[Firmware] Use esp-idf instead about slimevr-rust HOT 5 CLOSED

I'm intentionally not targetting ESP-IDF. Here was the rationale:

• Want to minimize pressure on the allocator. Whenever possible we want to use crates that don't even need alloc. We still ship a global allocator just in case but honestly I may remove even that - we haven't had a use for it yet. I could write my code as no_std and run it on std, but its a lot more likely that my dependencies will be using the allocator or more expensive OS primitives like threading etc.
• I want to be able to understand the entire tech stack of the firmware. This is because when there are bugs in dependencies (and there frequently are!) I want to be able to submit a PR to those dependencies to fix them. So far I've found that I have been able to fix issues in dependencies without too much effort because those dependencies have been written in rust, and are small and modular. ESP-IDF is neither of these things. I tried for months initially to port the official SlimeVR firmware to arduino running on top of esp-idf, and it was simply impossible due to the complexity of the tech stack - I never knew if the problem was in the hardware, my code, esp-idf, the configuration of esp-idf, arduino core, arduino library, or platformio. Now arduino on the esp32c3 is much more stable/usable, but it really drew attention to the importance of being able to fix bugs in the underlying tech stack.
• I want first-class support for rust build tools. This means a cargo build should work without requiring cmake, python, esp-idf installation, etc. I want to be able to use tools like cargo espflash and cargo embed also, when available.
• I want to not only target the esp32, but really any device with embedded-hal and that embassy-executor runs on (which is pretty much everything). I recently merged some PRs that added initial nrf52840 support, and this was painless due to the careful isolation of platform-specific code that has been a design goal from the start.
• I wanted the learning experience of no_std and avoiding alloc when possible, to improve my familiarity with bare metal code.

Hopefully this explains why I am looking to build on no_std and embassy instead of an RTOS, or std rust on top of an RTOS. Let me know if you have any questions! Do note however that these design goals are unlikely to change.

from slimevr-rust.

Yeah but it wont help for other architectures :/, any ideas?

from slimevr-rust.

@ImUrX Indeed this will trap us into the Espressif ecosystem. What I would suggest is to put portable code into a core crate and so we can still use other kernels if we can flock to a better ecosystem

from slimevr-rust.

@TheButlah Ah I see...I used to think that you are doubting that Espressif can provide a good ground for future either as they are based in China and US sanction can come in their way but seems like I guessed it all wrong...And the truth instead, you take this as a learning opportunity and for portability sake rather than taking it pragmatic (and maybe dramatic too).

from slimevr-rust.

doubting that Espressif can provide a good ground for future

Quite to the contrary - this codebase heavily relies upon the incredible work done by both official espressif employees and other members of the community from esp-rs. The espressif team has done a lot to make rust work well on their chips, and are extremely responsive to the community, as well as PRs that I submit to their crates.

Anyway, I'm going to mark this issue as closed, but feel free to ask any further clarifying questions.

from slimevr-rust.