ESP32 Forum

So, beginning with the "rmt/led_strip" example in the IDFv5 I added the "with_dma" flag to the rmt_tx_channel_config_t struct. The documentation for this flag states:

A channel with DMA attached can offload the CPU by a lot.

As I was curious about the performance implications of this, I decided to attempt to benchmark the difference. To benchmark it, I added a "busy_wait()" function that performs some simple math in a loop until 40ms has passed and counts how many loops it gets through in that time. The busy wait function begins as soon as the rmt_transmit() function is called. My theory is that if the PIO is having to interrupt the program flow to feed the RMT buffer, that will reduce the number of times the loop executes. I also compared this to an 'unburdened' run where the RMT peripheral is not used at all. What I found is:

• As expected, RMT transmit is not called, the loop executes the most number of times.
• When RMT transmit is called with DMA off, the loop slows down and fewer executions are counted.
• When RMT transmit is called with DMA on, the loop is slightly slower than with it turned off.

The difference between DMA on and off is small but consistent. It's performing something differently.

I have also tried this experiment:

• With more LEDs enabled than the default 24. I've tried up to 240.
• I've raised and lowered mem_block_symbols
• I've added DMA_ATTR to the buffer I'm passing to rmt_transmit
• I've added IRAM_ATTR to the encoder function

In conclusion, not only am I not seeing CPU offloading by a lot, but I'm seeing increased CPU usage when DMA is enabled. Am I misunderstanding the documentation? Am I missing a step in configuring RMT to be able to use DMA correctly? Is there a bug in the IDF? Has anyone else successfully used DMA with the RMT peripheral and seen a performance improvement?

That is odd... I'd expect DMA to add a small constant cost to the equation, but relatively that should disappear into nothing as the load increases. (420 LEDs qualify as that.) What chip are you using this on?

EDIT: According to the dev who designed the driver, mem_block_symbols is the size of the DMA buffer, so you should set this a lot larger than when you don't use DMA. Try something like 4096 or so, and see if the performance still is bad.

So, I'm running this on an S3. I changed some of the parameters, such as only using one transaction queue depth and at your suggesting, increasing the DMA buffer size to 2048 (the most without errors). Non-DMA's buffer size only went up to 256 before it started crashing. What I found was that the non-DMA version only utilized about 18% of the core for the period that the pulses are being emitted. The DMA version takes 0.01% of the core. There was poor testing methodology for my first observations. So, there is indeed a significant difference, from that perspective. But unless you're trying to run thousands of pixels, that 18% of the core is going to be amortized by the small proportion of the cycle budget that's spent actually transmitting the data. This could realistically be a factor, though, if you were trying to run multiple channels at the same time. Thanks for your help!

No worries! This also is a bit of a miss in the documentation: it doesn't really clarify that the buffer size should be increased for DMA to have any positive effect. We're going to correct that in an upcoming release.

Now if only I can push to help get Micropython transitioned over to esp-idf 5.x so I can implement a high-performance RGB LED driver for it! Even though IDF 4.4 supports the ESP32-S3 I did not see any way to enable DMA access from the RMT driver. Is there something I'm missing?