RFC: extension of libi2c to support SPI aswell

[Robert S. Grimes]

Thomas Doerfler wrote:
> And it is nice to find potential for further synergy (see -> SD-cards) :-)
>   
It certainly will be my pleasure!
>   
> yes, it was very relaxing and we had much fun.
>   
Good to hear!
> 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.
>   
Exactly.
> 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>).
>   
Okay, that's starting to make a lot more sense to me  I haven't really
been outside of the libbsp tree - yet! - so again I am reduced to the
newbie level!  But is that the correct directory?
> 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>
>   
This much I understand!  ;-) 

It seems this is where I could help, unless you are already working with
libbsp/powerpc/virtex - if so, I'll step back and let you have at it and
I can serve as a alpha tester like before.  If you are not working on
virtex for this, I'd be happy to do that, though I'll need more guidance
on how to fit it into the RTEMS build system.  Let me know how I can help...
> 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
>   
Oh, I see - this certainly makes sense.  So these chip drivers would use
the spi driver as a lower-level facility.  And for example, the Ramtron
chip driver could provided functions like fram_read(uint32_t offset,
size_t count, void* buffer) to the user, right?  Cool, I like that, and
I certainly could work on these, probably more effectively than the spi
drivers themselves.
> 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.
>
>   
Perhaps someone actually using the QSPI can help here someday!
>> 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?
>   
Yes.  Originally, I was probably not going to go that far, as I don't
really need that much sophistication, and my schedule would not allow
for me to go to that extreme.  On the other hand, with some help, it
certainly would save me from other problems.  The SD is a bit further
out (a couple of months) for me, but it's never too late to start
planning ahead.

So again, let me know how I can help!

Best regards,
-Bob
> 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
>>     
>
>
>