mirror of
https://github.com/esp-rs/esp-hal.git
synced 2025-09-26 20:00:32 +00:00
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:
parent
9146407573
commit
517b5ccbe2
@ -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| {
|
||||
|
@ -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)
|
||||
|
@ -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)) -> ! {
|
||||
|
@ -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)]
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
//!
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
//!
|
||||
|
@ -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
|
||||
|
@ -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) {
|
||||
|
@ -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
|
||||
|
@ -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 {
|
||||
|
@ -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,
|
||||
|
@ -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,
|
||||
|
||||
|
@ -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 {}
|
||||
|
@ -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> {
|
||||
|
@ -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 = ""]
|
||||
|
@ -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>,
|
||||
|
@ -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.
|
||||
|
@ -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();
|
||||
|
@ -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 {
|
||||
|
@ -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
|
||||
//!
|
||||
|
@ -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
|
||||
|
@ -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(
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
///
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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);
|
||||
}
|
||||
|
@ -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
|
||||
|
@ -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);
|
||||
}
|
||||
|
@ -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
|
||||
//!
|
||||
|
@ -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 {
|
||||
|
@ -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!()]
|
||||
|
@ -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) {
|
||||
|
@ -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)] {
|
||||
|
@ -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
|
||||
//!
|
||||
|
@ -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
|
||||
|
@ -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()
|
||||
}
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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;
|
||||
}
|
||||
|
||||
|
@ -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,
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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()
|
||||
|
@ -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
|
||||
|
@ -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();
|
||||
}
|
||||
});
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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);
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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,
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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);
|
||||
|
@ -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
|
||||
|
||||
|
@ -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)?;
|
||||
|
Loading…
x
Reference in New Issue
Block a user