This commit updates the esp32 port to work exclusively with ESP-IDF v5.
IDF v5 is needed for some of the newer ESP32 SoCs to work, and it also
cleans up a lot of the inconsistencies between existing SoCs (eg S2, S3,
and C3).
Support for IDF v4 is dropped because it's a lot of effort to maintain both
versions at the same time.
The following components have been verified to work on the various SoCs:
ESP32 ESP32-S2 ESP32-S3 ESP32-C3
build pass pass pass pass
SPIRAM pass pass pass N/A
REPL (UART) pass pass pass pass
REPL (USB) N/A pass pass N/A
filesystem pass pass pass pass
GPIO pass pass pass pass
SPI pass pass pass pass
I2C pass pass pass pass
PWM pass pass pass pass
ADC pass pass pass pass
WiFi STA pass pass pass pass
WiFi AP pass pass pass pass
BLE pass N/A pass pass
ETH pass -- -- --
PPP pass pass pass --
sockets pass pass pass pass
SSL pass ENOMEM pass pass
RMT pass pass pass pass
NeoPixel pass pass pass pass
I2S pass pass pass N/A
ESPNow pass pass pass pass
ULP-FSM pass pass pass N/A
SDCard pass N/A N/A pass
WDT pass pass pass pass
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This follows up on #5489, where we changed the esp32 core pinning to core 0
in order to work around an issue with IDF < 4.2.0. Now that IDF > 4.2.0 is
available, we allow pinning back to core 1, which eliminates some
problematic callback latency with WiFi enabled.
NimBLE is also pinned to core 1 - the same core as MicroPython - when using
IDF >=4.2.
MicroPython and NimBLE must be on the same core, for synchronisation of the
BLE ringbuf and the MicroPython scheduler. However, in the current IDF
versions (3.3 and 4.0) there are issues (see e.g. #5489) with running
NimBLE on core 1.
This change - pinning both tasks to core 0 - makes it possible to reliably
run the BLE multitests on esp32 boards.
This prevents issues with concurrent access to the ringbuf.
MICROPY_BEGIN_ATOMIC_SECTION is only atomic to the same core. We could
address this with a mutex, but it's also not safe to call mp_sched_schedule
across cores.
This avoids a confusing ENOMEM raised from gap_advertise if there is
currently an active connection. This refers to the static connection
buffer pre-allocated by Nimble (nothing to do with MicroPython heap
memory).
