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

[ennut at thezachariasgroup.com]

  I wouldn't modify the Nut/OS code but handle it at the application 
level.  (What do other developers feel about this?)

   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



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.

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.

   Hope this helps !

    Zack


At 03:51 PM 9/26/2008, you wrote:
>On Wed, Aug 13, 2008 at 08:16:40AM -0400, ennut at thezachariasgroup.com wrote:
> >    Jae,
> >    The problem was with the processor.
> > I have a EEPROM connected to PA12 which is SPI0_NPCS0.
> > The SD/MMC is connected to PA13 which is SPI0_NPCS1
> >
> > The chip uses SPI_CSR1 for the SD/MMC card until there is activity on
> > the EEPROM. Then the chip starts using SPI_CSR0 instead of SPI_CSR1
> > for the SD/MMC card.
> > (It took me a while to figure this one out)
> >
> >
> > My solution:
> > I put a semaphore that regulates both the SDCARD and EEPROM.
> >
> > Before a EEPROM operation I execute the following command:
> > outr(SPI0_CSR0, uwEEPROM_CSR0); //
> >
> > Where uwEEPROM_CSR0 is the SPI_CSR value for the EEPROM.
> >
> > After a EEPROM operation is complete I execute the following command:
> >
> > outr(SPI0_CSR0, uwMMC_CSR1); // This did the trick
> >
> > Where uwMMC_CSR1 is the SPI_CSR value for the SD/MMC card.
> > Note that this is written to SPI0_CSR0. This value should only have
> > to be used for SPI0_CSR1.
> >
> >
> > I have not tried to see what happens for the other two chip selects.
>
>I'm currently facing a similar problem with a SAM7X256.
>SPI flash on SPI0_NPCS2, MicroSD on SPI0_NPCS3
>Two VS1033 on SPI1_NPCS0/1/2/3.
>SPI1 works fine with my own code.
>The MicroSD card works fine as well with Nut/OS code.
>Now I want to use the flash on SPI0_NPCS2, but PHAT access can happen
>from other threads.
>
>Your suggestion sounds reasonable, but I'm a bit unsure about where
>to place the locking in the Nut/OS code.
>
>--
>B.Walter <bernd at bwct.de> http://www.bwct.de
>Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion