RFC: extension of libi2c to support SPI aswell

[Thomas Doerfler]

Hello Robert,

nice to hear you again :-)

And it is nice to find potential for further synergy (see -> SD-cards) :-)

Robert S. Grimes schrieb:
> Hi Thomas,
> 
> Hope you enjoyed your time off!

yes, it was very relaxing and we had much fun.


You are a bt concerned about the many "liberties" you have when using
SPI, due to the distinct chip select lines which can be routed
arbitrarily in the individual board hardware. This is oposed to I2C,
where the slave address is transmitted as a bit pattern over the serial
lines before each transfer.

This was an initial problem I had. But now I have split the low-level
driver into two parts: The main part (dealing eith the actual serial
data transfers, the mode settings for baudrate, clock/data relationship
etc) is board-independent (and therefore I want to implement it in
libcpu/<arch>/<chiptype>).

An auxiliar part is board dependent:

- It contains functions to performs an "address" to "chip select pin"
mapping (and to activate these lines when needed),
- It collects the required function pointer (pointing to the
board-independent and the board-dependent functions) and registers then
as one low-level driver to libi2c.
- And also attaches the SPI devices acutally available to the libi2c
middleware.

It is implemented in libbsp/<arch>/<board>

> 
> 1. The Analog Devices AD7490 (a nice little 16-channel, 12-bit A/D
> converter) actually uses the CS both to frame a fixed-size 16-bit
> transfer, but also initiate the A/D conversion.  So for this device, the
> CS must go active, then 16 clocks along with data, and then the CS must
> return inactive.
> 
> 2. The Ramtron ferro-electric non-volatile memories
> (http://www.ramtron.com/doc/Products/Nonvolatile/Nonvolatile.asp?ID=5)
> uses the CS signal to frame a transaction, where a transaction consists
> of a command by followed by a variable number of bytes.  For example, a
> read or write operation consists of a read opcode, followed by two bytes
> of address, followed by one or more bytes of data; the number of bytes
> is actually unlimited, as the device will wrap around if necessary.  So,
> the read or write operation is terminated not by a predefined (by the
> chip) number of bits, but rather by the CS signal.
> 
> 3. The Maxim MAX6957 is even crazier; while it is basically 16-bit
> transfer oriented, multiple devices can be daisy-chained to appear as a
> Nx16 bit wide device, hence requiring the CS to frame that sequence!
> 
> So the AD7490 uses a strict, constant 16-bit word transaction, while the
> Ramtron devices use a variable number of bytes per transaction.  So it
> is important to allow flexible handling of the CS signals in order to be
> able to communicate with these very different devices.

This must be handled by chip-specific drivers. They will be specific to
a certain SPI slave device, but independent from the board driver. So
they may be implemented in libchip/spi

> 
> Another issue that will be important to those using various Freescale
> CPUs that include the QSPI peripheral is the ability to either use the
> supplied CS signals (typically 3 or 4) directly, or as a selector using
> an external decoder to select one of 2^N-1 devices.

This can be handled in the board-dependent driver functions (see above).
Unfortunately my concept does not use all the nice features in the QSPI
like queueing, but these are too specific for such a general concept.

> 
> On another project, I did some investigation into how Linux does this,
> and the newer model seems to address these issues, at least in theory. 
> I don't know if their approach is overkill or not; perhaps someone who
> has used it can comment?
> 
> As for me, I need to use quite a few SPI devices in my current project,
> specifically the AD7490, Ramtron FM25L256, a custom CPLD (probably will
> use a fixed-size transaction as wide as 64-bits, and a SD flash card, so
> I am quite interested in this effort.  As you know, Thomas, I'm using
> the Xilinx Virtex-4 devices, and I intend to use several of the opb_spi
> peripherals per V-4, plus a custom adaptation that is essentially an
> opb_spi16 - a 16-bit wide version.  So I certainly could work on the
> low-level, hardware-specific parts for the V4 chip.

SD-card is on the wish list for our next project, so there might be some
synergies there!!!

I have a rough thought about a ATA-over-SDcard-over-SPI driver, which
would support SPI-mode SD-cards on ANY supported SPI hardware. Sounds nice?

wkr,
Thomas.

> 
> Thanks for bringing this up, as I've found the SPI a very convenient
> means of interfacing to a wide variety of peripherals, and a suitable
> driver is a great addition to RTEMS!!!
> 
> Take care,
> -Bob


-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9