SPI Master on ConnectCore 9P 9125

Hi All,

I am using the standard NetOS drivers for SPI. For my application I need to repeatedly Read/Write 24 bit frames and to deselect the device between each frame. I have configured the raw SPI rate to 4MHz and that works fine, but the data transfer seemed to be relatively slow when sending multiple frames as above.

I have set up a GPIO to time the actual NASpiReadWrite() function call and have some interesting results.
From calling NASpiReadWrite SPI_EN low >> 84us
CSN low to CSN high >> 6.2us
CSN High to return from NASpiReadWrite >> 264us

It seems that with repeated small packets there is an excessive overhead with the software in the driver. Is there any way that it is possible to improve this?

Hi All,

I have done a bit more investigation of what is actually going on here and found that the bulk of the problem seems to be associatedwith the NAuWait() function.

It would appear that this function accepts a single parameter to indicate a number of microseconds and then uses the Timer API to introduce a blocking wait. The function is called in a section of code to implement an overall timeout which waits for the SPI DMA transfer to complete, and is also called to provide a delay for Chip select deassertion.

The overall logic of the timeout code seems to me to be totally flawed. When using the standard signals that the devboard uses for SPI the CS control is automatic so it is possible to set the delay to zero in the SPI device config structure and remove some of the delay.

The NAuWait() function is contained in the nawait.c file. It does not seem to provide the required time delays. I have checked this in isolation with using a simple loop >>>

while (TRUE) {
NAsetGPIOpin (73, 0);
//NAuWait(100);
NAsetGPIOpin (73, 1);
}
With No delay GPIO73 low for 2.6us

while (TRUE) {
NAsetGPIOpin (73, 0);
NAuWait(100);
NAsetGPIOpin (73, 1);
}
With 100us delay GPIO73 low for 261us

With 1000us delay GPIO73 low for 1156us

This routine uses the standard functions for the Timer API. I have not yet determined if the implementation of the routine itself is causing the problem or if the Timer API itself has problems