esp-hal

esp-hal copied to clipboard

There is a HAL (more of a POC actually) for the ULP RiscV coprocessor of esp32s2 and (in future) esp32s3, that lives here.

This is a "mini" HAL as it exposes a single peripheral - the RTC pins (and an impl of the embedded-hal Delay trait), but this is still quite useful as the alternative is either to use unsafe code with hard-coded memory addresses (the ones where the pin-related registers are mapped) or (a bit better but still not perfect) to use the register definitions from the upcoming esp32s2/esp32s3 PAC crates.

The need for a "mini" HAL for ULP (RTC gpio pins + a delay utility really) was recognized a bit by the ESP-IDF here in that they have something similar for C code.

Since the ULP HAL is really bare metal, I think it should either live in this crate (likely feature-gated by a ulp feature), or in a separate crate - say - esp32-ulp-hal. Any preferences?

In any case it should depend on the upcoming bare-metal PAC crates for register definitions.

Additionally, the current "mini" HAL does need a startup code in RiscV32 assembly, which also currently lives in the esp-idf-hal here, as well as a startup code in Rust, that lives here. I'm not really sure where that assembly + Rust code belongs, perhaps in some sort of "rt" crate (esp32-ulp-rt ?), but we need to find it a new home as well.

Finally, none of the above is very urgent, but ideally we should solve it sooner or later.

Good point and in fact I thought about support for the ULPs in our bare-metal HAL

• this repository is the place to live for that HAL
• I think that HAL should be its own crate

Ok then shall i pull the existing code into - say - esp-ulp-hal, rebase it on top of the PAC crates and move to the esp-rs org?

Probably yes but maybe let's wait for Jesse's opinion on that (he is not available today but on Monday)

I think this can either be added as a package to the esp-hal repository, or it can live under its own repo in the esp-rs organization. I'm honestly not overly concerned which of these routes we take.

Originally the thought for this repo was to hold all of the HALs in a single place, however this can easily be re-defined to exclude the ULPs (and this definition only really lived in my head to begin with, anyways 😉 ).

I think the ULP should indeed be part of the esp-hal repo. Since we are talking about support for both S2 and S3, I guess I should PR two packages (esp32s2-ulp-hal and esp32s3-ulp-hal)?

Hmmmm... and maybe I'll need esp-ulp-hal-common. Not clear yet.

Sure, sounds good to me. Do what you have to do, nothing is permanent 😁

This has been superseded by #377