-
Notifications
You must be signed in to change notification settings - Fork 226
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
Support ESP-IDF Rust Target (for ESP32-C3 especially) #379
Comments
Does ESP32 have an OS we can target? |
@Thomasdezeeuw Uh, yes and no. ESP32 is a family of single board computers which is of course bare metal and no_std, but the ESP-IDF development kit, does feature FreeRTOS on with couple more such as a Virtual filesystem component - ESP32 - — ESP-IDF Programming Guide latest documentation (espressif.com), and some people hacked together to introduce standard library support around the ESP-IDF ecosystem, see STD support for the ESP-IDF framework by ivmarkov · Pull Request #87666 · rust-lang/rust (github.com). Notice ESP-IDF is best coupled with ESP32-C3 right now, which is easily obtainable from every corner of the world at any part of the world for around $7. While the arcanish ESP-IDF target does mean that some level of OS support (in the sense of a RTOS, however), meaning things like To me specifically I'm experimenting smol-rs/smol: A small and fast async runtime for Rust (github.com) on ESP32-C3 and I was successful to some degree, yet here this specific |
Socket2 is wrapper around the OS's network stack, i.e. it just wraps
We don't need too much from std lib, some types from
I'm not too familiar with smol or async-net/io my self so I can't say much about it. But perhaps it would be easier to simply not compile the networking side on ESP32 targets? Unless you actually need networking. If you do need networking then we need good libc support and wrappers for various system calls (usually provided by libc). I would start by removing compilation of everything that isn't available at the moment and start slowing adding things that are available. |
Since this target doesn't (seem to) have an OS we won't support it in Socket2. |
This seems relevant: afeb723. It's a patch to make socket2 work on espidf. Apologies for tagging you, @ivmarkov is this something upstreamable? Or is it better to keep it in the esp-rs-compat org? For more context, I'm having trouble compiling https://github.com/project-chip/matter-rs for an esp32-c3 device. |
From my point of view it's Ok to upstream, ideally with a CI (at least with
|
I was always planning to upstream that. The one thing holding me off from doing it during the last couple of months was that in the meantime, the mainline of @Thomasdezeeuw - would you accept two PRs then? One for the As for running |
Yes, but please send it to target v0.5.x first and then we can backport that. Btw I'm going to try and release v0.5 this week(end), so at that point
Running with nightly is fine. You probably want something we use to have for Redox: 14be1bc (the part that's deleted in that commit). |
Hi @Thomasdezeeuw, me again :) I've got a patch ready for the main branch and also the backported patch again v0.4.9 (which is needed because tokio latest appears to still target socket2 0.4.9). I'll post a PR soon once I confirm the master one actually works. |
Smoke tested on esp32c3 dev board. I've also tested a similar patch backported to v0.4.9 with much greater functionality including tokio + mio with other patches I've been working on and it's fully working. Closes rust-lang#379
Smoke tested on esp32c3 dev board. I've also tested a similar patch backported to v0.4.9 with much greater functionality including tokio + mio with other patches I've been working on and it's fully working. Closes #379
Not sure how this got missed in rust-lang#452, it was definitely compiling before. Properly closes rust-lang#379.
This was missed in rust-lang#452 because I wasn't testing with feature="all" enabled for my small socket2 test. For the full tokio integration I was using v0.4.x which didn't need this fix. Properly closes rust-lang#379.
Right now it fails to build:
The text was updated successfully, but these errors were encountered: