[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805271642.42291.david-b@pacbell.net>
Date: Tue, 27 May 2008 16:42:42 -0700
From: David Brownell <david-b@...bell.net>
To: mgross@...ux.intel.com
Cc: spi-devel-general@...ts.sourceforge.net,
Jonathan Cameron <Jonathan.Cameron@...il.com>,
linux-kernel@...r.kernel.org,
LM Sensors <lm-sensors@...sensors.org>
Subject: Re: Accelerometer, Gyros and ADC's etc within the kernel.
On Tuesday 27 May 2008, mark gross wrote:
>
> > > 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 )
Actually figure 19-3 (p. 198) may be a bit more clear.
Curious. That PIC18F controller has *three* bits ... equivalents
of CPOL and CPHA, plus a bit saying whether to wait a whole or
half clock after the leading clock edge before sampling it.
A quick survey of some other SPI chips suggests that the most
conventional interpretation is to sample on the trailing edge
of the clock, and not presume long hold times.
I would surely hope the SPI interface spec doesn't have to get
into the mess of timing variations which typify anyone trying to
make memory controllers do the Right thing ... *shudder* ...
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists