esp-rs Organization Inventory

The purpose of this document is to help us decide where to focus our development efforts, while not abandoning projects and leaving the community to fend for themselves. It may make sense to move some libraries into larger repositories, e.g.) many bare-metal libraries could live in `esp-hal`. Whether or not we want to do this is up for discussion, and how far we will take this will need some debating. There will need to be some discussion with the community about what to do with certain repos, e.g.) the `esp-idf-*` repos. **NOTE:** Some repos have been filtered out, generally because they do not contain any Rust. (These columns are referring to the *repositories*, not the *projects*) | Repo | Archive? | Maintenance? | Keep? | Move? | | :---------------------------: | :------: | :----------: | :---: | :---: | | esp-hal | | | ✅ | | | esp-idf-svc | | | ✅ | | | esp-idf-sys | | | ✅ | | | esp-idf-hal | | | ✅ | | | espup | | | ✅ | | | esp-openthread | | | ✅ | ?* | | esp-pacs | | | ✅ | | | espflash | | | ✅ | | | esp-wifi | | | | ?* | | esp-idf-template | | | ✅ | | | xtensa-lx | | | ✅ | | | esp-backtrace | | | | ✅ | | std-training | | | ✅ | | | no_std-training | | | ✅ | | | esp-template | | | ✅ | | | esp-mbedtls | ? | | X**** | | | embedded-svc | | ?** | ✅ | | | esp-ieee802154 | | | | ✅ | | esp-println | | | | ✅ | | esp-flasher-stub | | | ? | | | esp-storage | | | | ✅ | | esp-flash-loader | | | ✅ | | | esp-idf-part | | | ✅ | into espflash? | | embuild | | | ✅ | ? | | esp-web-flash-server | ? | looks unmaintained? | X | | | esp-wireless-drivers-3rdparty | | Upstream isn't being maintained: https://github.com/espressif/esp-wireless-drivers-3rdparty why? | ✅ | | | xtensa-toolchain | | | ✅ | | | riscv-atomic-emulation-trap | ? | | | ?*** | | xtensa-atomic-emulation-trap | ? | | | ?*** | | espmonitor | ✅ | | X | X | | esp-serial-dbg | ? | merge into espflash? | X | | |esp-rs-compat/synopsys-usb-otg | | | ✅ | | | _* Move `esp-wifi` into `esp-hal` repository, but keep `esp-wifi-sys` separate_ _\*\* See: https://github.com/esp-rs/embedded-svc/issues/72_ _\*\*\*: Move to rust-embedded-community_ _\*\*\*\*: We need to provide the same example with RustTLS_ ## Changes - `esp-alloc` package has been moved into the `esp-hal` repository, `esp-alloc` repository was archived ## Opinions If you have any opinions regarding the fate of a specific repository, please leave some notes below detailing them. ### Bjoern - I could imagine moving these to esp-hal - esp-println - esp-backtrace - esp-wifi (minus esp-wifi-sys) - esp-storage - esp-alloc - Candidates for archiving - esp-serial-dbg .... no one ever used it but actually I sometimes look into the code since there are a few intersting things I need from time to time - esp-mbedtls - we should somewhere have a working example using Rustls (showing the same things the examples in esp-mbedtls do) and then we could retire it or maybe transfer ownership to Anthony if he wants it (he is somewhat active on the repo). Probably we should also have an example using embeddedTLS While esp-ieee802154 and esp-openthread seem like a burden I think both will become much more important so we probably should get a bit more serious about them. I have a few things (examples/POCs) on my personal GitHub space which might be useful to users. We had an idea to have a repo with examples like that. That might remind us to update those examples more frequently. e.g. - https://github.com/bjoernQ/s3box-sound - https://github.com/bjoernQ/esp32c3-ble-hid - https://github.com/bjoernQ/es8311-rs - https://github.com/bjoernQ/ps2keyboard-esp32c3 (not sure but at least sometimnes people refer to it) - https://github.com/bjoernQ/rust-esp32s3-ili9341 - https://github.com/bjoernQ/esp32-rust-nostd-temperature-logger - https://github.com/bjoernQ/esp32c3-ota-experiment - https://github.com/bjoernQ/esp32c3-ble-provisioning-experiment - https://github.com/bjoernQ/esp32s3-hid-example Some of these are in a bad shape and would need some more work ### Jesse - I personally think many of the bare-metal libraries can probably be moved into `esp-hal`, though I'd like to it free of blobs if it's practical to do so. - This reduces friction when making updates, IMO - Perhaps we can keep `esp-ieee802154` in a separate repo, and the `esp-wifi` repo can turn into `esp-wifi-sys` or something, and we can move `esp-wifi` (the library) into `esp-hal`? - I know I resisted this in the past, but as long we keep the blobs out I am starting to think maybe this is for the best? - Given our current infrastructure for automation/testing, I think it'd be easy to just include Wi-Fi examples with the rest of our existing examples - Some repos (like the `*-atomic-emulation-trap` repos, specifically) should be put in maintenance mode, or archived altogether - `espmonitor` appears to be unmaintained, but we've also never really been involved with that repo so I feel a bit weird making a decision about it... ### Juraj ### Kirill ### Sergio - I like the idea of merging `esp-println`, `esp-backtrace` and `esp-wifi` (leaving blobs on its own repo) into `esp-hal` - `esp-web-flash-server` could probably be archived. Its useful to flash from containers, but I dont think its being used by anyone, it doesnt even support all the targets. - I would suggest keeping `esp-template` as its very useful for generating new projects. - Same for `esp-idf-template` but I guess this is influenced with what we decide to do with the rest of the `esp-idf-*` crates - Trainnings are also worth keeping IMO. They require some maintenance and updating, but they still provide a lot of value for newbies. ### Scott - Oops I kinda already updated some of the table before seeing this, sorry! - I marked the esp-idf-* crates as keep - I think generally, anything without a blob/sys and is esp-hal related, can be moved into esp-hal - Anything with a blob/sys _could_ be split and the pure Rust part moved to esp-hal where it makes sense - 802.15.4, merge the svd into the chip svd? - I'm not sure if we have any Rust specific special purpose, but if esp-wireless-drivers-3rdparty was updated regularly upstream could we use that instead of our own? - I think that mbedtls has to exist until we can do more than basic things with embedded-tls, after that we can decide what to do with it