[En-Nut-Discussion] Multiple devices on the SPI BUS

[Bernd Walter]

On Fri, Sep 26, 2008 at 09:02:45PM -0400, ennut at thezachariasgroup.com wrote:
>   I wouldn't modify the Nut/OS code but handle it at the application 
> level.  (What do other developers feel about this?)

I'm not scared to modify the Nut/OS code for my personal needs.
I already had to change it a bit because I'm using an RTL8201BL PHY.
It is too hardware dependend to have everything configureable.
I'm already quite amazed how much can be done with defines, but in
the end it can't be generic enough for every case.

>    You need to define and initialize a semaphore.
> 
> SEM semSPI0; // should be global
> NutSemInit(&semSPI0, 1); // Set to one so only one resource can 
> access the SPI0 Bus at a time.
> 
> 
> Now every place you need to access one of the devices on the SPI0 bus 
> you need to execute the following sequence:
> 
>    NutSemWait(&semSPI0); // Make sure it is OK to use the SPI0 bus
> // Potentially modify the CSR
>    ...
> // Execute your code as quick as possible
>    ...
> // Potentially set the CSR value back to the original value
> 
>    NutSemPost(&semSPI0); // Make sure it is OK to use the SPI0 bus

That's well understood.
I'm using NutMutex*, which is a bit easier to use as a Mutex.
It is more where it is best placed within Nut/OS code.

> One approach to regulating the SPI bus is to decide which CSR value 
> is going to be programmed in the 7X256 while the bus isn't
> being used. For many systems it may be the MicroSD card. If the 
> MicroSD card needs to be accessed, no changes to CSR is required.
> If the SPI Flash needs to be accessed then the Flash routine will 
> change CSR to the proper value, access the Flash, then set it back
> to the CSR value the MicroSD card requires. Just a thought.

Agreed - I know which CSR is used bby the at91mmc code and everything
else is free.

> Another approach is to have the routine set the CSR value that it needs.
> 
> 
> All of this is a pain.
> 
> If you can make any of the CSR values identical for a given SPI bus, 
> it will make your life easier.
> 
> 
> Since you are using both SPI busses,  you may need two semaphores.

The other SPI is no problem, since it is only used by my code.
I use my own SPI1 Mutex for it and everything is fine.
The point is that the MMC code needs to be teached to use the same
sempahore that I use for SPI0.
Your idea to use it in around every FS access sounds interesting, but
isn't possible without Nut/OS changes as well, because I use FTP
service.

Well - if I understood the code correct the existing MMC semaphore is
almost useable in this case, although it is obviously intended to
protect something else.
I only need to change it's name and export it, so I can claim it in
my own SPI0 code as well.
The only point where SPI1 is not protected is in the MmCardInit()
function, but this is not a real problem for me.
I only need to take care that the semaphore isn't initialized if
MmCardInit() fails.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.