esp-hal vs esp-idf-hal for EV telematic application

[0xkelvin]

We are working on esp32c6 for telematic features in our VCU ( Vehicle Control Unit)
Basically, esp32c6 is needs to communicate with LTE module, bunch of sensors via I2C, ADC, UART and communicate with other module on system via CAN bus.

and we want to use Embassy as well. At some first steps, we realise that esp-hal is easier to start, but a bit worries : whether esp-hal is good enough - what are the advantages of esp-idf-hal compare with esp-hal ? what are the aspect do i need to consider ?

Very appreciate for any comments, i am quite new here.

[bjoernQ]

Just my very personal opinion and I'm biased since I'm working on esp-hal:

esp-idf-hal is basically a Rust wrapper over functionality provided by esp-idf. esp-idf is really battle tested and supports even more "exotic" configurations. esp-idf also supports pretty much everything the chips are capable of. Rust on top of esp-idf even supports the Rust-Standard-Library.

esp-hal is a somewhat young implementation on bare-metal. There are some gaps in supported functionality and the API might currently see breaking changes from release to release (there are some refactorings in the pipeline which definitely will be breaking changes - also we are constantly trying to improve the APIs for useability). esp-hal does not support the Rust-Standard-Library.

Given that, it sounds like esp-idf-hal is always preferable but that's (in my opinion) not the whole truth.

esp-hal is all Rust (besides some ROM functions used) and a relatively small code-base. It evolves quite quickly and making contributions to fix a bug or add missing functionality is doable with reasonable effort. Especially when targeting embedded devices the absence of Rust-std support shouldn't be a huge problem. Crates created and suitable for embedded devices usually take that in account and are no-std / no-alloc. If needed alloc is also supported when using esp-hal

esp-idf-hal sooner or later requires a deep understanding of the underlying esp-idf which is a full-blown RTOS (written in C/C++, based on FreeRTOS) with thousands of configuration options to tailor things exactly to your needs. It comes with a flexible build-system which lets you tweak things a lot. All this comes with its own complexity.
Using Rust on top of esp-idf makes the build considerably more complex.

Support for std might make it possible to use some crates which need support for it but often times those are not implemented with the resource constraints of embedded devices in mind (some crates might try to allocate megabytes of RAM, make assumptions about the performance of the CPU etc.).

Given your requirements we can at least put a checkmark on everything for esp-hal. But it really depends on the very details.

• I2C is supported - async and non-async
• ADC is supported for one-shot readings, we are missing advanced functionality there currently, e.g. continuous reading, DMA, threshold monitoring are not yet supported
• UART is supported - async and non-async
• CAN/TWAI is supported and tested at least for C3 and S3 - it should also work for C6 (but pretty much untested), there is a pending PR to add async support as well (not sure when that will be in a mergeable state)

There is also the option to start with one of the HALs and later switch (with some effort) to the other by moving everything possible into a HAL independent crate. How feasible that is in reality heavily depends on the project itself and probably on the Rust experience of the team. Switching from esp-hal to esp-idf-hal might however be quite some effort - the other way around might be even harder or almost impossible if Rust-std features are heavily used.

As said: Those are just my personal thoughts on this. I am quite sure others have a completely different view on these things

[0xkelvin]

Really thanks for your insightful ! it is really help us on the direction, but anyway more or less me and my team have a answer for us from your points.

thanks a lot