QSPI support

[allison-n-h]

Hoping to take advantage of the QSPI and DMA features of the SPI peripheral. This is listed as TODO in spi.rs

[pyaillet]

Dma should be ok now, thanks to #70 and #76
You might want to test this.

[madwizard-thomas]

The implementation currently used polling transactions even with DMA. Am I correct in that this prevents other tasks from being executed while the transfer is executing?
As a side question, is it possible to use esp-hal's SPI/DMA implementation in an esp-idf-hal (std) environment or is this recommended against?

[ivmarkov]

Am I correct in that this prevents other tasks from being executed while the transfer is executing?

What do you mean? You are on top of ESP IDF / FreeRTOS. When the driver polls for transactions, it does not busy loop, but sleeps the current task. You can execute as many other tasks during that time as you want.

As a side question, is it possible to use esp-hal's SPI/DMA implementation in an esp-idf-hal (std) environment or is this recommended against?

Haven't heard of anybody else doing that, and your mileage might vary. Not sure why you want to do that in the first place.

[madwizard-thomas]

When the driver polls for transactions, it does not busy loop, but sleeps the current task.

I asked this because the esp-idf documentation says the following:

Polling transactions save time otherwise spent on queue handling and context switching, which results in smaller transaction duration. The disadvantage is that the CPU is busy while these transactions are in progress.

It wasn’t clear to me before if this meant the task busy loops or if it just blocks each time the task is activated.

[ivmarkov]

Good point, let me check again actually...

[ivmarkov]

@madwizard-thomas Argh you are right that it is actually busy looping: https://github.com/espressif/esp-idf/blob/release/v4.4/components/driver/spi_master.c#L983

Yet, I don't see any disabling of the FreeRTOS task scheduler, or holding a critical section. Which means that though the task is busy looping, it can be interrupted by the scheduler by another task with a higher priority (or same prio task due to time-slicing).

So it should still work IMO. A bit not so efficient in terms of CPU power consumption though.

Once we have the async SPI driver merged, as a side effect we'll get interrupt transactions as well though.

[Vollbrecht]

dont forget you are on an FreeRTOS with preemptive scheduling, if the task here has lower prio than some other task you run concurrently this should be preempted on the while loop right?

[ivmarkov]

Changing the title to reflect that DMA support is in place since quite some time. Mainline also now supports async, as well as blocking+non-polling mode.