ca04263b7b
* RMT: make PulseCode a newtype rather than an extension trait on u32
This has several advantages:
- the meaning of `u32` used as pulse code becomes more explicit
- it allows using `PulseCode` methods in `const` context (which is otherwise
not possible because Rust does not presently support associated const
fn in traits).
- it allows providing custom `defmt::Format` and `core::fmt::Debug` impls
for `PulseCode`, greatly helping with debugging
I have taken the liberty to implement `core::fmt::Debug` in a slightly
non-standard way: The most natural implementation would probably use a
struct-style output like
PulseCode { length1: 42, level1: Level::High, length2: 24, level2: Level::Low }
However, that is very lengthy and not really human-readable anymore when
dealing with an array of `PulseCode`s. Thus, this uses the more compact format
PulseCode(H 42, L 24)
This provides `u32: From<PulseCode>` and `PulseCode: From<u32>` impls and
converts rx and tx methods to accept `impl Into<PulseCode>` and
`impl From<PulseCode>`, respectively.
This should help to reduce how much user code needs to change (but replacing
`u32` type annotations with `PulseCode` will be required).
By applying `#[repr(transparent)]` to `struct PulseCode`, it is
guaranteed to match the layout of `u32` such that accessing the hardware
buffer via `*mut PulseCode` pointers is valid.
* RMT: Address review on PulseCode refactor, further refine the interface a bit
- introduce Level::const_from and Level::const_into
- pre-compute a few more shifts and masks (this is unlikely to affect
generated code, since the compiler would have const propagated them
anyway, but it helps to keep the PulseCode impl more readable)
- improve docstrings
- remove PulseCode::empty in favor of PulseCode::default, keep
PulseCode::end_marker for now (but it's not completely clear that this
interface is optimal; see also the FIXME note on adding a variant of
this methods that supports settings levels and length1)
- make PulseCode::new_unchecked pub and shuffle it around in the code so
that it doesn't show up first in the docs
- factor out PulseCode::symbolX methods for internal use in debug
formatting
- sprinkle a few more #[inline] to be totally sure that this really adds
no overhead over having plain u32
- convert methods receivers from &self to self given that PulseCode is
Copy (which probably doesn't matter much since all these methods
should always be inlined)
- remove PulseCode::as_u32() and make the tuple field pub: There's no
safety implication of marking this pub, and field access still
provides a const-compatible way to obtain the wrapped value
esp-hal
Bare-metal (no_std) hardware abstraction layer for Espressif devices. Currently supports, to varying degrees, the following devices:
- ESP32 Series: ESP32
- ESP32-C Series: ESP32-C2, ESP32-C3, ESP32-C6
- ESP32-H Series: ESP32-H2
- ESP32-S Series: ESP32-S2, ESP32-S3
Additionally provides limited support for programming the low-power RISC-V cores found on the ESP32-C6, ESP32-S2, and ESP32-S3 via the esp-lp-hal package.
For additional information regarding any of the crates in this repository, please refer to the relevant crate's README.md file. If you have any questions, comments, or concerns, please open an issue, start a new discussion, or join us on Matrix.
If you are currently using (or considering using) esp-hal in a production environment and have any feedback or require support, please feel free to contact us at rust.support@espressif.com.
Note
This repository includes crates that are at various stages of maturity and stability. While many functionalities have already been implemented and are usable for most tasks, certain advanced or less common features may still be under development. Each crate may offer different levels of functionality and guarantees.
Getting Started
For information relating to the development of Rust applications on ESP devices, please first read The Rust on ESP Book.
For information about the HAL and how to use it in your own projects, please refer to the documentation.
When browsing the examples, we recommend viewing the tag for the esp-hal release you are using to ensure compatibility, e.g. esp-hal-v1.0.0-beta.0, as the main branch is used for development and APIs may have changed in the meantime.
Resources
- The Rust Programming Language
- The Embedded Rust Book
- The Embedonomicon
- The Rust on ESP Book
- Embedded Rust (no_std) on Espressif
Contributing
We have a number of living documents to aid contributing to the project, please give these a read before modifying code:
License
All packages within this repository are licensed under either of:
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution notice
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.