Hello,
We understand that there are those who really wish to do spi sharing. At the moment we have not been able to come up with a method that would be easy to use with the large number of spi devices out there. If there were a straight-forward way to accomplish this, we would certainly have done it. The FAQ below is the current status of sharing the spi with the file system.
FAQ: Sharing the QSPI with the EFFS on NetBurner Modules
---------------------------------------------------------
1. Does the EFFS require exclusive use of the processor’s QSPI?
Exclusive use is the only supported method of using the EFFS. Sharing the QSPI with other devices is extremely complex and the implementation will vary greatly from one SPI peripheral to another. Essentially each implementation becomes an engineering task particular to the design.
2. Are there any examples of QSPI sharing?
No, each device has different requirements.
3. Are there any other options?
If you are using a Mod5234, the eTPU signals can be configured as a SPI port. There are also external devices such as the NXP SC18IS602/602B which is an I2C to SPI bridge chip.
4. Is it possible to implement QSPI sharing myself?
Yes, but please be aware that we cannot support that effort. The source code for the SD card QSPI driver is located in c:\nburn\<platform>\system\mmc_mcf.cpp.
5. Do you have any recommendations?
Basically what you need to do is check if the SPI bus is free before using it. If it is free then you need to make sure it is properly configured for the device. Anything else at the EFFS level, such as open files, should be irrelevant since the SD card will just be in a
stalled state.
One possible strategy is to create a structure that contains all of the configuration settings for each specific QSPI device, one of them being the SD Card. This structure should contain all of the general configuration registers for this peripheral as well as the settings for each of the queue configuration registers. You can find the configuration settings for the SD Card in the "int spi_init (void)" except for the actual SPI clock speed.
The clock is first set to the lowest speed possible, about 100KHz. Then when the card is mounted the driver will communicate with the card and check its rated speed. After a successful mount the QSPI speed will be set. This value can change for various cards.
The EFFS uses the function "void spi_set_baudrate (unsigned long br)" to set the QSPI baudrate. You might want to add code in this function to save this new baud to the structure you made to remember your QSPI configurations for the SD Card.
You then need to use an OS object to protect the SPI bus, such as an OSMbox, since you can pass data with these objects. Assign each SPI device a specific ID and store it in the mailbox. The places you pend on this OS object should be at the beginning of the functions that accesses the bus. For example, from "C:\Nburn\MOD5234\system\mmc_mcf.cpp", put the protection at the beginning of the "spi_cs_lo" and post the object at the end of "spi_cs_hi". This works at the CS level for the SD card since the CS is asserted and deasserted via GPIO at the beginning and end of each transfer. When using the general QSPI driver (qspi.h) the CS is asserted by the peripheral after each word is transferred. You will need to set the pend and post is the proper places in your code to completely protect the entire QSPI transaction.
Now combine your OS protections and your stored settings structure for each device. First pend on the Mbox. Then once you successfully gain control of the OS Mbox, check the value in the mailbox. If this value is the same as the ID assigned to the current SPI device then continue on to use the peripheral. If the ID is different then you need to load
the correct settings for your device into the QSPI registers. These device specific settings should be stored in the structure mentioned earlier. Then write the current device ID into the mailbox to specify how the QSPI is currently configured. Now you can continue on to use the peripheral.
