esp-rs
RFC: Decouple `embassy` support from `esp-hal`
As things stand, we have a strong coupling to the embassy ecosystem in esp-hal. This has always struck me as a bit odd, and probably not quite "right", but for the sake of development we've continued to support embassy in-tree. This has also repeatedly caused delays where we need to wait for embassy to update and release various packages, which interferes with the HAL release cycle.
I propose that embassy support should be decoupled into a separate package, eg. esp-hal-embassy; if we continue to support other RTOS/frameworks in the future (which I would like to!), I don't want to continue accumulating cruft in the HAL.
I had taken a swing at doing this in https://github.com/esp-rs/esp-hal/pull/976 already, however some concerns were raised that I feel we don't have solutions for currently. Didn't seem like that PR was going to get merged so I've closed it for the time being. For more context please refer to the aforementioned PR.
So, I'd like to open discussion on how we can move forward to accomplish this task.
In general, it probably makes sense to move that code into its own crate
Ideally the user would only need to add one dependency and we re-export relevant things from here.
Problem might be: https://github.com/esp-rs/esp-hal/pull/976#issuecomment-1833696150
On the other hand one dependency more or less doesn't make much of a difference probably. The bigger problem for users might be to choose the right features and make sure to not pull incompatible versions. Might be solvable via documentation and/or esp-template
IMO decoupling make sense. If we consider OS metaphore for Embassy, we can see that similar metaphore has been aplied to std with ESP-IDF which is also viewed as OS - FreeRTOS in this case. We could take also Zephyr and NuttX into consideration as OSes where Rust can run. Other OSes in this case might be derrived from sytems TockOS. It's question whether such generic principle could be found for all theses OSes. Yet, at least exploration of Embassy as OS makes sense.
I think once my next Timer abstraction PR lands we'll be in pretty good shape for this, so going to pick it back up soon.