SPI Chip Selects

[SeeCwriter]

I'm looking at the PinIO class for the MOD5234, and there are no definitions for SPI_CS2 and SPI_CS3. Yet the CPU reference manual says there are 4 SPI chip selects available for its QSPI bus. Are the two upper chip selects not available for use on the MOD5234 module?

Steve

[lgitlitz]

The MOD5234 only brings out 2 of the 4 SPI chip selects. The data sheet is a bit easier to read if you are looking at the available functions for the module pins: http://www.netburner.com/downloads/mod5 ... iagram.pdf. This processor has 256 pins, only 100 can be brought out to the header.

A little bit of a side topic but the SPI peripheral CS signals are not so great unless you need them for continuous transfer mode. These chip selects are one of the most common problems I have seen people run into when trying to set up an SPI slave device. The SPI peripheral will de-assert the CS signals whenever the end of the SPI queue is reached. Due to this the QSPI driver can only assert the CS signal for the length of each data word, it is then de-asserted briefly between each data word. This can be a problem with many devices as they want the CS signal asserted for the entire transfer. SD Cards require the CS for the entire transfer, all microchip A/Ds I have tested also require CS asserted the entire transfer. It is simple enough to simply assert a GPIO pin before you start a transfer and de-assert it after the transfer. I do not recall any devices that have issues with the CS signal being asserted the entire transfer, even if they work with the other way too. The hit on performance here is nearly nil compared to the speed of the transfer.

-Larry

[SeeCwriter]

Thank you for that reply. That was very helpful and I'm sure saved us many hours of debugging.

[bbracken]

Honestly, the CS concept for the QSPI is very limiting. I have written a QSPI driver for an MCF5225x that totally bypasses the QSPI CS handling and uses GPIO for CS. First of all, you are no longer limited to the 4 CSs (and don't have to add external hardware to support up to 16 SPI devices). You also do not have to worry about the absurd CS handling at the end of the 16 word buffer. The driver I wrote can transfer as many bytes as necessary all within a single assertion of CS.

Basically the driver does not enable the CS signals for QSPI usage and uses a unique GPIO for each SPI device which must be manually controlled. The generation of the clock, sending and receiving of SPI data is still done by the QSPI core.

Not sure what impact this driver would have in a NB world (particulary with the FileSystem interface)... but am pretty sure that it would require some minor changes.

bb

[Ridgeglider]

On the 5234 you could use the eTPU to set up an SPI interface that's independent of the EFFS: http://www.netburner.com/downloads/mod5 ... ppNote.zip

[yevgenit]

Honestly, the CS concept for the QSPI is very limiting. I have written a QSPI driver for an MCF5225x that totally bypasses the QSPI CS handling and uses GPIO for CS. First of all, you are no longer limited to the 4 CSs (and don't have to add external hardware to support up to 16 SPI devices). You also do not have to worry about the absurd CS handling at the end of the 16 word buffer.

QSPI unit has flexible and powerful feature: hardware control of CS lines per each of 16 control entries. Using of this feature is too limited and confusing in the QSPI library. This feature is poorly understand by the non-experienced developers.

Below is example of advanced using the QSPI hardware features. I rewrited QSPI driver in my latest project for continuous ADC TI tlc2578 sampling at 7 channels, including 3 channel with sample rate 20480 samples per second and 4 channels with sample rate 5120 Hz. The interrupt rate is 10240 Hz. The interesting driver feature is filling of transmit queue and control queue only during the initialization. Then, entire sequence of the ADC programming and triggering doesn't consume the CPU time at all. CPU only needs to read samples from the (half) receive queue in time. One CS line is used for ADC wakeup/idle, and another CS line is used for 10240 Hz external interrupt. Such a performance is impossible without QSPI-controlled CS lines.

[lgitlitz]

I agree that the automated CS lines are a requirement for high speed acquisition applications. Still these are the only applications I know that benefit from the automated CS signals over GPIO. The example for the tlc2578 didn't get attached to your post, I would be interested in seeing that one. I like how you used a CS line to interrupt the CPU for reading data. You are completely correct about the CS lines being very important for continuous mode QSPI. I posted an example previously that used continuous QSPI mode for interfacing with two TLV2548 A2Ds ( http://forum.embeddedethernet.com/viewt ... ?f=5&t=823 ). What I did here is configured the QSPI to continuously read from the 2 A2Ds and store all 16 A2D channels in their respective QSPI queues. Once configured no CPU time was required except to simply read the specific queue for the most recent conversion. My goal here was not to store a large amount of high speed A2D but to have the lowest latency possible when reading any of the 16 A2D channels.

Currently the NNDK QSPI driver works in non-continuous mode. Basically it loads as much data as possible into the 32 bytes of queue space and starts the QSPI. When the data reaches the end then the QSPI stops and an interrupt occurs. Data is then read and/or written to the queues and QSPI is started again. At lower SPI speeds the interrupt delay is not significant. At higher speeds, such as 20MHz, about half the CPU time is spent in the interrupts so the effective speed is only 10MHz. One good thing here is you also get 50% CPU time for your application while the transfer is running. The NNDK QSPI driver was written to simplify the usage of QSPI and to be universally compatible with most external peripherals. While this driver can universally communicate with most devices, it can not be used for high speed data acquisition such as your A2D application. Any high bandwidth QSPI application should be written in a custom driver, though this will be challenging for someone who is unfamiliar with this peripheral. The NNDK also uses QSPI for interfacing with SD Cards. A custom driver was written ( mmc_mcf.cpp ) to improve performance over the regular QSPI driver. This driver is polling based by default, it runs in a loop continuously reading/writing data to the QSPI peripheral. This will run the QSPI at the highest speed possible with no queue loading delays but requires 100% CPU time. If another task or interrupt starts running then QSPI completely stops. If SD_IRQ_QSPI is defined in this file then the SD Card transfers will used the NNDK interrupt based driver. This will slow the max speed of the transfer by about 20-30% but will allow other interrupts and tasks to run while transferring data to the SD Card.

-Larry