Hi all. I decided to try driving an APA102 LED strip using DMA-based SPI on a T3.2. I’m using the standard SPI library that comes with Teensyduino. My code loads up the DMA buffer, calls ‘SPI.beginTransaction()’, and then calls this overload of ‘SPI.transfer()’:
The SPI parameters are set up for 24 MHz clock and things work pretty much as expected. The SPI.transfer() call returns very quickly and DMA autonomously blasts the data out to the LED strip while my code can do other stuff at the same time. Pretty cool.
Only one issue -- my timing measurements showed that the DMA transfer was taking longer than expected given the SPI clock rate and number of bytes transferred. So, I put the SPI Clock signal on a scope. This indeed showed the SPI Clock running at the full 24 MHz, but it was bursty. There are always 8 clock pulses at 24 MHz (a single byte being transferred), but each group is separated by a time gap. The gaps vary some, but they’re all on the order of ~200ns each.
So, finally, the question -- before I dig into this further, is this characteristic just the way it is with DMA SPI on a T3.2? Or, perhaps, is the DMA or SPI peripheral not being set up optimally by the standard SPI library? Or, could the DMA be being forced in to wait states by other memory bus activity? That seems unlikely to me given how regular the gaps are.
Thanks in advance.
Code:
bool transfer(const void *txBuffer, void *rxBuffer, size_t count, EventResponderRef event_responder);
The SPI parameters are set up for 24 MHz clock and things work pretty much as expected. The SPI.transfer() call returns very quickly and DMA autonomously blasts the data out to the LED strip while my code can do other stuff at the same time. Pretty cool.
Only one issue -- my timing measurements showed that the DMA transfer was taking longer than expected given the SPI clock rate and number of bytes transferred. So, I put the SPI Clock signal on a scope. This indeed showed the SPI Clock running at the full 24 MHz, but it was bursty. There are always 8 clock pulses at 24 MHz (a single byte being transferred), but each group is separated by a time gap. The gaps vary some, but they’re all on the order of ~200ns each.
So, finally, the question -- before I dig into this further, is this characteristic just the way it is with DMA SPI on a T3.2? Or, perhaps, is the DMA or SPI peripheral not being set up optimally by the standard SPI library? Or, could the DMA be being forced in to wait states by other memory bus activity? That seems unlikely to me given how regular the gaps are.
Thanks in advance.