No DMA support for SPI in arduino-esp32?

[RudolphRiedel]

Neither the SPI class which is merely a wrapper or the underlying esp32-hal-spi.c seem to support DMA.
Is this observation correct?

Or is there a way to send a buffer over SPI with DMA without adding a third party library?

[me-no-dev]

DMA will be added at some point but it's not an easy task because of some internal issues. For now you can use the IDF API for SPI and utilise DMA that way.

[RudolphRrr]

I could not find it.
But it appears to be in here: https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/lib/libdriver.a
And this would be the SPI include for it:
https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/driver/driver/spi_master.h

[lbernstone]

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_master.html
You can include idf drivers in arduino, as long as you don't mix the two.

[RudolphRiedel]

Before you wonder, "RudolphRrr"is my account as well.
This looks promising, the documentation unfortunately not so much.
I managed to put in some workarounds to make SPI at least faster as on the UNO but sending out the buffer with DMA should be way faster while allowing lower SPI clocks.

With a simple SPI.transfer(data) executing a lot slower on the ESP32 than on the UNO, the SPI class kind of needs an update, and/or probably esp32-hal-spi.c.
The extra functions like SPI.write32() and SPI.writeBytes() are pretty much mandatory when sending more than the occasional byte over SPI - very nice to have but also not really portable.
Yes, I know there is supposed to be a reason why it is that slow, it is thread-safe, or maybe it is.
On the other hand the ESP-IDF driver is not even thread-safe.
And the 6.25µs between SPI transfers with esp32-hal-spi.c. really are way too much - that is 1500 clock-cycles of doing nothing.
https://user-images.githubusercontent.com/31180093/100015163-d0d87f80-2dd7-11eb-807b-d12fee2e7706.png

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[RudolphRiedel]

Not actually resolved but I worked around the issue by using ESP-IDF in the meantime.

One thing that was interesting to note is that the time between two simple 8-bit transfers on ESP32-Arduino is ridiculously long, especially for a 240MHz controller, with 6µs.
It is even longer with ESP-IDF, I measured 28µs at first using spi_device_transmit().

Yes, I am talking about the pause between sending two bytes, the time from one byte is finished and
the next starts to transfer.

When claiming the bus with spi_device_acquire_bus() / spi_device_release_bus() this is even increased to 32µs.

I switched over to use spi_device_polling_transmit() and it got a lot better - for whatever reason.
With locking the bus I got down to 8.2µs without locking I measured 12.2µs.

So using simple SPI transfers with ESP-IDF is even slower than with ESP32-Arduino.
But at least this is offset by the possibility to use DMA.
Oh yes, I also found that native ESP-IDF is running slower than the ESP-IDF that is supplied with ESP32-Arduino.

At this point I consider SPI with the ESP32 to be severly broken.

And for a reference, when using the Arduino SPI class on an Adafruit Metro M4 which is clocked at 120MHz,
the gap between two bytes on the SPI is only 440ns.
Heck, even an Arduino UNO at 16MHz is faster than the ESP32 at doing single byte transfers over SPI.

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.

[s-light]

the base issues of very long inter-byte gaps is still valid.
i will open up a new issue - if i get my hands on an oscilloscope to write a good test-case.
i first encountered this issue by trying to get my TI TLC5971 LED-Driver chips working...

[RudolphRiedel]

Playing with an ESP32-C3 I learned that the SPI got a lot faster in the meantime but there still is no DMA support.
I tried to combine the SPI class with ESP-IDF but so far the DMA works only once and the overhead to switch is about 600µs.
I guess it is not really feasible to combine esp32-hal-spi / SPI.cpp with ESP-IDF since esp32-hal-spi is doing direct register access?

Combined SPI.cpp / ESP-IDF transfer:

ESP-IDF no-DMA and DMA transfers:

SPI class only

Looking at this it is probably overdue to remove the ESP-IDF based transfers again.
While this make the SPI transfers blocking, the short blocking transfers take 3.6x to 4.0x more time when using ESP-IDF.
And at least the first 15µs of the ESP-IDF DMA transfer is overhead.
The display update with 228 bytes takes 30µs with the SPI running at 20MHz, this is preparing the buffer and asking ESP-IDF to send it with DMA.
The display update using only the SPI class which makes this a whole lot more compatible to anything else using the SPI takes 139µs now which is way faster than what I measured originally.

I still would like to see DMA support added, 228 bytes is only a tiny buffer.
But this looks feasible now and compatibility is a very nice bonus.