Hello,
I have an interrupt generated on a GPIO pin. When this interrupt happens (every 2ms) I need to initiate an SPI transfer via DMA. It all works, but the time from the interrupt happening to when the first clock is output to the SPI device is ~76 microseconds. I would like to drive this time interval down to <40 microseconds.
While I don't know exactly where all this time is spent, the vast majority of the code lives in hw_spi_read_buf() and hw_dma_channel_initialization(). Given the way my application works, it would appear that most of this code could be done once outside the interrupt. Leaving the code Inside the interrupt to only resetting the destination buffer and enabling the dma channels.
It doesn't look like there is a way to do this with the current SDK... Do you have any advice on the best way to achieve this as I don't have a good feel for which parts of the code need to be done every time a transfer is initiated and which parts remain constant.
thanks,
marco
So, I implemented two new functions in hw_spi.[ch]. The first does everything hw_spi_read_buf() does except for the enabling of the DMA channels. The second updates the source/destination addresses and enables the DMA channels. The interrupt latency is reduced to 36us which is acceptable.
I don't like modifying the SDK sources so perhaps this functionality could be included as it would seem an obvious solution where the SPI is connected to a single device and servicing it in a timely fashion is important (equally important would be to not spend a bunch of time in the ISR in the first place).
marco
Hi marcodg,
I would assume that you are in cached mode and what you are facing isn't exactly a code execution stall, but the fact that the device stalls due to fetching code from the flash. From what i can understand from your post on you attempt to reduce the the time you broke the hw_spi_read_buf() function to two seperate functions and therefore you altered the code positioning in the flash, so those two functions, smaller in size are cached or retained perhaps, thus there is no extra time delay for the device to fetch code from the flash. Try to add __RETAINED_CODE prefix in the functions that are being invoked from the interrupt so that they are kept in the sysram and if i am right that should improve the response time of the system.
Thanks MT_dialog