Talk more about esp-radio and esp-generate#235
Conversation
Should be probably shortened, just a WIP prototype for now
| | `esp-sync` | Synchronization primitives for Espressif devices. | Unstable | | ||
| | `esp-storage` | Storage utilities for Espressif devices. | Unstable | | ||
| | `esp-radio` | Wi‑Fi, BLE, IEEE 802.15.4, and ESP‑NOW functionality for Espressif devices. | Unstable | | ||
| | `esp-radio` | Wi‑Fi, BLE, IEEE 802.15.4, and ESP‑NOW functionality for Espressif devices. | Stable | |
There was a problem hiding this comment.
I wouldn't mark esp-radio as stable :D
There was a problem hiding this comment.
That's what initial issue says, but I agree with you 🤔
Maybe we should do it after we officially stabilize it 😄
There was a problem hiding this comment.
We can add another issue to do this, if we want to close #230 - just please open it here, then add esp-rs/esp-hal#4448 as the parent issue.
SergioGasquez
left a comment
SergioGasquez
left a comment
There was a problem hiding this comment.
Looks good to me, maybe I will keep the explanation shorter with less examples/details.
|
|
||
| `esp-generate` provides more than dependency selection: it applies a known set of crates and feature combinations corresponding to the chosen template options, reducing the amount of manual configuration required to produce a working project. | ||
|
|
||
| Enabling various options may add additional crates to `Cargo.toml` of the generated project. Certain capabilities require supporting libraries to function correctly. The templates aim to keep the dependency set minimal while ensuring the generated project is functional and immediately runnable. |
There was a problem hiding this comment.
| Enabling various options may add additional crates to `Cargo.toml` of the generated project. Certain capabilities require supporting libraries to function correctly. The templates aim to keep the dependency set minimal while ensuring the generated project is functional and immediately runnable. | |
| Enabling various options may add additional crates to `Cargo.toml` of the generated project. The templates aim to keep the dependency set minimal while ensuring the generated project is functional and immediately runnable. |
playfulFence
changed the title
esp-radio and esp-generateesp-radio and esp-generate
|
|
||
| Enabling various options may add additional crates to `Cargo.toml` of the generated project. The templates aim to keep the dependency set minimal while ensuring the generated project is functional and immediately runnable. | ||
|
|
||
| Wireless connectivity provided by `esp-radio`, as stated in [Ancillary Crates](../../introduction/ancillary-crates.md) chapter, relies on `esp-rtos`. For this reason, enabling Wi-Fi or BLE causes `esp-generate` to include this crate and configure it with the `esp-radio` feature, providing the scheduling and runtime integration required for reliable operation. When Embassy support is enabled, `esp-rtos` also serves as the integration point for async execution on supported chips, with a corresponding feature enabled in the template project. For IP networking, the templates include the surrounding networking components. This typically includes `smoltcp`, `embassy-net` for async networking, when Embassy is enabled. |
There was a problem hiding this comment.
This paragraph is weird, it's not about the tool, but the crates...
There was a problem hiding this comment.
Hmm 🤔
Not sure I agree with this... Like, this text explicitly tells what is being included by esp-generate by enabling different features for a generated project, IMO this describes the tool behaviour pretty well
There was a problem hiding this comment.
I think I agree with @bugadani - it's too much details IMHO
I guess it's enough to tell users that it will setup a "fully-functional" skeleton with a minimal set of crates needed and the necessary features enabled but if I imagine being a newbie reading this (i.e. being into the esp-rs world for one or two hours) this might cause more confusion than it should
| The core crate that ties all work with Espressif chips in Rust is the `esp-hal` crate. Through it, you will be able to perform basic initialization of the chip, as well as access drivers for the peripherals available on the chip. The full [`esp-hal` documentation] for selected chip will give unambiguous information about what peripherals are available to use, and the stability of their respective drivers. | ||
|
|
||
| Furthermore, you may want to use more advanced functionality of the chip. For example, network and connectivity. This part of the ecosystem is the responsibility of `esp-radio`, which combines drivers for the communication protocols available on one or another of Espressif's products: `Wi-Fi`, `BLE`, `esp-now` and low-level `IEEE 802.15.4` for the lower layers of communication. More detailed information for each chip is available in the [`esp-radio` sub-repository]. | ||
| Furthermore, you may want to use more advanced functionality of the chip. For example, network and connectivity. This part of the ecosystem is the responsibility of `esp-radio`, which combines drivers for the communication protocols available on one or another of Espressif's products: `Wi-Fi`, `BLE`, `esp-now` and low-level `IEEE 802.15.4` for the lower layers of communication. More detailed information for each chip is available in the [`esp-radio` sub-repository]. It is also worth mentioning that radio support requires the stack to run continuously in the background (timers, interrupts, state machines). `esp-radio` relies on `esp-rtos` for the scheduling/runtime glue needed to run reliably, and `esp-generate` will add `esp-rtos` automatically when you enable the appropriate template options. |
There was a problem hiding this comment.
esp-radiorelies onesp-rtos
Shouldn't we be more precise? esp-radio relies on any implementation of esp-radio-rtos-driver, we just happen to provide esp-radio as a good enough default.
6 participants
closes #230