Hi,
I try to read 630 Bytes, clock frequency 14Mhz using SPI1 interface.
As the Spi_Read() function fails, I use Spi_ReadWrite() for now.
I read 100 times 630 Byte blocks, the image shows one of this transfers I randomy picked and every block contains a gap. The transfer is stalled for about 39µs and this happens more or less at the same position within the transfer.
Whats going on?
I expected breaks at random positions and of ramdom duration caused by other tasks needing the processor. I see this behavior on my former SoM running WEC2013.
I get this breaks every 50 transfers, but duration could be much longer. I have to implement a ring buffer at the system generating the data to get it working without data loss.
I guess it is ok for now, tests follow, I just ask to know whats happen behind the scenes.
Thanks a lot.
With best regards
Gerhard
Dear @Gerhard
I don’t have a simple explanation why this delay happens at the same position. It required quite some investigation to find the reason. As it seems to be no real concern for you, I woule prefer if we don’t need to do all the work.
39µs delay are probably too short for a context switch, so it looks more like the explanation is in something like an interrupt service routine, or the SPI algorithm itself.
You mention that it sometimes takes much longer. In this case we might see an interruption by a higher priority thread. You could try to increase the priority of your thread which calls Spi_ReadWrite() to see whether it reduces the long delays.
Regards, Andy
The GAP may be due to the need of reloading data into the SPI FIFO, increasing the priority can remove it or, at least, make its maximum duration more stable, avoiding additional jitter. I am not sure that increasing priority of the thread calling readwrite is enough, other threads may be involved.
