pkg/esp32_sdk: bump to v4.4.2
Contribution description
v4.4.2 is a bugfix release, it should work with only minor changes.
The restart procedure now involves esp_restart_noos() and vTaskSuspendAll(), so add system_internal.c for the former and a dummy implementation for the latter.
Testing procedure
Only tested examples/gnrc_border_router on esp32-wroom-32 so far.
Issues/PRs references
Do you think that it is necessary to test it for all ESP32x SoCs?
Murdock results
:heavy_check_mark: PASSED
3ba39e110d781a2d228543e24c8cdf7c0e542bd2 pkg/esp32_sdk: bump to v4.4.2
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 1991 | 0 | 1991 | 08m:04s |
Artifacts
This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.
What is the hold-up here?
CI was not happy at all
any plans to bump it to v5.0? 👉👈
CI was not happy at all
https://github.com/RIOT-OS/RIOT/pull/18767#issuecomment-1283034312 does not really reflect this :sweat_smile:
I'm not even sure if we have any ESP32 devices included in the Murdock run, AFAIR the build failures were on some of the newer ones.
any plans to bump it to v5.0? 👉👈
I had already started working on it over a year ago, but had to stop my work a year ago for personal reasons. Unfortunately, it is much more than just an upgrade to the next version. Rather, it requires a major rework of the RIOT-OS port to ESP32 due to the extensive changes in ESP-IDF with this major release and the fact that we can't just use it as it is, since ESP-IDF is directly merged with FreeRTOS. This means that we can only use some low-level functions that are not actually usable via the API and have to add some tricks and our own functions to be able to use the ESP32 SoCs at all which is quite difficult due to the undocumented or poorly documented hardware. That is the RIOT-OS port to ESP32 SoCs is quite tricky.
After the break of over a year now, I honestly don't know whether I'll have the time to look at ESP-IDF v5.x in the near future and try the port again. Unfortunately, we need ESP-IDF v5.x to support the newer ESP32 RISC-V SoCs.
I honestly don't know whether I'll have the time to look at ESP-IDF v5.x in the near future and try the port again
Well if you'd like some extra labor power i'd volunteer. it would be educational for me :smile:
My usecase is driving a strip of WS281x neopixels using the RMT module with DMA. The DMA part is currently missing in the WS281x driver in RIOT. I'm considering hacking in DMA support to the neopixel driver somehow, but then it would depend on the outdated ESP sdk that RIOT uses currently, which I'm unsure if it'd be desirable by the core RIOT team.
For reference, DMA support got added to the RMA module in version v5.0 of ESP-IDF/SDK (commit 2fb43820c22)
Any advice/suggestion is welcome!
For reference, DMA support got added to the RMA module in version v5.0 of ESP-IDF/SDK (commit 2fb43820c22)
With PR #21261 we will provide the migration to ESP-IDF v5.4. Unfortunately, the RMT module has been completely redesigned, so I decided to use the legacy driver in the first step and migrate to the new RMT module later :worried:
This PR is now obsolete.