On Tuesday 20 May 2008, mark gross wrote:
quoted text
> > 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.


quoted text
> 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!  :)


quoted text
> 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.
 

quoted text
> 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.

- Dave
--
unsubscribe notice
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/