Combine the esp-ulp-riscv-hal and esp32c6-lp-hal packages

[jessebraham]

Since we're planning on combining the HAL packages for the HP cores, makes sense to do the same for the LP cores, IMO. There was a fair bit of overlap in the implementations of the GPIO and Delay drivers, so we've been able to eliminate some code there. For the parts that are different, we can just #[cfg()] them off as needed like we already do in esp-hal-common.

I've also implemented the embedded-hal@1.0.0 traits in addition to the 0.2.x traits; both of which can be enabled/disable using features. I have enabled embedded-hal@0.2.x by default for now, because those were the traits which had previously already been implemented, but maybe we want to change this? Anyway, not a huge issue, but something to be aware of.

If anybody has any input regarding the package name or any other implementation details, please let me know!

[Dominaezzz]

There was a fair bit of overlap in the implementations of the GPIO and Delay drivers, so we've been able to eliminate some code there.

This is true now but do the other peripherals the similar registers between the lp and ulp?

I was planning on contributing some drivers to esp-ulp-riscv-hal as I need it for a project but the thought of having to also do esp32c6-lp-hal at the same time (without testing) is a little demotivating. Of course, it's not a big deal if they're similar or if you'd accept PRs for drivers for only one ulp type, but my newbie opinion is to hold off until more drivers are implemented before making the call.

[bjoernQ]

LGTM

[SergioGasquez]

I think we should also update the general README https://github.com/esp-rs/esp-hal?tab=readme-ov-file#low-power-cores

[bjoernQ]

There was a fair bit of overlap in the implementations of the GPIO and Delay drivers, so we've been able to eliminate some code there.

This is true now but do the other peripherals the similar registers between the lp and ulp?

I was planning on contributing some drivers to esp-ulp-riscv-hal as I need it for a project but the thought of having to also do esp32c6-lp-hal at the same time (without testing) is a little demotivating. Of course, it's not a big deal if they're similar or if you'd accept PRs for drivers for only one ulp type, but my newbie opinion is to hold off until more drivers are implemented before making the call.

I think contributing just for the targets you can test is totally fine

I was a bit afraid of merging the HALs, too. Especially for upcoming features which are very different for different the targets (especially interrupt handling) - but on the other hand in esp-hal-common we even target two different architectures

[JurajSadel]

LGTM, thanks for working on this!

[jessebraham]

This is true now but do the other peripherals the similar registers between the lp and ulp?

The S2/S3 ULPs have like 4 peripherals, most of which are already covered or in-progress. The C6 (and soon, the P4) have very similar LP cores with very similar peripherals. These cores are more similar than a lot of the HP cores in esp-hal-common are.

I was planning on contributing some drivers to esp-ulp-riscv-hal as I need it for a project but the thought of having to also do esp32c6-lp-hal at the same time (without testing) is a little demotivating. Of course, it's not a big deal if they're similar or if you'd accept PRs for drivers for only one ulp type, but my newbie opinion is to hold off until more drivers are implemented before making the call.

We have never required people implement drivers for all supported devices, we have multiple drivers in esp-hal-common which are implemented for some devices but not others already, so this should not be an issue.