Closed jerryneedell closed 4 years ago
We discussed this in today's weekly meeting: https://youtu.be/CqDPd4dVNaI?t=3530
The conclusion was that this is expected Python slowness setting up the transaction. The gap between 4 bytes transmitting is due to manually providing bytes to the peripheral rather than using DMA.
@tannewt is having a more streamlined DMA process something you'd like to eventually explore?
@hierophect Not really. The SPI delays are very minor compared to the setup cost in Python.
@tannewt would you recommend closing this, in that case? Or are there other performance improvements you'd envision long term?
Nothing concrete. Will close.
I have been doing some timing tests of SPI transactions
This is on a feather_m0_rfm69 (SAMD21) but there are similar delays on SAMD51 and STM32F504. The delays are shorter on the faster boards, but still seem long.
There seem to be very long delays between the SPI transactions. This figure shows a write operation The interesting thing is how long it takes before the writes actually happen top 4 traces are MOSI/MISO/SCK/CS trace 5 is D13 -- self.led in the code trace 6 is D12 -- self.signal in the code
D13 is set High when the write function is called D12 is set High when the actual spi write starts after getting set up see the code snippet below from the rfm69 module
As you can see, there is nearly a millisecond of delay before the write actually begins.
This same delay is present every SPI transaction. Like the second picture when it is polling for a packet receipt.
There just seem to be a lot of dead time. My question is, is these delays between transactions expected and necessary?
If I run this in Arduino, the delays between transactions are in microseconds.