heju wrote:However in between the consecutive frames we have large gaps of ~0.5ms
This limits somehow the speed for consecutive single transactions.
I never did a comparable test on the Pi running linux, is this a hard limitation or did I miss something?
What you are seeing is mostly the result of trying to create a high level API that covers the requirements of as many people as possible.
If you look at the driver level implementation of SPIDeviceWriteRead (for example BCM2709SPI0WriteRead) you will see that it does a lot of setup work for each transaction.
Determining the mode, chip select, clock rate, setting the control registers to enable the actual transaction and then performing memory barriers to ensure correct ordering etc, probably one of the biggest elements of the 0.5ms gap will be due to the use of SemaphoreWait to cause the calling thread to wait for the transaction to complete.
SemaphoreWait will place the thread onto a wait list and once the interrupt signals the completion it will be returned to the scheduling queue to await rescheduling, the scheduler interrupt only triggers every 500us so it can take up to this amount of time for the thread to be woken after the completion.
Of course if you need to send longer transactions then the SPIDeviceWriteRead function allows for that, your device also has to support receiving a larger block of data and your application needs to have the data available to send.
Multiple different approaches would be possible, one idea might be to create a custom version of the SPI0 driver which either doesn't use SemaphoreWait (perhaps using a non sleep delay instead) or going further and creating a driver that takes a circular buffer and keeps sending transactions as long as their is data available.
We are open to ideas that might make the API more useful for a wider range of tasks so if you have any thoughts please let us know.