[En-Nut-Discussion] SPI Bus

[duane ellis]

Thiago> [ why does the at91 spi driver not use the PCS pins auto magically ]

Bernd> Some slaves require the CS to be asserted over a complete sequence,

My take on NUT interfaces is that they are "purpose built" - and not 
"generic built" - ie: There is a seperate function for uart0, and uart1, 
etc. In contrast, a "generic driver" often requires a bit more code 
space, more features, etc. In a limited resource systems (like nut) 
purpose built is good, but painful when viewed with "generic views".

As Bernd points out - other target chips have strange requirements.

For example some chips require a long delay between the initial SPI 
byte, which acts like a command, and any subsequent bytes, the payload. 
Often these are really a micro processor acting as a SPI slave. ie: The 
chip detects a SPI rx interrupt. Q: How long is the interrupt latency? 
Then, once in the IRQ, the code can poll the SPI interface in tight high 
speed hand optimized loop, then return from the IRQ when done.

I'll add that some SPI hosts have other problems,

The AT91 has a two DMA channels, one TX and one RX.  In contrast: ADI 
Blackfin has a uni-directional DMA interface, you create two back to 
back DMA transfers, use DMA interrupts and and reconfigure the DMA 
between each sub-transfer, while keeping the CS pin active via GPIO. The 
Blackfin has "cs" built into the SPI controller but in this case, it 
cannot be used.

Other chips require balanced DMA transfers - ie: Remember SPI hardware 
really is full duplex, for ever byte transmitted on MOSI, a byte is 
received on MISO.  When talking to a SPI flash, you send a few command 
bytes, and a huge payload.  In the flash case, the transfer is 
unbalanced. Some DMA systems, operating in full duplex mode require the 
TX buffer and RX buffer to be equal sizes (balanced). To help, some 
chips have a "fill with 1s" bit in the SPI interface.

It just gets messy.

-Duane.