Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkg/esp32_sdk: bump to v4.4.2 #18767

Closed
wants to merge 2 commits into from
Closed

Conversation

benpicco
Copy link
Contributor

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

@benpicco benpicco requested a review from gschorcht as a code owner October 18, 2022 18:21
@github-actions github-actions bot added Area: cpu Area: CPU/MCU ports Area: pkg Area: External package ports Platform: ESP Platform: This PR/issue effects ESP-based platforms labels Oct 18, 2022
@@ -145,6 +145,11 @@ void vTaskSuspend(TaskHandle_t xTaskToSuspend)
}
}

void vTaskSuspendAll(void)
{
/* TODO */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we will ever be able to implement it in on top of the RIOT scheduler.

@gschorcht gschorcht added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation labels Oct 18, 2022
@gschorcht
Copy link
Contributor

Do you think that it is necessary to test it for all ESP32x SoCs?

@riot-ci
Copy link

riot-ci commented Oct 18, 2022

Murdock results

✔️ PASSED

3ba39e1 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.

@benpicco benpicco added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 26, 2022
@miri64
Copy link
Member

miri64 commented Nov 26, 2024

What is the hold-up here?

@benpicco
Copy link
Contributor Author

CI was not happy at all

@IsikcanYilmaz
Copy link
Contributor

any plans to bump it to v5.0? 👉👈

@miri64
Copy link
Member

miri64 commented Nov 26, 2024

CI was not happy at all

#18767 (comment) does not really reflect this 😅

@benpicco
Copy link
Contributor Author

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.

@gschorcht
Copy link
Contributor

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.

@IsikcanYilmaz
Copy link
Contributor

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 😄

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!

@gschorcht
Copy link
Contributor

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 😟

@benpicco
Copy link
Contributor Author

benpicco commented Mar 4, 2025

This PR is now obsolete.

@benpicco benpicco closed this Mar 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: cpu Area: CPU/MCU ports Area: pkg Area: External package ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ESP Platform: This PR/issue effects ESP-based platforms State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants