Messages in this thread | | | Date | Tue, 27 May 2008 08:56:41 -0700 | From | mark gross <> | Subject | Re: Accelerometer, Gyros and ADC's etc within the kernel. |
| |
On Wed, May 21, 2008 at 05:53:38PM -0700, David Brownell wrote: > On Tuesday 20 May 2008, mark gross wrote: > > > ST Micro LIS3L02DQ 3D accelerometer. ... > > > > FWIW: I have this device talking to a PIC-18 and pushing the results > > over the serial port. > > Jonathan neglected to mention that he's already sent a driver > for this to the SPI list. ;) > > Which is part of the reason for asking this question. Right > now that driver sits in drivers/spi/lis3l02dq.c but that is > probably not its best long-term domicile. > > > > WRT linux support, I can't think of a generalized way to create a driver > > that would be able to be used with this device in Linux. You need to > > know witch IRQ line the DR line is connected too, and if you are > > bit-banging the SPI data off the thing, then you need to know which > > GPIO's of the host CPU you'll be using. If you have SPI hardware then > > you need to know where to pull the data from. The problem doesn't seem to > > generalize well. > > I guess I don't follow. The SPI framework handles all that > stuff already, even if you're bitbanging. Though to be > sure, if you're bitbanging SPI you want your platform to > be able to inline those GPIO calls so those inner loops > only take a few instructions per bit ... also solved! :) >
I'll take a look sometime soon.
> > > Also, If you are playing with accelerometer data, you likely need some > > real time support or at lest a reliable time stamping of the data to do > > anything interesting. > > True. I imagine a few other such issues will appear once > more folk than Jonathan are using these sorts of sensors > on Linux. I'd expect the sample stream to have internal > timestamps for truly critical systems, unless variability > in when the host makes timestamps is not really an issue. >
Its on my list of things to do..
> > > Another problem area is around SPI itself. There are variations of > > device implementations around chip select polarity, clock biasing > > (rising,falling, or midpoint) sampling from one SPI part to the next. > > Midpoint? That's not one I've come across before. All four > standard SPI clock/sample/shift modes are already supported > in the SPI framework though. Ditto active-high chipselects > (vs normal active-low) etc.
Yeah, its one of the sampling modes for the PIC18F4455 its one of the master mode sampling options (see page 194 of http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf )
--mgross
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |