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
