Support for ESP32 Quad and Octal SPI on SPI2 and SPI3
I have an ESP32S3 project that requires a high bandwidth between the MCU and an external device. The only feature blocking the use of micropython is its lack of support for ESP32's multi-line SPI (Quad and Octal). I looked over the SPI code in ports/esp32 and it looks pretty doable. I'm considering adding it and sending a PR. Before I do so, though, I'm wondering how I should expose it in a module. I think the most sensible thing would be to create a separate esp32.QSPI class (and perhaps an esp32.OctalSPI class).
I'd be interested in hearing what people think.
Thanks!
Support for hardware SD/MMC access on ESP32
This PR implements support for the ESP32's hardware SD/MMC interface. This provides much, much faster access to SD cards. It also implements support for accessing SD cards over an SPI interface using DMA access and the ESP-IDF implementation of the SD/MMC protocol written in C.
The class constructor is designed to have sensible defaults. As a result, on ESP32 modules where the SD Card slot is wired to the usually-free SD/MMC hardware channel, mounting a card is as simple as:
uos.mount(esp32.SDCard(), "/sd")
Using the native implementations of the SD card protocol provides a radical speed-up compared to the soft sdcard.py module. On a TTGO 8 card read speeds of a FAT32 file mounted through VFS are between 25 and 30 times faster (depending on block size) using the hardware SD/MMC interface compared the software SD protocol with software SPI and 12 to 17 times faster than software SD with hardware SPI drivers, exceeding 750K bytes per second. Using the C implementation of the SD card protocol over SPI is typically 12 times faster compared to hardware SPI and the Python SD card protocol. Write speeds are typically 5 to 8 times faster and can exceed 250K bytes per second.
The new SDCard class is added to the existing esp32 module (since the SDCard class for the PyBoard resides in the pyb module). Its inclusion is conditional on the MICROPY_HW_ENABLE_SDCARD macro being set to 1 in mpconfigport.h. The new code adds about 24K bytes to the ROM size but only 192 bytes to the RAM consumption on devices without SPI RAM and zero impact on devices with SPI RAM (I'm not quite sure why it even takes the 192 bytes, since all static variables are const so should be landing in the ROM too). Given that most ESP32 devices are not short of ROM space I would recommend having support switched on by default and the PR includes the appropriate setting in mpconfigport.h.
The PR includes documentation of the new class as part of the ESP32-specific library documentation.