710a0b996f
* RMT: Remove duplicate conditionals
The next check,
config.memsize > NUM_CHANNELS - T::CHANNEL
just below includes this case and exits with the same error.
* RMT: move chip-specific code to chip_specific modules
Moves configure_clock and clear_memsizes from Rmt methods to the chip_specific
sub-modules:
- configure_clock dispatches to functions from chip_specific anyway,
using the same #cfg attributes as the chip_specific module
- clear_memsizes also uses the same #cfg attributes, and it deals with
low-level register access, which is generally contained in the chip_specific
module
* RMT: small refactor of divider calculation using let-else
The same check as before, but slightly more concise, and getting rid of
the explicit cast.
* RMT: simplify is_memory_blocks_available and set_memory_blocks_unavailable
by removing unnecessary checks for special-case values that actually behave the
same as the general case that is handled in the loops
* RMT: merge is_memory_blocks_available and set_memory_blocks_unavailable
Both are only used in conjunction anyway.
There's a TOCTOU issue here: ChannelCreator is Send + Sync, so it can be
used from ISR context or on different cores for multicore targets.
This commit does not address that yet, but is a first step to fixing the
race condition, which would require making the check-then-modify atomic
(atomic per channel would probably be sufficient).
* RMT: move reserve_memory from trait to chip_specific module
Mainly, this also fixes incorrect indexig of ch_tx_conf0, ch_rx_conf0
for some chips (esp32s3, esp32c3, ...).
It also allows for some deduplication of the logic in reserve_memory.
Generally, since this function deals with the collection of all channels
rather than just a single one, it feels more natural to move it to the
module rather than the per-channel trait.
* RMT: avoid race condition via critical_section
This is not a great solution, but resolving this in a better way seems
to require more design work: The PAC crates don't seem to provide atomic
CAS operations on registers, thus it is not easily possible to reserve
the memory belonging to another channel than the current one without
causing a race condition: Another channel could be used to concurrently
reserve the same memory, either from an ISR context, or from another
core on multi-core chips.
* RMT: Release channel RAM on Channel drop
This should allow it to be re-used, either by other subsequent channels,
or by the initial channel if it was used for a non-'static lifetime and
is re-initialized.
* RMT: add global STATE and use it to control channel RAM access
Right now, this removes the use of critical_section previously
introduced as a stopgap solution to a race condition.
It will generally be useful to track state in a global static atomic for adding
fully interrupt-driven transfers later on.
* RMT: Fix regression form #3292 where tx transaction doesn't write
enough data
The idea is to fill half of the available RAM in on each threshold
event. Increasing the amount of available RAM in this calculation was
forgotten when adding support for extended channel RAM.
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.