Make cargo xfmt respect the format config (#3739)

* Make cargo xfmt respect the format config

* Make sure comments and doc code have the same width
This commit is contained in:
Dániel Buga 2025-07-03 10:18:02 +02:00 committed by GitHub
parent 9146407573
commit 517b5ccbe2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
72 changed files with 398 additions and 441 deletions

View File

@ -268,10 +268,8 @@ impl HeapRegion {
///
/// # Safety
///
/// - The supplied memory region must be available for the entire program
/// (`'static`).
/// - The supplied memory region must be exclusively available to the heap
/// only, no aliasing.
/// - The supplied memory region must be available for the entire program (`'static`).
/// - The supplied memory region must be exclusively available to the heap only, no aliasing.
/// - `size > 0`.
pub unsafe fn new(
heap_bottom: *mut u8,
@ -412,18 +410,17 @@ impl EspHeap {
///
/// - Memory is allocated from the first suitable memory region first
///
/// - The heap grows "upwards", towards larger addresses. Thus `end_addr`
/// must be larger than `start_addr`
/// - The heap grows "upwards", towards larger addresses. Thus `end_addr` must be larger than
/// `start_addr`
///
/// - The size of the heap is `(end_addr as usize) - (start_addr as usize)`.
/// The allocator won't use the byte at `end_addr`.
/// - The size of the heap is `(end_addr as usize) - (start_addr as usize)`. The allocator won't
/// use the byte at `end_addr`.
///
/// # Safety
///
/// - The supplied memory region must be available for the entire program (a
/// `'static` lifetime).
/// - The supplied memory region must be exclusively available to the heap
/// only, no aliasing.
/// - The supplied memory region must be available for the entire program (a `'static`
/// lifetime).
/// - The supplied memory region must be exclusively available to the heap only, no aliasing.
/// - `size > 0`.
pub unsafe fn add_region(&self, region: HeapRegion) {
critical_section::with(|cs| {

View File

@ -162,8 +162,7 @@ fn parse_configs(
// Get the metadata of the project to
// - discover configurable crates
// - get the active features on crates (e.g. to guess the chip the project is
// targeting)
// - get the active features on crates (e.g. to guess the chip the project is targeting)
// this might fetch the dependencies from registries and/or git repositories
// so this
// - might take a few seconds (while it's usually very quick)

View File

@ -89,8 +89,8 @@ This will use software-interrupt 3 which isn't available for anything else to wa
///
/// - a [StaticCell](https://docs.rs/static_cell/latest/static_cell/) (safe)
/// - a `static mut` (unsafe, not recommended)
/// - a local variable in a function you know never returns (like `fn main()
/// -> !`), upgrading its lifetime with `transmute`. (unsafe)
/// - a local variable in a function you know never returns (like `fn main() -> !`), upgrading
/// its lifetime with `transmute`. (unsafe)
///
/// This function never returns.
pub fn run(&'static mut self, init: impl FnOnce(Spawner)) -> ! {

View File

@ -95,17 +95,15 @@ impl Alarm {
/// We are free to choose how we implement these features, and we provide
/// three options:
///
/// - If the `generic` feature is enabled, we implement a single timer queue,
/// using the implementation provided by embassy-time-queue-driver.
/// - If the `single-integrated` feature is enabled, we implement a single timer
/// queue, using our own integrated timer implementation. Our implementation
/// is a copy of the embassy integrated timer queue, with the addition of
/// clearing the "owner" information upon dequeueing.
/// - If the `multiple-integrated` feature is enabled, we provide a separate
/// timer queue for each executor. We store a separate timer queue for each
/// executor, and we use the scheduled task's owner to determine which queue
/// to use. This mode allows us to use less disruptive locks around the timer
/// queue, but requires more timers - one per timer queue.
/// - If the `generic` feature is enabled, we implement a single timer queue, using the
/// implementation provided by embassy-time-queue-driver.
/// - If the `single-integrated` feature is enabled, we implement a single timer queue, using our
/// own integrated timer implementation. Our implementation is a copy of the embassy integrated
/// timer queue, with the addition of clearing the "owner" information upon dequeueing.
/// - If the `multiple-integrated` feature is enabled, we provide a separate timer queue for each
/// executor. We store a separate timer queue for each executor, and we use the scheduled task's
/// owner to determine which queue to use. This mode allows us to use less disruptive locks around
/// the timer queue, but requires more timers - one per timer queue.
pub(super) struct EmbassyTimer {
/// The timer queue, if we use a single one (single-integrated, or generic).
#[cfg(single_queue)]

View File

@ -15,17 +15,15 @@
//! optimized memory usage and precise handling of hardware interrupts.
//!
//! Key Components:
//! - [`handler`](macro@handler) - Attribute macro for marking interrupt
//! handlers. Interrupt handlers are used to handle specific hardware
//! interrupts generated by peripherals.
//! - [`handler`](macro@handler) - Attribute macro for marking interrupt handlers. Interrupt
//! handlers are used to handle specific hardware interrupts generated by peripherals.
//!
//! - [`ram`](macro@ram) - Attribute macro for placing statics and functions
//! into specific memory sections, such as SRAM or RTC RAM (slow or fast)
//! with different initialization options. See its documentation for details.
//! - [`ram`](macro@ram) - Attribute macro for placing statics and functions into specific memory
//! sections, such as SRAM or RTC RAM (slow or fast) with different initialization options. See
//! its documentation for details.
//!
//! - [`embassy::main`](macro@embassy_main) - Creates a new `executor` instance
//! and declares an application entry point spawning the corresponding
//! function body as an async task.
//! - [`embassy::main`](macro@embassy_main) - Creates a new `executor` instance and declares an
//! application entry point spawning the corresponding function body as an async task.
//!
//! ## Examples
//!
@ -71,11 +69,10 @@ mod switch;
///
/// - `rtc_fast`: Use RTC fast RAM.
/// - `rtc_slow`: Use RTC slow RAM. **Note**: not available on all targets.
/// - `persistent`: Persist the contents of the `static` across resets. See [the
/// section below](#persistent) for details.
/// - `zeroed`: Initialize the memory of the `static` to zero. The initializer
/// expression will be discarded. Types used must implement
/// [`bytemuck::Zeroable`].
/// - `persistent`: Persist the contents of the `static` across resets. See [the section
/// below](#persistent) for details.
/// - `zeroed`: Initialize the memory of the `static` to zero. The initializer expression will be
/// discarded. Types used must implement [`bytemuck::Zeroable`].
///
/// Using both `rtc_fast` and `rtc_slow` or `persistent` and `zeroed` together
/// is an error.
@ -90,11 +87,10 @@ mod switch;
///
/// ### Warnings
///
/// - A system-level or lesser reset occurring before the ram has been zeroed
/// *could* skip initialization and start the application with the static
/// filled with random bytes.
/// - There is no way to keep some kinds of resets from happening while updating
/// a persistent static—not even a critical section.
/// - A system-level or lesser reset occurring before the ram has been zeroed *could* skip
/// initialization and start the application with the static filled with random bytes.
/// - There is no way to keep some kinds of resets from happening while updating a persistent
/// static—not even a critical section.
///
/// If these are issues for your application, consider adding a checksum
/// alongside the data.
@ -182,9 +178,8 @@ pub fn entry(args: TokenStream, input: TokenStream) -> TokenStream {
///
/// The following restrictions apply:
///
/// * The function must accept exactly 1 parameter, an
/// `embassy_executor::Spawner` handle that it can use to spawn additional
/// tasks.
/// * The function must accept exactly 1 parameter, an `embassy_executor::Spawner` handle that it
/// can use to spawn additional tasks.
/// * The function must be declared `async`.
/// * The function must not use generics.
/// * Only a single `main` task may be declared.

View File

@ -12,8 +12,7 @@
//!
//! ## Configuration
//! ECC Accelerator supports:
//! - Two different elliptic curves, namely P-192 and P-256 defined in FIPS
//! 186-3.
//! - Two different elliptic curves, namely P-192 and P-256 defined in FIPS 186-3.
//! - Seven working modes.
//! - Interrupt upon completion of calculation.
//!

View File

@ -14,12 +14,9 @@
//!
//! GPIO has several event channels, and the ETM events that each event
//! channel can generate are:
//! - RISE_EDGE: Indicates that the output signal of the corresponding GPIO has
//! a rising edge
//! - FALL_EDGE: Indicates that the output signal of the corresponding GPIO has
//! a falling edge
//! - ANY_EDGE: Indicates that the output signal of the corresponding GPIO is
//! reversed
//! - RISE_EDGE: Indicates that the output signal of the corresponding GPIO has a rising edge
//! - FALL_EDGE: Indicates that the output signal of the corresponding GPIO has a falling edge
//! - ANY_EDGE: Indicates that the output signal of the corresponding GPIO is reversed
//!
//! ## Examples
//! ### Toggle an LED When a Button is Pressed

View File

@ -82,15 +82,13 @@
//! Peripheral signals and GPIOs can be connected with the following
//! constraints:
//!
//! - A peripheral input signal must be driven by exactly one signal, which can
//! be a GPIO input or a constant level.
//! - A peripheral output signal can be connected to any number of GPIOs. These
//! GPIOs can be configured differently. The peripheral drivers will only
//! support a single connection (that is, they disconnect previously
//! configured signals on repeat calls to the same function), but you can use
//! `esp_hal::gpio::OutputSignal::connect_to` (note that the type is currently
//! hidden from the documentation) to connect multiple GPIOs to the same
//! output signal.
//! - A peripheral input signal must be driven by exactly one signal, which can be a GPIO input or a
//! constant level.
//! - A peripheral output signal can be connected to any number of GPIOs. These GPIOs can be
//! configured differently. The peripheral drivers will only support a single connection (that is,
//! they disconnect previously configured signals on repeat calls to the same function), but you
//! can use `esp_hal::gpio::OutputSignal::connect_to` (note that the type is currently hidden from
//! the documentation) to connect multiple GPIOs to the same output signal.
//! - A GPIO input signal can be connected to any number of peripheral inputs.
//! - A GPIO output can be driven by only one peripheral output.
//!

View File

@ -2,17 +2,14 @@
//!
//! ## Requirements
//!
//! - On devices other than the P4, there is a single interrupt handler. GPIO
//! interrupt handling must not interfere with the async API in this single
//! handler.
//! - Async operations take pins by `&mut self`, so they can only be accessed
//! after the operation is complete, or cancelled. They may be defined to
//! overwrite the configuration of the manual interrupt API, but not affect
//! the interrupt handler.
//! - Manual `listen` operations don't need to be prepared for async operations,
//! but async operations need to be prepared to handle cases where the pin was
//! configured to listen for an event - or even that the user unlistened the
//! pin but left the interrupt status set.
//! - On devices other than the P4, there is a single interrupt handler. GPIO interrupt handling
//! must not interfere with the async API in this single handler.
//! - Async operations take pins by `&mut self`, so they can only be accessed after the operation is
//! complete, or cancelled. They may be defined to overwrite the configuration of the manual
//! interrupt API, but not affect the interrupt handler.
//! - Manual `listen` operations don't need to be prepared for async operations, but async
//! operations need to be prepared to handle cases where the pin was configured to listen for an
//! event - or even that the user unlistened the pin but left the interrupt status set.
//!
//! The user should be careful when using the async API and the manual interrupt
//! API together. For performance reasons, we will not prevent the user handler

View File

@ -658,14 +658,12 @@ impl<'d> Io<'d> {
/// setting for you. Based on your use case, you need to do one of this
/// yourself:
///
/// - Disabling the interrupt enable setting for the GPIO pin allows you to
/// handle an event once per call to [`listen()`]. Using this method, the
/// [`is_interrupt_set()`] method will return `true` if the interrupt is
/// set even after your handler has finished running.
/// - Clearing the interrupt status register allows you to handle an event
/// repeatedly after [`listen()`] is called. Using this method,
/// [`is_interrupt_set()`] will return `false` after your handler has
/// finished running.
/// - Disabling the interrupt enable setting for the GPIO pin allows you to handle an event once
/// per call to [`listen()`]. Using this method, the [`is_interrupt_set()`] method will return
/// `true` if the interrupt is set even after your handler has finished running.
/// - Clearing the interrupt status register allows you to handle an event repeatedly after
/// [`listen()`] is called. Using this method, [`is_interrupt_set()`] will return `false`
/// after your handler has finished running.
///
/// [`listen()`]: Input::listen
/// [`is_interrupt_set()`]: Input::is_interrupt_set
@ -2035,8 +2033,7 @@ impl RtcPinWithResistors for AnyPin<'_> {
/// Set GPIO event listening.
///
/// - `gpio_num`: the pin to configure
/// - `int_ena`: maskable and non-maskable CPU interrupt bits. None to leave
/// unchanged.
/// - `int_ena`: maskable and non-maskable CPU interrupt bits. None to leave unchanged.
/// - `int_type`: interrupt type, see [Event] (or 0 to disable)
/// - `wake_up_from_light_sleep`: whether to wake up from light sleep
fn set_int_enable(gpio_num: u8, int_ena: Option<u8>, int_type: u8, wake_up_from_light_sleep: bool) {

View File

@ -9,11 +9,9 @@
//! Main features:
//!
//! - Standard HMAC-SHA-256 algorithm.
//! - Hash result only accessible by configurable hardware peripheral (in
//! downstream mode).
//! - Hash result only accessible by configurable hardware peripheral (in downstream mode).
//! - Compatible to challenge-response authentication algorithm.
//! - Generates required keys for the Digital Signature (DS) peripheral (in
//! downstream mode).
//! - Generates required keys for the Digital Signature (DS) peripheral (in downstream mode).
//! - Re-enables soft-disabled JTAG (in downstream mode).
//!
//! ## Configuration

View File

@ -976,19 +976,17 @@ impl<'d> I2c<'d, Async> {
/// transaction.
///
/// Transaction contract:
/// - Before executing the first operation an ST is sent automatically. This
/// is followed by SAD+R/W as appropriate.
/// - Data from adjacent operations of the same type are sent after each
/// other without an SP or SR.
/// - Between adjacent operations of a different type an SR and SAD+R/W is
/// sent.
/// - Before executing the first operation an ST is sent automatically. This is followed by
/// SAD+R/W as appropriate.
/// - Data from adjacent operations of the same type are sent after each other without an SP or
/// SR.
/// - Between adjacent operations of a different type an SR and SAD+R/W is sent.
/// - After executing the last operation an SP is sent automatically.
/// - If the last operation is a `Read` the master does not send an
/// acknowledge for the last byte.
/// - If the last operation is a `Read` the master does not send an acknowledge for the last
/// byte.
///
/// - `ST` = start condition
/// - `SAD+R/W` = slave address followed by bit 1 to indicate reading or 0
/// to indicate writing
/// - `SAD+R/W` = slave address followed by bit 1 to indicate reading or 0 to indicate writing
/// - `SR` = repeated start condition
/// - `SP` = stop condition
#[cfg_attr(
@ -1133,19 +1131,17 @@ where
/// Execute the provided operations on the I2C bus.
///
/// Transaction contract:
/// - Before executing the first operation an ST is sent automatically. This
/// is followed by SAD+R/W as appropriate.
/// - Data from adjacent operations of the same type are sent after each
/// other without an SP or SR.
/// - Between adjacent operations of a different type an SR and SAD+R/W is
/// sent.
/// - Before executing the first operation an ST is sent automatically. This is followed by
/// SAD+R/W as appropriate.
/// - Data from adjacent operations of the same type are sent after each other without an SP or
/// SR.
/// - Between adjacent operations of a different type an SR and SAD+R/W is sent.
/// - After executing the last operation an SP is sent automatically.
/// - If the last operation is a `Read` the master does not send an
/// acknowledge for the last byte.
/// - If the last operation is a `Read` the master does not send an acknowledge for the last
/// byte.
///
/// - `ST` = start condition
/// - `SAD+R/W` = slave address followed by bit 1 to indicate reading or 0
/// to indicate writing
/// - `SAD+R/W` = slave address followed by bit 1 to indicate reading or 0 to indicate writing
/// - `SR` = repeated start condition
/// - `SP` = stop condition
///
@ -1825,8 +1821,8 @@ impl Driver<'_> {
/// Configures the I2C peripheral for a write operation.
/// - `addr` is the address of the slave device.
/// - `bytes` is the data two be sent.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `cmd_iterator` is an iterator over the command registers.
fn setup_write<'a, I>(
&self,
@ -1940,10 +1936,10 @@ impl Driver<'_> {
/// Configures the I2C peripheral for a read operation.
/// - `addr` is the address of the slave device.
/// - `buffer` is the buffer to store the read data.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `will_continue` indicates whether there is another read operation
/// following this one and we should not nack the last byte.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `will_continue` indicates whether there is another read operation following this one and
/// we should not nack the last byte.
/// - `cmd_iterator` is an iterator over the command registers.
fn setup_read<'a, I>(
&self,
@ -2308,12 +2304,11 @@ impl Driver<'_> {
/// Executes an I2C read operation.
/// - `addr` is the address of the slave device.
/// - `buffer` is the buffer to store the read data.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `stop` indicates whether the operation should end with a STOP
/// condition.
/// - `will_continue` indicates whether there is another read operation
/// following this one and we should not nack the last byte.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `stop` indicates whether the operation should end with a STOP condition.
/// - `will_continue` indicates whether there is another read operation following this one and
/// we should not nack the last byte.
/// - `cmd_iterator` is an iterator over the command registers.
fn start_read_operation(
&self,
@ -2347,10 +2342,9 @@ impl Driver<'_> {
/// Executes an I2C write operation.
/// - `addr` is the address of the slave device.
/// - `bytes` is the data two be sent.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `stop` indicates whether the operation should end with a STOP
/// condition.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `stop` indicates whether the operation should end with a STOP condition.
/// - `cmd_iterator` is an iterator over the command registers.
fn write_operation_blocking(
&self,
@ -2378,12 +2372,11 @@ impl Driver<'_> {
/// Executes an I2C read operation.
/// - `addr` is the address of the slave device.
/// - `buffer` is the buffer to store the read data.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `stop` indicates whether the operation should end with a STOP
/// condition.
/// - `will_continue` indicates whether there is another read operation
/// following this one and we should not nack the last byte.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `stop` indicates whether the operation should end with a STOP condition.
/// - `will_continue` indicates whether there is another read operation following this one and
/// we should not nack the last byte.
/// - `cmd_iterator` is an iterator over the command registers.
fn read_operation_blocking(
&self,
@ -2414,10 +2407,9 @@ impl Driver<'_> {
/// Executes an async I2C write operation.
/// - `addr` is the address of the slave device.
/// - `bytes` is the data two be sent.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `stop` indicates whether the operation should end with a STOP
/// condition.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `stop` indicates whether the operation should end with a STOP condition.
/// - `cmd_iterator` is an iterator over the command registers.
async fn write_operation(
&self,
@ -2445,12 +2437,11 @@ impl Driver<'_> {
/// Executes an async I2C read operation.
/// - `addr` is the address of the slave device.
/// - `buffer` is the buffer to store the read data.
/// - `start` indicates whether the operation should start by a START
/// condition and sending the address.
/// - `stop` indicates whether the operation should end with a STOP
/// condition.
/// - `will_continue` indicates whether there is another read operation
/// following this one and we should not nack the last byte.
/// - `start` indicates whether the operation should start by a START condition and sending the
/// address.
/// - `stop` indicates whether the operation should end with a STOP condition.
/// - `will_continue` indicates whether there is another read operation following this one and
/// we should not nack the last byte.
/// - `cmd_iterator` is an iterator over the command registers.
async fn read_operation(
&self,
@ -2893,8 +2884,8 @@ mod bus_clear {
// Starting from (9, false), becase:
// - we start with SCL low
// - a complete SCL cycle consists of a high period and a low period
// - we decrement the remaining counter at the beginning of a cycle, which gives
// us 9 complete SCL cycles.
// - we decrement the remaining counter at the beginning of a cycle, which gives us 9
// complete SCL cycles.
let state = State::SendClock(Self::BUS_CLEAR_BITS, false);
Self {

View File

@ -10,10 +10,8 @@
//! ## Notes
//!
//! Data output is interleaved:
//! - 8bit: [A, B, C, D] is output as [C, D, A, B] (i.e., swapped as 16bit
//! words)
//! - 16bit: [A, B, C, D] is output as [B, A, D, C] (i.e., 16bit words are
//! swapped)
//! - 8bit: [A, B, C, D] is output as [C, D, A, B] (i.e., swapped as 16bit words)
//! - 16bit: [A, B, C, D] is output as [B, A, D, C] (i.e., 16bit words are swapped)
#![cfg_attr(esp32, doc = "")]
#![cfg_attr(
esp32,

View File

@ -501,8 +501,8 @@ where
/// Sending out the [DmaTxBuffer] to the RGB/DPI interface.
///
/// - `next_frame_en`: Automatically send the next frame data when the
/// current frame is sent out.
/// - `next_frame_en`: Automatically send the next frame data when the current frame is sent
/// out.
pub fn send<TX: DmaTxBuffer>(
mut self,
next_frame_en: bool,
@ -716,8 +716,7 @@ pub struct Format {
/// Configures the byte order for data transmission.
///
/// - In 8-bit mode, [ByteOrder::Inverted] means every two bytes are
/// swapped.
/// - In 8-bit mode, [ByteOrder::Inverted] means every two bytes are swapped.
/// - In 16-bit mode, this controls the byte order (endianness).
pub byte_order: ByteOrder,

View File

@ -530,9 +530,8 @@ pub use private::Internal;
/// # Safety
///
/// - The type must be inhabited
/// - The type must be valid for any bit pattern of its backing memory in case a
/// reset occurs during a write or a reset interrupts the zero initialization
/// on first boot.
/// - The type must be valid for any bit pattern of its backing memory in case a reset occurs during
/// a write or a reset interrupts the zero initialization on first boot.
/// - Structs must contain only `Persistable` fields and padding
#[instability::unstable]
pub unsafe trait Persistable: Sized {}

View File

@ -60,12 +60,10 @@ macro_rules! trm_markdown_link {
/// This macro generates the following:
///
/// - An `AnyPeripheral` struct, name provided by the macro call.
/// - An `any::Degrade` trait which is supposed to be used as a supertrait of a
/// relevant Instance.
/// - An `any::Degrade` trait which is supposed to be used as a supertrait of a relevant Instance.
/// - An `any::Inner` enum, with the same variants as the original peripheral.
/// - A `From` implementation for each peripheral variant.
/// - A `degrade` method for each peripheral variant using the `any::Degrade`
/// trait.
/// - A `degrade` method for each peripheral variant using the `any::Degrade` trait.
#[macro_export]
macro_rules! any_peripheral {
($(#[$meta:meta])* $vis:vis peripheral $name:ident<'d> {

View File

@ -9,30 +9,28 @@
//! - Digital motor control, e.g., brushed/brushless DC motor, RC servo motor
//! - Switch mode-based digital power conversion
//! - Power DAC, where the duty cycle is equivalent to a DAC analog value
//! - Calculate external pulse width, and convert it into other analog values
//! like speed, distance
//! - Calculate external pulse width, and convert it into other analog values like speed, distance
//! - Generate Space Vector PWM (SVPWM) signals for Field Oriented Control (FOC)
//!
//! ## Configuration
//!
//! * PWM Timers 0, 1 and 2
//! * Every PWM timer has a dedicated 8-bit clock prescaler.
//! * The 16-bit counter in the PWM timer can work in count-up mode,
//! count-down mode or count-up-down mode.
//! * A hardware sync or software sync can trigger a reload on the PWM timer
//! with a phase register (Not yet implemented)
//! * The 16-bit counter in the PWM timer can work in count-up mode, count-down mode or
//! count-up-down mode.
//! * A hardware sync or software sync can trigger a reload on the PWM timer with a phase
//! register (Not yet implemented)
//! * PWM Operators 0, 1 and 2
//! * Every PWM operator has two PWM outputs: PWMxA and PWMxB. They can work
//! independently, in symmetric and asymmetric configuration.
//! * Every PWM operator has two PWM outputs: PWMxA and PWMxB. They can work independently, in
//! symmetric and asymmetric configuration.
//! * Software, asynchronously override control of PWM signals.
//! * Configurable dead-time on rising and falling edges; each set up
//! independently. (Not yet implemented)
//! * All events can trigger CPU interrupts. (Not yet implemented)
//! * Modulating of PWM output by high-frequency carrier signals, useful
//! when gate drivers are insulated with a transformer. (Not yet
//! * Configurable dead-time on rising and falling edges; each set up independently. (Not yet
//! implemented)
//! * Period, time stamps and important control registers have shadow
//! registers with flexible updating methods.
//! * All events can trigger CPU interrupts. (Not yet implemented)
//! * Modulating of PWM output by high-frequency carrier signals, useful when gate drivers are
//! insulated with a transformer. (Not yet implemented)
//! * Period, time stamps and important control registers have shadow registers with flexible
//! updating methods.
//! * Fault Detection Module (Not yet implemented)
//! * Capture Module (Not yet implemented)
#![doc = ""]

View File

@ -161,12 +161,11 @@ impl DeadTimeCfg {
/// A MCPWM operator
///
/// The PWM Operator submodule has the following functions:
/// * Generates a PWM signal pair, based on timing references obtained from the
/// corresponding PWM timer.
/// * Each signal out of the PWM signal pair includes a specific pattern of dead
/// time. (Not yet implemented)
/// * Superimposes a carrier on the PWM signal, if configured to do so. (Not yet
/// * Generates a PWM signal pair, based on timing references obtained from the corresponding PWM
/// timer.
/// * Each signal out of the PWM signal pair includes a specific pattern of dead time. (Not yet
/// implemented)
/// * Superimposes a carrier on the PWM signal, if configured to do so. (Not yet implemented)
/// * Handles response under fault conditions. (Not yet implemented)
pub struct Operator<'d, const OP: u8, PWM> {
phantom: PhantomData<&'d PWM>,

View File

@ -168,8 +168,7 @@ pub mod asynch {
///
/// # Arguments
///
/// * `ep_out_buffer` - An internal buffer used to temporarily store
/// received packets.
/// * `ep_out_buffer` - An internal buffer used to temporarily store received packets.
///
/// Must be large enough to fit all OUT endpoint max packet sizes.
/// Endpoint allocation will fail if it is too small.

View File

@ -56,10 +56,8 @@ impl<const UNIT: usize, const NUM: usize> Channel<'_, UNIT, NUM> {
/// Configures how the channel affects the counter based on the transition
/// made by the input signal.
///
/// * `neg_edge` - The effect on the counter when the input signal goes 1 ->
/// 0.
/// * `pos_edge` - The effect on the counter when the input signal goes 0 ->
/// 1.
/// * `neg_edge` - The effect on the counter when the input signal goes 1 -> 0.
/// * `pos_edge` - The effect on the counter when the input signal goes 0 -> 1.
pub fn set_input_mode(&self, neg_edge: EdgeMode, pos_edge: EdgeMode) {
let pcnt = PCNT::regs();
let conf0 = pcnt.unit(UNIT).conf0();

View File

@ -4,12 +4,10 @@
///
/// The macro has a few fields doing different things, in the form of
/// `second <= third (fourth)`.
/// - The second field is the name of the peripheral, as it appears in the
/// `Peripherals` struct.
/// - The third field is the name of the peripheral as it appears in the PAC.
/// This may be `virtual` if the peripheral is not present in the PAC.
/// - The fourth field is an optional list of interrupts that can be bound to
/// the peripheral.
/// - The second field is the name of the peripheral, as it appears in the `Peripherals` struct.
/// - The third field is the name of the peripheral as it appears in the PAC. This may be `virtual`
/// if the peripheral is not present in the PAC.
/// - The fourth field is an optional list of interrupts that can be bound to the peripheral.
#[doc(hidden)]
#[macro_export]
macro_rules! peripherals {

View File

@ -12,10 +12,8 @@
//! Typically, the RMT peripheral can be used in the following scenarios:
//! - Transmit or receive infrared signals, with any IR protocols, e.g., NEC
//! - General-purpose sequence generator
//! - Transmit signals in a hardware-controlled loop, with a finite or infinite
//! number of times
//! - Modulate the carrier to the output signal or demodulate the carrier from
//! the input signal
//! - Transmit signals in a hardware-controlled loop, with a finite or infinite number of times
//! - Modulate the carrier to the output signal or demodulate the carrier from the input signal
//!
//! ### Channels
//!

View File

@ -11,12 +11,10 @@
//! under any of the following conditions:
//!
//! - RF subsystem is enabled (i.e. Wi-Fi or Bluetooth are enabled).
//! - An internal entropy source has been enabled by calling
//! `bootloader_random_enable()` and not yet disabled by calling
//! `bootloader_random_disable()`.
//! - While the ESP-IDF Second stage bootloader is running. This is because the
//! default ESP-IDF bootloader implementation calls
//! `bootloader_random_enable()` when the bootloader starts, and
//! - An internal entropy source has been enabled by calling `bootloader_random_enable()` and not
//! yet disabled by calling `bootloader_random_disable()`.
//! - While the ESP-IDF Second stage bootloader is running. This is because the default ESP-IDF
//! bootloader implementation calls `bootloader_random_enable()` when the bootloader starts, and
//! `bootloader_random_disable()` before executing the app.
//!
//! When any of these conditions are true, samples of physical noise are

View File

@ -296,8 +296,7 @@ where
/// Creates an instance of `RsaModularMultiplication`.
///
/// - `r` can be calculated using `2 ^ ( bitlength * 2 ) mod modulus`.
/// - `m_prime` can be calculated using `-(modular multiplicative inverse of
/// modulus) mod 2^32`.
/// - `m_prime` can be calculated using `-(modular multiplicative inverse of modulus) mod 2^32`.
///
/// For more information refer to 20.3.1 of <https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf>.
pub fn new(

View File

@ -365,8 +365,7 @@ impl<'d> Rtc<'d> {
// In terms of peripherals:
// - LPWR is used on the following chips: esp32, esp32p4, esp32c2, esp32c3,
// esp32s2, esp32s3
// - LPWR is used on the following chips: esp32, esp32p4, esp32c2, esp32c3, esp32s2, esp32s3
// - LP_AON is used on the following chips: esp32c5, esp32c6, esp32c61, esp32h2

View File

@ -117,16 +117,12 @@ impl crate::interrupt::InterruptConfigurable for Sha<'_> {
}
// A few notes on this implementation with regards to 'memcpy',
// - The registers are *not* cleared after processing, so padding needs to be
// written out
// - This component uses core::intrinsics::volatile_* which is unstable, but is
// the only way to
// - The registers are *not* cleared after processing, so padding needs to be written out
// - This component uses core::intrinsics::volatile_* which is unstable, but is the only way to
// efficiently copy memory with volatile
// - For this particular registers (and probably others), a full u32 needs to be
// written partial
// - For this particular registers (and probably others), a full u32 needs to be written partial
// register writes (i.e. in u8 mode) does not work
// - This means that we need to buffer bytes coming in up to 4 u8's in order
// to create a full u32
// - This means that we need to buffer bytes coming in up to 4 u8's in order to create a full u32
/// An active digest
///

View File

@ -9,22 +9,20 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `errata36(pin_num: u8, pull_up: bool, pull_down: bool)`:
//! * Handles the configuration of pull-up and pull-down resistors for
//! specific GPIO pins
//! * Handles the configuration of pull-up and pull-down resistors for specific GPIO pins
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -9,19 +9,18 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -9,19 +9,18 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -9,19 +9,18 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -9,19 +9,18 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -9,29 +9,27 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `impl_get_rtc_pad`:
//! * This macro_rule generates a function to get a specific RTC pad. It
//! takes a single argument `$pad_name`, which is an identifier
//! representing the name of the pad. Returns a reference to the
//! corresponding RTC pad.
//! * This macro_rule generates a function to get a specific RTC pad. It takes a single
//! argument `$pad_name`, which is an identifier representing the name of the pad. Returns a
//! reference to the corresponding RTC pad.
//! - `impl_get_rtc_pad_indexed`:
//! * This macro_rule generates a function similar to the previous one but
//! for indexed RTC pads. It takes two arguments: `$pad_name`, which
//! represents the name of the pad, and `$idx`, which is the index of
//! the specific pad. Returns a reference to the indexed RTC pad.
//! * This macro_rule generates a function similar to the previous one but for indexed RTC
//! pads. It takes two arguments: `$pad_name`, which represents the name of the pad, and
//! `$idx`, which is the index of the specific pad. Returns a reference to the indexed RTC
//! pad.
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -515,14 +515,13 @@ pub(crate) mod utils {
///
/// [`wp_gpio_num`]: u8 Number of the WP pin to reconfigure for quad I/O
/// [`spiconfig`]: u32 Pin configuration, as returned from ets_efuse_get_spiconfig().
/// - If this parameter is 0, default SPI pins are used and
/// wp_gpio_num parameter is ignored.
/// - If this parameter is 1, default HSPI pins are used and
/// wp_gpio_num parameter is ignored.
/// - For other values, this parameter encodes the HD pin number and
/// also the CLK pin number. CLK pin selection is used to
/// determine if HSPI or SPI peripheral will be used (use HSPI if
/// CLK pin is the HSPI clock pin, otherwise use SPI).
/// - If this parameter is 0, default SPI pins are used and wp_gpio_num parameter is
/// ignored.
/// - If this parameter is 1, default HSPI pins are used and wp_gpio_num parameter is
/// ignored.
/// - For other values, this parameter encodes the HD pin number and also the CLK pin
/// number. CLK pin selection is used to determine if HSPI or SPI peripheral will be
/// used (use HSPI if CLK pin is the HSPI clock pin, otherwise use SPI).
// Both HD & WP pins are configured via GPIO matrix to map to the selected peripheral.
fn esp_rom_spiflash_select_qio_pins(wp_gpio_num: u8, spiconfig: u32);
}

View File

@ -9,19 +9,18 @@
//! Let's get through the functionality and configurations provided by this GPIO
//! module:
//! - `gpio` block:
//! * Defines the pin configurations for various GPIO pins. Each line
//! represents a pin and its associated options such as input/output
//! mode, analog capability, and corresponding functions.
//! * Defines the pin configurations for various GPIO pins. Each line represents a pin and its
//! associated options such as input/output mode, analog capability, and corresponding
//! functions.
//! - `analog` block:
//! * Block defines the analog capabilities of various GPIO pins. Each
//! line represents a pin and its associated options such as mux
//! selection, function selection, and input enable.
//! * Block defines the analog capabilities of various GPIO pins. Each line represents a pin
//! and its associated options such as mux selection, function selection, and input enable.
//! - `enum InputSignal`:
//! * This enumeration defines input signals for the GPIO mux. Each input
//! signal is assigned a specific value.
//! * This enumeration defines input signals for the GPIO mux. Each input signal is assigned a
//! specific value.
//! - `enum OutputSignal`:
//! * This enumeration defines output signals for the GPIO mux. Each
//! output signal is assigned a specific value.
//! * This enumeration defines output signals for the GPIO mux. Each output signal is assigned
//! a specific value.
//!
//! This trait provides functions to read the interrupt status and NMI status
//! registers for both the `PRO CPU` and `APP CPU`. The implementation uses the

View File

@ -355,14 +355,13 @@ pub(crate) mod utils {
///
/// [`wp_gpio_num`]: u8 Number of the WP pin to reconfigure for quad I/O
/// [`spiconfig`]: u32 Pin configuration, as returned from ets_efuse_get_spiconfig().
/// - If this parameter is 0, default SPI pins are used and wp_gpio_num
/// parameter is ignored.
/// - If this parameter is 1, default HSPI pins are used and wp_gpio_num
/// parameter is ignored.
/// - For other values, this parameter encodes the HD pin number and
/// also the CLK pin number. CLK pin selection is used to determine if
/// HSPI or SPI peripheral will be used (use HSPI if CLK pin is the
/// HSPI clock pin, otherwise use SPI).
/// - If this parameter is 0, default SPI pins are used and wp_gpio_num parameter is
/// ignored.
/// - If this parameter is 1, default HSPI pins are used and wp_gpio_num parameter is
/// ignored.
/// - For other values, this parameter encodes the HD pin number and also the CLK pin
/// number. CLK pin selection is used to determine if HSPI or SPI peripheral will be used
/// (use HSPI if CLK pin is the HSPI clock pin, otherwise use SPI).
// Both HD & WP pins are configured via GPIO matrix to map to the selected peripheral.
fn esp_rom_spiflash_select_qio_pins(wp_gpio_num: u8, spiconfig: u32);
}

View File

@ -14,10 +14,10 @@
//! If all you want to do is to communicate to a single device, and you initiate
//! transactions yourself, there are a number of ways to achieve this:
//!
//! - Use the [`SpiBus`](embedded_hal::spi::SpiBus) trait and its associated
//! functions to initiate transactions with simultaneous reads and writes, or
//! - Use the `ExclusiveDevice` struct from [`embedded-hal-bus`] or `SpiDevice`
//! from [`embassy-embedded-hal`].
//! - Use the [`SpiBus`](embedded_hal::spi::SpiBus) trait and its associated functions to initiate
//! transactions with simultaneous reads and writes, or
//! - Use the `ExclusiveDevice` struct from [`embedded-hal-bus`] or `SpiDevice` from
//! [`embassy-embedded-hal`].
//!
//! ### Shared SPI access
//!

View File

@ -251,8 +251,7 @@ impl<L: single_core::RawLock> GenericRawMutex<L> {
///
/// - Each release call must be paired with an acquire call.
/// - The returned token must be passed to the corresponding `release` call.
/// - The caller must ensure to release the locks in the reverse order they
/// were acquired.
/// - The caller must ensure to release the locks in the reverse order they were acquired.
unsafe fn acquire(&self) -> RestoreState {
cfg_if::cfg_if! {
if #[cfg(single_core)] {
@ -301,10 +300,8 @@ impl<L: single_core::RawLock> GenericRawMutex<L> {
///
/// # Safety
///
/// - This function must only be called if the lock was acquired by the
/// current thread.
/// - The caller must ensure to release the locks in the reverse order they
/// were acquired.
/// - This function must only be called if the lock was acquired by the current thread.
/// - The caller must ensure to release the locks in the reverse order they were acquired.
/// - Each release call must be paired with an acquire call.
unsafe fn release(&self, token: RestoreState) {
unsafe {
@ -362,8 +359,7 @@ impl RawMutex {
///
/// - Each release call must be paired with an acquire call.
/// - The returned token must be passed to the corresponding `release` call.
/// - The caller must ensure to release the locks in the reverse order they
/// were acquired.
/// - The caller must ensure to release the locks in the reverse order they were acquired.
pub unsafe fn acquire(&self) -> RestoreState {
unsafe { self.inner.acquire() }
}
@ -372,10 +368,8 @@ impl RawMutex {
///
/// # Safety
///
/// - This function must only be called if the lock was acquired by the
/// current thread.
/// - The caller must ensure to release the locks in the reverse order they
/// were acquired.
/// - This function must only be called if the lock was acquired by the current thread.
/// - The caller must ensure to release the locks in the reverse order they were acquired.
/// - Each release call must be paired with an acquire call.
pub unsafe fn release(&self, token: RestoreState) {
unsafe {

View File

@ -125,8 +125,7 @@ impl<'d> SystemTimer<'d> {
///
/// # Safety
///
/// - Disabling a `Unit` whilst [`Alarm`]s are using it will affect the
/// [`Alarm`]s operation.
/// - Disabling a `Unit` whilst [`Alarm`]s are using it will affect the [`Alarm`]s operation.
/// - Disabling Unit0 will affect [`Instant::now`].
pub unsafe fn configure_unit(unit: Unit, config: UnitConfig) {
unit.configure(config)
@ -140,8 +139,7 @@ impl<'d> SystemTimer<'d> {
///
/// # Safety
///
/// - Modifying a unit's count whilst [`Alarm`]s are using it may cause
/// unexpected behaviour
/// - Modifying a unit's count whilst [`Alarm`]s are using it may cause unexpected behaviour
/// - Any modification of the unit0 count will affect [`Instant::now`]
pub unsafe fn set_unit_value(unit: Unit, value: u64) {
unit.set_count(value)
@ -672,8 +670,7 @@ pub mod etm {
//! tasks.
//!
//! The system timer can generate the following ETM events:
//! - SYSTIMER_EVT_CNT_CMPx: Indicates the alarm pulses generated by
//! COMPx
//! - SYSTIMER_EVT_CNT_CMPx: Indicates the alarm pulses generated by COMPx
//! ## Example
//! ```rust, no_run
#![doc = crate::before_snippet!()]

View File

@ -276,8 +276,7 @@ impl<'d> Touch<'d, Continuous, Async> {
///
/// ## Parameters:
///
/// - `rtc`: The RTC peripheral is needed to configure the required
/// interrupts.
/// - `rtc`: The RTC peripheral is needed to configure the required interrupts.
/// - `config`: Optional configuration options.
///
/// ## Example
@ -414,9 +413,8 @@ impl<P: TouchPin, Tm: TouchMode> TouchPad<P, Tm, Blocking> {
/// [1]: ../rtc_cntl/struct.Rtc.html#method.set_interrupt_handler
///
/// ## Parameters:
/// - `threshold`: The threshold above/below which the pin is considered
/// touched. Above/below depends on the configuration of `touch` in
/// [`new`](Self::new) (defaults to below).
/// - `threshold`: The threshold above/below which the pin is considered touched. Above/below
/// depends on the configuration of `touch` in [`new`](Self::new) (defaults to below).
///
/// ## Example
pub fn enable_interrupt(&mut self, threshold: u16) {

View File

@ -525,9 +525,8 @@ pub enum ConfigError {
///
/// This error is returned if:
/// * the baud rate exceeds 5MBaud or is equal to zero.
/// * the user has specified an exact baud rate or with some percentage of
/// deviation to the desired value, and the driver cannot reach this
/// speed.
/// * the user has specified an exact baud rate or with some percentage of deviation to the
/// desired value, and the driver cannot reach this speed.
UnsupportedBaudrate,
/// The requested timeout exceeds the maximum value (
@ -2900,8 +2899,8 @@ impl Info {
/// [ConfigError::UnsupportedTimeout] if the provided value exceeds
/// the maximum value for SOC:
/// - `esp32`: Symbol size is fixed to 8, do not pass a value > **0x7F**.
/// - `esp32c2`, `esp32c3`, `esp32c6`, `esp32h2`, esp32s2`, esp32s3`: The
/// value you pass times the symbol size must be <= **0x3FF**
/// - `esp32c2`, `esp32c3`, `esp32c6`, `esp32h2`, esp32s2`, esp32s3`: The value you pass times
/// the symbol size must be <= **0x3FF**
fn set_rx_timeout(&self, timeout: Option<u8>, _symbol_len: u8) -> Result<(), ConfigError> {
cfg_if::cfg_if! {
if #[cfg(esp32)] {

View File

@ -15,17 +15,16 @@
//!
//! The USB Serial/JTAG controller boasts the following features:
//!
//! - Hardwired for CDC-ACM (Communication Device Class - Abstract Control
//! Model) and JTAG adapter functionality
//! - Integrates CDC-ACM adherent serial port emulation (plug-and-play on most
//! modern OSes); supports host controllable chip reset and entry into
//! download mode
//! - Allows fast communication with CPU debugging core using a compact
//! representation of JTAG instructions
//! - Two OUT Endpoints and three IN Endpoints in addition to Control Endpoint
//! 0; Up to 64-byte data payload size
//! - Internal PHY means that very few or no external components needed to
//! connect to a host computer
//! - Hardwired for CDC-ACM (Communication Device Class - Abstract Control Model) and JTAG adapter
//! functionality
//! - Integrates CDC-ACM adherent serial port emulation (plug-and-play on most modern OSes);
//! supports host controllable chip reset and entry into download mode
//! - Allows fast communication with CPU debugging core using a compact representation of JTAG
//! instructions
//! - Two OUT Endpoints and three IN Endpoints in addition to Control Endpoint 0; Up to 64-byte data
//! payload size
//! - Internal PHY means that very few or no external components needed to connect to a host
//! computer
//!
//! ## Usage
//!

View File

@ -4,8 +4,7 @@
//!
//! This crate provides:
//!
//! - Before main initialization of the `.bss` and `.data` sections controlled
//! by features
//! - Before main initialization of the `.bss` and `.data` sections controlled by features
//! - `#[entry]` to declare the entry point of the program
//!
//! ## Feature Flags

View File

@ -1528,8 +1528,8 @@ pub enum ScanTypeConfig {
///
/// # Procedure
/// 1. Send probe request on each channel.
/// 2. Wait for probe response. Wait at least `min` time, but if no response
/// is received, wait up to `max` time.
/// 2. Wait for probe response. Wait at least `min` time, but if no response is received, wait
/// up to `max` time.
/// 3. Switch channel.
/// 4. Repeat from 1.
Active {
@ -2799,10 +2799,9 @@ impl WifiController<'_> {
/// Connect WiFi station to the AP.
///
/// - If station is connected , call [Self::disconnect] to disconnect.
/// - Scanning will not be effective until connection between device and the
/// AP is established.
/// - If device is scanning and connecting at the same time, it will abort
/// scanning and return a warning message and error
/// - Scanning will not be effective until connection between device and the AP is established.
/// - If device is scanning and connecting at the same time, it will abort scanning and return a
/// warning message and error
pub fn connect(&mut self) -> Result<(), WifiError> {
self.connect_impl()
}

View File

@ -1,6 +1,7 @@
//! Uses DMA to copy psram to internal memory.
//!
//! If your module is octal PSRAM then you need to set `ESP_HAL_CONFIG_PSRAM_MODE` to `octal`.
//! If your module is octal PSRAM then you need to set
//! `ESP_HAL_CONFIG_PSRAM_MODE` to `octal`.
//% FEATURES: esp-hal/psram aligned esp-hal/unstable
//% CHIPS: esp32s3

View File

@ -2,17 +2,16 @@
//! tasks over others.
//!
//! The example creates three tasks:
//! - A low priority task that is not actually async, but simulates some
//! blocking work. This task will run for 5 seconds, then sleep for 5
//! seconds.
//! - A low priority task that is actually async, but will not be able to run
//! while the blocking task is running.
//! - A high priority task that prints something every second. The example
//! demonstrates that this task will continue to run even while the low
//! priority blocking task is running.
//! - A low priority task that is not actually async, but simulates some blocking work. This task
//! will run for 5 seconds, then sleep for 5 seconds.
//! - A low priority task that is actually async, but will not be able to run while the blocking
//! task is running.
//! - A high priority task that prints something every second. The example demonstrates that this
//! task will continue to run even while the low priority blocking task is running.
// The thread-executor is created by the `#[esp_hal_embassy::main]` macro and is used to spawn `low_prio_async` and `low_prio_blocking`.
// The interrupt-executor is created in `main` and is used to spawn `high_prio`.
// The thread-executor is created by the `#[esp_hal_embassy::main]` macro and is used to spawn
// `low_prio_async` and `low_prio_blocking`. The interrupt-executor is created in `main` and is used
// to spawn `high_prio`.
//% CHIPS: esp32 esp32c2 esp32c3 esp32c6 esp32h2 esp32s2 esp32s3
//% FEATURES: embassy esp-hal-embassy/log-04 esp-hal/unstable

View File

@ -96,7 +96,8 @@ async fn main(_spawner: Spawner) {
};
// Run everything concurrently.
// If we had made everything `'static` above instead, we could do this using separate tasks instead.
// If we had made everything `'static` above instead, we could do this using
// separate tasks instead.
join(usb_fut, echo_fut).await;
}

View File

@ -34,7 +34,8 @@ fn main() -> ! {
println!();
// The app descriptor (if present) is contained in the first 256 bytes
// of an app image, right after the image header (24 bytes) and the first section header (8 bytes)
// of an app image, right after the image header (24 bytes) and the first
// section header (8 bytes)
let mut app_desc = [0u8; 256];
pt.find_partition(partitions::PartitionType::App(
partitions::AppPartitionSubType::Factory,

View File

@ -7,8 +7,8 @@
//!
//! ## ⚠️ Before writing ⚠️
//! - From the factory, the eFuse keyblocks are programmed to be 32-byte 0x00.
//! - This example is programmed to use this value so you can skip this step if
//! you don't want to burn an eFuse key.
//! - This example is programmed to use this value so you can skip this step if you don't want to
//! burn an eFuse key.
//! - If you skip the skip burning a custom key, you still need to [burn the
//! purpose](#burn-key-purpose).
//! - [Read more about eFuses](https://docs.espressif.com/projects/esptool/en/latest/esp32c3/espefuse/index.html)
@ -36,8 +36,7 @@
//! ```
//!
//! You can then write your key using the following command
//! - `BLOCK_KEY0` The keyblock to program the key to. By default this example
//! uses key0.
//! - `BLOCK_KEY0` The keyblock to program the key to. By default this example uses key0.
//! - `HMAC_UP` The purpose for the key. Use HMAC_UP for upstream.
//! - `--no-read-protect` Allow to read the key from software, after writing it.
//! ```sh

View File

@ -1,6 +1,8 @@
//! While this can be used as an example it's meant to be used with `extras/ieee802154-sniffer`
//! While this can be used as an example it's meant to be used with
//! `extras/ieee802154-sniffer`
//!
//! Besides the runtime changeable channel and the output format it's almost identical to ieee802154_receive_all_frames
//! Besides the runtime changeable channel and the output format it's almost
//! identical to ieee802154_receive_all_frames
//% CHIPS: esp32c6 esp32h2
//% FEATURES: esp-ieee802154 esp-hal/unstable

View File

@ -1,25 +1,32 @@
//! OTA Update Example
//!
//! This shows the basics of dealing with partitions and changing the active partition.
//! For simplicity it will flash an application image embedded into the binary.
//! In a real world application you can get the image via HTTP(S), UART or from an sd-card etc.
//! This shows the basics of dealing with partitions and changing the active
//! partition. For simplicity it will flash an application image embedded into
//! the binary. In a real world application you can get the image via HTTP(S),
//! UART or from an sd-card etc.
//!
//! Adjust the target and the chip in the following commands according to the chip used!
//! Adjust the target and the chip in the following commands according to the
//! chip used!
//!
//! - `cargo xtask build examples examples esp32 --example=gpio_interrupt`
//! - `espflash save-image --chip=esp32 examples/target/xtensa-esp32-none-elf/release/gpio_interrupt examples/target/ota_image`
//! - `espflash save-image --chip=esp32 examples/target/xtensa-esp32-none-elf/release/gpio_interrupt
//! examples/target/ota_image`
//! - `cargo xtask build examples examples esp32 --example=ota_update`
//! - `espflash save-image --chip=esp32 examples/target/xtensa-esp32-none-elf/release/ota_update examples/target/ota_image`
//! - erase whole flash via `espflash erase-flash` (this is to make sure otadata is cleared and no code is flashed to any partition)
//! - `espflash save-image --chip=esp32 examples/target/xtensa-esp32-none-elf/release/ota_update
//! examples/target/ota_image`
//! - erase whole flash via `espflash erase-flash` (this is to make sure otadata is cleared and no
//! code is flashed to any partition)
//! - run via `cargo xtask run example examples esp32 --example=ota_update`
//!
//! On first boot notice the firmware partition gets booted ("Loaded app from partition at offset 0x10000").
//! Press the BOOT button, once finished press the RESET button.
//! On first boot notice the firmware partition gets booted ("Loaded app from
//! partition at offset 0x10000"). Press the BOOT button, once finished press
//! the RESET button.
//!
//! Notice OTA0 gets booted ("Loaded app from partition at offset 0x110000").
//!
//! Once again press BOOT, when finished press RESET.
//! You will see the `gpio_interrupt` example gets booted from OTA1 ("Loaded app from partition at offset 0x210000")
//! You will see the `gpio_interrupt` example gets booted from OTA1 ("Loaded app
//! from partition at offset 0x210000")
//!
//! See https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/ota.html
@ -78,8 +85,9 @@ fn main() -> ! {
);
println!("current {:?} - next {:?}", current, current.next());
// Mark the current slot as VALID - this is only needed if the bootloader was built with auto-rollback support.
// The default pre-compiled bootloader in espflash is NOT.
// Mark the current slot as VALID - this is only needed if the bootloader was
// built with auto-rollback support. The default pre-compiled bootloader in
// espflash is NOT.
if ota.current_slot().unwrap() != Slot::None
&& (ota.current_ota_state().unwrap() == esp_bootloader_esp_idf::ota::OtaImageState::New
|| ota.current_ota_state().unwrap()

View File

@ -13,7 +13,8 @@
//! Connect MISO and MOSI pins to see the outgoing data is read as incoming
//! data.
//!
//! If your module is octal PSRAM then you need to set `ESP_HAL_CONFIG_PSRAM_MODE` to `octal`.
//! If your module is octal PSRAM then you need to set
//! `ESP_HAL_CONFIG_PSRAM_MODE` to `octal`.
//% FEATURES: esp-hal/psram esp-hal/unstable
//% CHIPS: esp32s3

View File

@ -42,7 +42,8 @@ fn interrupt_handler() {
if touch1.is_interrupt_set() {
println!("touch 1 pin interrupt");
touch1.clear_interrupt();
// We disable the interrupt until the next loop iteration to avoid massive retriggering.
// We disable the interrupt until the next loop iteration to avoid massive
// retriggering.
touch1.disable_interrupt();
}
});

View File

@ -2,8 +2,9 @@
//!
//! `IS_FIRST_SENDER` below must be set to false on one of the ESP's
//!
//! In case you want to use `self-testing`, get rid of everything related to the aforementioned `IS_FIRST_SENDER`
//! and follow the advice in the comments related to this mode.
//! In case you want to use `self-testing`, get rid of everything related to the
//! aforementioned `IS_FIRST_SENDER` and follow the advice in the comments
//! related to this mode.
//!
//! The following wiring is assumed:
//! - TX/RX => GPIO2, connected internally and with internal pull-up resistor.
@ -13,8 +14,9 @@
//!
//! Notes for external transceiver use:
//!
//! The default setup assumes that two microcontrollers are connected directly without an external
//! transceiver. If you want to use an external transceiver, you need to:
//! The default setup assumes that two microcontrollers are connected directly
//! without an external transceiver. If you want to use an external transceiver,
//! you need to:
//! * uncomment the `rx_pin` line
//! * use `new()` function to create the TWAI configuration.
//! * change the `tx_pin` and `rx_pin` to the appropriate pins for your boards.
@ -42,7 +44,8 @@ esp_bootloader_esp_idf::esp_app_desc!();
fn main() -> ! {
let peripherals = esp_hal::init(esp_hal::Config::default());
// Without an external transceiver, we only need a single line between the two MCUs.
// Without an external transceiver, we only need a single line between the two
// MCUs.
let (rx_pin, tx_pin) = unsafe { peripherals.GPIO2.split() };
// Use these if you want to use an external transceiver:
// let tx_pin = peripherals.GPIO2;
@ -51,8 +54,8 @@ fn main() -> ! {
// The speed of the bus.
const TWAI_BAUDRATE: twai::BaudRate = twai::BaudRate::B125K;
// !!! Use `new` when using a transceiver. `new_no_transceiver` sets TX to open-drain
// Self-testing also works using the regular `new` function.
// !!! Use `new` when using a transceiver. `new_no_transceiver` sets TX to
// open-drain Self-testing also works using the regular `new` function.
// Begin configuring the TWAI peripheral. The peripheral is in a reset like
// state that prevents transmission but allows configuration.

View File

@ -1,7 +1,6 @@
//! WiFi frame injection example
//!
//! Periodically transmits a beacon frame.
//!
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/sniffer esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -1,12 +1,14 @@
//! Access point
//!
//! Creates an open access-point with SSID `esp-wifi`.
//! You can connect to it using a static IP in range 192.168.2.2 .. 192.168.2.255, gateway 192.168.2.1
//! You can connect to it using a static IP in range 192.168.2.2 ..
//! 192.168.2.255, gateway 192.168.2.1
//!
//! Open http://192.168.2.1:8080/ in your browser
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the WiFi has no internet connection, Chrome might not want to load the URL - you can use a shell and try `curl` and `ping`
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the
//! WiFi has no internet connection, Chrome might not want to load the URL - you
//! can use a shell and try `curl` and `ping`
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -2,12 +2,13 @@
//!
//! Set SSID and PASSWORD env variable before running this example.
//!
//! Gets an ip address via DHCP, creates an open access-point with SSID `esp-wifi`
//! You can connect to it using a static IP in range 192.168.2.2 .. 192.168.2.255, gateway 192.168.2.1
//! Open http://192.168.2.1:8080/ in your browser - the example will perform an HTTP get request to some "random" server
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the WiFi has no internet connection, Chrome might not want to load the URL - you can use a shell and try `curl` and `ping`
//! Gets an ip address via DHCP, creates an open access-point with SSID
//! `esp-wifi` You can connect to it using a static IP in range 192.168.2.2 ..
//! 192.168.2.255, gateway 192.168.2.1 Open http://192.168.2.1:8080/ in your browser - the example will perform an HTTP get request to some "random" server
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the
//! WiFi has no internet connection, Chrome might not want to load the URL - you
//! can use a shell and try `curl` and `ping`
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -1,12 +1,14 @@
//! Run a test of download, upload and download+upload in a blocking fashion.
//!
//! A prerequisite to running the benchmark examples is to run the benchmark server on your local machine. Simply run the following commands to do so.
//! A prerequisite to running the benchmark examples is to run the benchmark
//! server on your local machine. Simply run the following commands to do so.
//! ```
//! cd extras/bench-server
//! cargo run --release
//! ```
//! Ensure you have set the IP of your local machine in the `HOST_IP` env variable. E.g `HOST_IP="192.168.0.24"` and also set SSID and PASSWORD env variable before running this example.
//!
//! Ensure you have set the IP of your local machine in the `HOST_IP` env
//! variable. E.g `HOST_IP="192.168.0.24"` and also set SSID and PASSWORD env
//! variable before running this example.
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -1,7 +1,8 @@
//! BLE Example
//!
//! - starts Bluetooth advertising
//! - offers one service with three characteristics (one is read/write, one is write only, one is read/write/notify)
//! - offers one service with three characteristics (one is read/write, one is write only, one is
//! read/write/notify)
//! - pressing the boot-button on a dev-board will send a notification if it is subscribed
//% FEATURES: esp-wifi esp-wifi/ble esp-hal/unstable

View File

@ -5,8 +5,8 @@
//! - performs an HTTP get request to some "random" server
//! - does BLE advertising (you cannot connect to it - it's just not implemented in the example)
//!
//! Note: On ESP32-C2 and ESP32-C3 you need a wifi-heap size of 70000, on ESP32-C6 you need 80000 and a tx_queue_size of 10
//!
//! Note: On ESP32-C2 and ESP32-C3 you need a wifi-heap size of 70000, on
//! ESP32-C6 you need 80000 and a tx_queue_size of 10
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-wifi/ble esp-wifi/coex esp-hal/unstable
//% CHIPS: esp32 esp32s3 esp32c2 esp32c3 esp32c6
@ -80,7 +80,8 @@ fn main() -> ! {
let now = || time::Instant::now().duration_since_epoch().as_millis();
// initializing Bluetooth first results in a more stable WiFi connection on ESP32
// initializing Bluetooth first results in a more stable WiFi connection on
// ESP32
let connector = BleConnector::new(&esp_wifi_ctrl, peripherals.BT);
let hci = HciConnector::new(connector, now);
let mut ble = Ble::new(&hci);

View File

@ -2,7 +2,6 @@
//!
//!
//! Set SSID and PASSWORD env variable before running this example.
//!
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-wifi/log-04 esp-wifi/csi esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -3,8 +3,8 @@
//!
//! Set SSID and PASSWORD env variable before running this example.
//!
//! This gets an ip address via DHCP then performs an HTTP get request to some "random" server
//!
//! This gets an ip address via DHCP then performs an HTTP get request to some
//! "random" server
//% FEATURES: esp-wifi esp-wifi/wifi esp-hal/unstable esp-wifi/smoltcp
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -1,10 +1,14 @@
//! Embassy access point
//!
//! - creates an open access-point with SSID `esp-wifi`
//! - you can connect to it using a static IP in range 192.168.2.2 .. 192.168.2.255, gateway 192.168.2.1
//! - open http://192.168.2.1:8080/ in your browser - the example will perform an HTTP get request to some "random" server
//! - you can connect to it using a static IP in range 192.168.2.2 .. 192.168.2.255, gateway
//! 192.168.2.1
//! - open http://192.168.2.1:8080/ in your browser - the example will perform an HTTP get request
//! to some "random" server
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the WiFi has no internet connection, Chrome might not want to load the URL - you can use a shell and try `curl` and `ping`
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the
//! WiFi has no internet connection, Chrome might not want to load the URL - you
//! can use a shell and try `curl` and `ping`
//% FEATURES: embassy esp-wifi esp-wifi/wifi esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -8,11 +8,13 @@
//! - connect to it using a static IP in range 192.168.2.2 .. 192.168.2.255, gateway 192.168.2.1
//! - open http://192.168.2.1:8080/ in your browser
//! - or:
//! - connect to the network referenced by the SSID env variable and open the IP address printed by the example
//! - connect to the network referenced by the SSID env variable and open the IP address printed
//! by the example
//! - the example will perform an HTTP get request to some "random" server and return the response
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the WiFi has no internet connection, Chrome might not want to load the URL - you can use a shell and try `curl` and `ping`
//!
//! On Android you might need to choose _Keep Accesspoint_ when it tells you the
//! WiFi has no internet connection, Chrome might not want to load the URL - you
//! can use a shell and try `curl` and `ping`
//% FEATURES: embassy esp-wifi esp-wifi/wifi esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6
@ -185,9 +187,10 @@ async fn main(spawner: Spawner) -> ! {
loop {
println!("Wait for connection...");
// FIXME: If connections are attempted on both sockets at the same time, we might end up
// dropping one of them. Might be better to spawn both accept() calls, or use fused futures?
// Note that we only attempt to serve one connection at a time, so we don't run out of ram.
// FIXME: If connections are attempted on both sockets at the same time, we
// might end up dropping one of them. Might be better to spawn both
// accept() calls, or use fused futures? Note that we only attempt to
// serve one connection at a time, so we don't run out of ram.
let either_socket = embassy_futures::select::select(
ap_server_socket.accept(IpListenEndpoint {
addr: None,

View File

@ -1,14 +1,17 @@
//! Run a test of download, upload and download+upload in async fashion.
//!
//! A prerequisite to running the benchmark examples is to run the benchmark server on your local machine. Simply run the following commands to do so.
//! A prerequisite to running the benchmark examples is to run the benchmark
//! server on your local machine. Simply run the following commands to do so.
//! ```
//! cd extras/bench-server
//! cargo run --release
//! ```
//! Ensure you have set the IP of your local machine in the `HOST_IP` env variable. E.g `HOST_IP="192.168.0.24"` and also set SSID and PASSWORD env variable before running this example.
//!
//! Because of the huge task-arena size configured this won't work on ESP32-S2 and ESP32-C2
//! Ensure you have set the IP of your local machine in the `HOST_IP` env
//! variable. E.g `HOST_IP="192.168.0.24"` and also set SSID and PASSWORD env
//! variable before running this example.
//!
//! Because of the huge task-arena size configured this won't work on ESP32-S2
//! and ESP32-C2
//% FEATURES: embassy esp-wifi esp-wifi/wifi esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c3 esp32c6

View File

@ -1,7 +1,8 @@
//! Embassy BLE Example
//!
//! - starts Bluetooth advertising
//! - offers one service with three characteristics (one is read/write, one is write only, one is read/write/notify)
//! - offers one service with three characteristics (one is read/write, one is write only, one is
//! read/write/notify)
//! - pressing the boot-button on a dev-board will send a notification if it is subscribed
//% FEATURES: embassy esp-wifi esp-wifi/ble esp-hal/unstable

View File

@ -3,7 +3,8 @@
//!
//! Set SSID and PASSWORD env variable before running this example.
//!
//! This gets an ip address via DHCP then performs an HTTP get request to some "random" server
//! This gets an ip address via DHCP then performs an HTTP get request to some
//! "random" server
//!
//! Because of the huge task-arena size configured this won't work on ESP32-S2

View File

@ -1,6 +1,7 @@
//! Embassy ESP-NOW Example (Duplex)
//!
//! Asynchronously broadcasts, receives and sends messages via esp-now in multiple embassy tasks
//! Asynchronously broadcasts, receives and sends messages via esp-now in
//! multiple embassy tasks
//!
//! Because of the huge task-arena size configured this won't work on ESP32-S2

View File

@ -1,7 +1,6 @@
//! WiFi sniffer example
//!
//! Sniffs for beacon frames.
//!
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/sniffer esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -5,7 +5,6 @@
//! - might be necessary to configure your WiFi access point accordingly
//! - uses the given static IP
//! - responds with some HTML content when connecting to port 8080
//!
//% FEATURES: esp-wifi esp-wifi/wifi esp-wifi/smoltcp esp-hal/unstable
//% CHIPS: esp32 esp32s2 esp32s3 esp32c2 esp32c3 esp32c6

View File

@ -96,8 +96,8 @@ async fn edge_counter_task(
// This join will:
// - first set up the pin to listen
// - then poll the pin future once (which will return Pending)
// - then signal that the pin is listening, which enables the other core to
// toggle the matching OutputPin
// - then signal that the pin is listening, which enables the other core to toggle the
// matching OutputPin
// - then will wait for the pin future to resolve.
embassy_futures::join::join(in_pin.wait_for_any_edge(), async {
signal.signal(edge_count);

View File

@ -1,8 +1,14 @@
edition = "2024"
# Comments
format_code_in_doc_comments = true
normalize_comments = true
wrap_comments = true
# Code in comments
doc_comment_code_block_width = 100
comment_width = 100
# Enums
enum_discrim_align_threshold = 35

View File

@ -195,11 +195,14 @@ fn fmt_packages(workspace: &Path, args: FmtPackagesArgs) -> Result<()> {
.build();
if args.check {
cargo_args.push("--".into());
cargo_args.push("--check".into());
}
cargo_args.push("--".into());
cargo_args.push(format!(
"--config-path={}/rustfmt.toml",
workspace.display()
));
cargo_args.extend_from_slice(&source_files);
xtask::cargo::run(&cargo_args, &path)?;