diff --git a/API-GUIDELINES.md b/API-GUIDELINES.md
index 82184cbc624..093ac5a2775 100644
--- a/API-GUIDELINES.md
+++ b/API-GUIDELINES.md
@@ -1,4 +1,4 @@
-# esp-rs API Guidelines
+# `esp-rs` API Guidelines
## About
@@ -7,7 +7,7 @@ This is a living document - make sure to check the latest version of this docume
> [!NOTE]
> Not all of the currently existing code follows this guideline, yet.
-In general, the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines) apply to all projects in the ESP-RS GitHub organization where possible. (`C-RW-VALUE` and `C-SERDE` do not apply)
+In general, the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines) apply to all projects in the ESP-RS GitHub organization where possible. (`C-RW-VALUE` and `C-SERDE` do not apply)
Especially for public API but if possible also for internal APIs.
@@ -42,13 +42,47 @@ The following paragraphs contain additional recommendations.
- Avoid type states and extraneous generics whenever possible
- These often lead to usability problems, and tend to just complicate things needlessly - sometimes it can be a good tradeoff to make a type not ZST
- Common cases of useless type info is storing pin information - this is usually not required after configuring the pins and will bloat the complexity of the type massively. When following the `PeripheralRef` pattern it's not needed in order to keep users from re-using the pin while in use
-- Avoiding `&mut self` when `&self` is safe to use. `&self` is generally easier to use as an API. Typical applications of this are where the methods just do writes to registers which don't have side effects.
+- Avoiding `&mut self` when `&self` is safe to use. `&self` is generally easier to use as an API. Typical applications of this are where the methods just do writes to registers which don't have side effects.
- For example starting a timer is fine for `&self`, worst case a timer will be started twice if two parts of the program call it. You can see a real example of this [here](https://github.com/esp-rs/esp-hal/pull/1500#pullrequestreview-2015911974)
## Maintainability
- Avoid excessive use of macros unless there is no other option; modification of the PAC crates should be considered before resorting to macros.
- Every line of code is a liability. Take some time to see if your implementation can be simplified before opening a PR.
-- If your are porting code from ESP-IDF (or anything else), please include a link WITH the commit hash in it, and please highlight the relevant line(s) of code
+- If you are porting code from ESP-IDF (or anything else), please include a link WITH the commit hash in it, and please highlight the relevant line(s) of code
- If necessary provide further context as comments (consider linking to code, PRs, TRM - make sure to use permanent links, e.g. include the hash when linking to a Git repository, include the revision, page number etc. when linking to TRMs)
-- Generally follow common "good practices" and idiomatic Rust style
+- Generally, follow common "good practices" and idiomatic Rust style
+
+## Modules Documentation
+
+Modules should have the following documentation format:
+```rust
+//! # Peripheral Name (Peripheral Acronym)
+//!
+//! ## Overview
+//! Small description of the peripheral, see ESP-IDF docs or TRM
+//!
+//! ## Configuration
+//! Explain how can the peripheral be configured, and which parameters can be configured
+//!
+//! ## Usage
+//! Explain if we implement any external traits
+//!
+//! ## Examples
+//!
+//! ### Name of the Example
+//! Small description of the example if needed
+//! ```rust, no_run
+//! ...
+//! ```
+//!
+//! ## Implementation State
+//! List unsuported features
+```
+- If any of the headers is empty, remove it
+- When possible, use ESP-IDF docs and TRM as references and include links if possible.
+ - In case of referencing an ESP-IDF link make it chip-specific, for example:
+ ```
+ #![doc = concat!("[ESP-IDF documentation](https://docs.espressif.com/projects/esp-idf/en/latest/", crate::soc::chip!(), "/api-reference/peripherals/etm.html)")]
+ ```
+- Documentation examples should be short and basic, for more complex scenarios, create an example.
diff --git a/esp-hal/src/assist_debug.rs b/esp-hal/src/assist_debug.rs
index 6ea71a3cab4..dafd353e517 100644
--- a/esp-hal/src/assist_debug.rs
+++ b/esp-hal/src/assist_debug.rs
@@ -1,22 +1,27 @@
-//! # Debug Assistant
+//! # Debug Assistant (ASSIST_DEBUG)
//!
//! ## Overview
-//! The Assist Debug driver provides functionality for debugging and monitoring
-//! features on ESP chips. It includes capabilities such as monitoring stack
-//! pointer (SP), monitoring memory regions, and handling interrupts related to
-//! debugging.
-//!
//! Debug Assistant is an auxiliary module that features a set of functions to
-//! help locate bugs and issues during software debugging.
+//! help locate bugs and issues during software debugging. It includes
+//! capabilities such as monitoring stack pointer (SP), monitoring memory
+//! regions, and handling interrupts related to debugging.
+//!
//!
+//! ## Configuration
//! While all the targets support program counter (PC) logging it's API is not
//! exposed here. Instead the ROM bootloader will always enable it and print the
//! last seen PC (e.g. _Saved PC:0x42002ff2_). Make sure the reset was triggered
//! by a TIMG watchdog. Not an RTC or SWD watchdog.
//!
-//! ⚠️ Bus write access logging is not available via this API. ⚠️
+//! ## Examples
+//! Visit the [Debug Assist] example for an example of using the Debug
+//! Assistant.
+//!
+//! [Debug Assist]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/debug_assist.rs
//!
-//! ⚠️ This driver has only blocking API. ⚠️
+//! ## Implmentation State
+//! - Bus write access logging is not available via this API
+//! - This driver has only blocking API
use crate::{
interrupt::InterruptHandler,
diff --git a/esp-hal/src/delay.rs b/esp-hal/src/delay.rs
index db121a67c1f..1b85154755d 100644
--- a/esp-hal/src/delay.rs
+++ b/esp-hal/src/delay.rs
@@ -1,16 +1,21 @@
-//! # Delay driver
+//! # Delay
//!
//! ## Overview
//! The Delay driver provides blocking delay functionalities using the
//! `SYSTIMER` peripheral for RISC-V devices and the built-in Xtensa timer for
-//! Xtensa devices. This module implements the blocking [DelayMs] and [DelayUs]
-//! traits from [embedded-hal].
+//! Xtensa devices.
//!
+//! ## Configuration
//! The delays are implemented in a "best-effort" way, meaning that the CPU will
//! block for at least the amount of time specified, but accuracy can be
//! affected by many factors, including interrupt usage.
//!
+//! ## Usage
+//! This module implements the blocking [DelayMs] and [DelayUs] traits from
+//! [embedded-hal], both 0.2.x and 1.x.x.
+//!
//! ## Examples
+//! ### Delay for 1 second
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::delay::Delay;
@@ -23,7 +28,7 @@
//!
//! [DelayMs]: embedded_hal_02::blocking::delay::DelayMs
//! [DelayUs]: embedded_hal_02::blocking::delay::DelayUs
-//! [embedded-hal]: https://docs.rs/embedded-hal/0.2.7/embedded_hal/index.html
+//! [embedded-hal]: https://docs.rs/embedded-hal/1.0.0/embedded_hal/delay/index.html
use fugit::HertzU64;
pub use fugit::MicrosDurationU64;
diff --git a/esp-hal/src/ecc.rs b/esp-hal/src/ecc.rs
index 69e01816c32..e2450aa87fc 100644
--- a/esp-hal/src/ecc.rs
+++ b/esp-hal/src/ecc.rs
@@ -1,6 +1,6 @@
-//! ECC Accelerator
+//! # Elliptic Curve Cryptography (ECC) Accelerator
//!
-//! # Overview
+//! ## Overview
//!
//! Elliptic Curve Cryptography (ECC) is an approach to public-key cryptography
//! based on the algebraic structure of elliptic curves. ECC allows smaller
@@ -10,22 +10,20 @@
//! elliptic curves, thus accelerating ECC algorithm and ECC-derived
//! algorithms (such as ECDSA).
//!
-//! # Main features
-//!
+//! ## Configuration
//! ECC Accelerator supports:
//! - Two different elliptic curves, namely P-192 and P-256 defined in FIPS
//! 186-3.
//! - Seven working modes.
//! - Interrupt upon completion of calculation.
//!
-//! # Availability on ESP32 family
-//!
-//! The accelerator is available on ESP32-C2 and ESP32-C6.
-//!
-//! # Data representation
-//!
//! Inputs of the ECC hardware accelerator must be provided in big-endian
//! representation. The driver handles the inner representation of the blocks.
+//!
+//! ## Examples
+//! Visit the [ECC] test for an example of using the ECC Accelerator.
+//!
+//! [ECC]: https://github.com/esp-rs/esp-hal/blob/main/hil-test/tests/ecc.rs
use core::marker::PhantomData;
@@ -84,7 +82,7 @@ pub enum WorkMode {
impl<'d> Ecc<'d, crate::Blocking> {
/// Create a new instance in [crate::Blocking] mode.
///
- /// Optionally an interrupt handler can be bound.
+ /// Optionally an interrupt handler can be bound.
pub fn new(ecc: impl Peripheral
+ 'd, interrupt: Option) -> Self {
crate::into_ref!(ecc);
diff --git a/esp-hal/src/etm.rs b/esp-hal/src/etm.rs
index 9388eb128f2..ea35a9cc70e 100644
--- a/esp-hal/src/etm.rs
+++ b/esp-hal/src/etm.rs
@@ -20,7 +20,7 @@
//!
//! For more information, please refer to the
#![doc = concat!("[ESP-IDF documentation](https://docs.espressif.com/projects/esp-idf/en/latest/", crate::soc::chip!(), "/api-reference/peripherals/etm.html)")]
-//! ## Example
+//! ## Examples
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::gpio::Io;
diff --git a/esp-hal/src/hmac.rs b/esp-hal/src/hmac.rs
index 209d970c83e..f2b37a83048 100644
--- a/esp-hal/src/hmac.rs
+++ b/esp-hal/src/hmac.rs
@@ -1,19 +1,12 @@
-//! HMAC Accelerator
+//! # Hash-based Message Authentication Code (HMAC) Accelerator
//!
-//! # Overview
+//! ## Overview
+//! HMAC is a secure authentication technique that verifies the authenticity and
+//! integrity of a message with a pre-shared key. This module provides hardware
+//! acceleration for SHA256-HMAC generation using a key burned into an eFuse
+//! block.
//!
-//! The Hash-based Message Authentication Code (HMAC) module computes Message
-//! Authentication Codes (MACs) using Hash algorithm and keys as described in
-//! RFC 2104. The hash algorithm is SHA-256, the 256-bit HMAC key is stored in
-//! an eFuse key block and can be set as read-protected, i. e., the key is not
-//! accessible from outside the HMAC accelerator itself.
-//!
-//! The HMAC module can be used in two modes - in ”upstream” mode the HMAC
-//! message is supplied by the user and the calculation result is read back by
-//! the user. In ”downstream” mode the HMAC module is used as a Key Derivation
-//! Function (KDF) for other internal hardwares.
-//!
-//! # Main features
+//! Main features:
//!
//! - Standard HMAC-SHA-256 algorithm.
//! - Hash result only accessible by configurable hardware peripheral (in
@@ -23,16 +16,23 @@
//! downstream mode).
//! - Re-enables soft-disabled JTAG (in downstream mode).
//!
-//! # Availability on ESP32 family
+//! ## Configuration
+//! The HMAC module can be used in two modes - in ”upstream” mode the HMAC
+//! message is supplied by the user and the calculation result is read back by
+//! the user. In ”downstream” mode the HMAC module is used as a Key Derivation
+//! Function (KDF) for other internal hardwares.
+//!
+//! ### HMAC padding
//!
-//! The accelerator is available on ESP32-S2, ESP32-S3, ESP32-C3 and ESP32-C6.
+//! The HMAC padding is handled by the driver. In downstream mode, users do not
+//! need to input any message or apply padding. The HMAC module uses a default
+//! 32-byte pattern of 0x00 for re-enabling JTAG and a 32-byte pattern of 0xff
+//! for deriving the AES key for the DS module.
//!
-//! # HMAC padding
+//! ## Examples
+//! Visit the [HMAC] example to learn how to use the HMAC accelerator
//!
-//! The HMAC padding is handled by the driver. In
-//! downstream mode, users do not need to input any message or apply padding.
-//! The HMAC module uses a default 32-byte pattern of 0x00 for re-enabling JTAG
-//! and a 32-byte pattern of 0xff for deriving the AES key for the DS module.
+//! [HMAC]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/hmac.rs
use core::convert::Infallible;
diff --git a/esp-hal/src/i2c.rs b/esp-hal/src/i2c.rs
index e6e3142075a..f39af673853 100644
--- a/esp-hal/src/i2c.rs
+++ b/esp-hal/src/i2c.rs
@@ -45,9 +45,8 @@
//! from the community. This includes the [embedded-hal] for both 0.2.x and
//! 1.x.x versions.
//!
-//! ### Examples
-//!
-//! #### Read Data from a BMP180 Sensor
+//! ## Examples
+//! ### Read Data from a BMP180 Sensor
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::i2c::I2C;
diff --git a/esp-hal/src/i2s.rs b/esp-hal/src/i2s.rs
index d60810860b0..6ecd98293be 100644
--- a/esp-hal/src/i2s.rs
+++ b/esp-hal/src/i2s.rs
@@ -1,15 +1,18 @@
-//! # I2S Master
+//! # Inter-IC Sound (I2S)
//!
//! ## Overview
+//! I2S (Inter-IC Sound) is a synchronous serial communication protocol usually
+//! used for transmitting audio data between two digital audio devices.
+//! Espressif devices may contain more than one I2S peripheral(s). These
+//! peripherals can be configured to input and output sample data via the I2S
+//! driver.
//!
-//! The I2S Master peripheral driver provides support for the I2S (Inter-IC
-//! Sound) Master functionality on ESP chips. It enables audio data transmission
-//! and reception with external audio devices, such as DACs (Digital-to-Analog
-//! Converters) and ADCs (Analog-to-Digital Converters) through the I2S
-//! interface. Also this module supports different data formats, including
-//! varying data and channel widths, different standards, such as the Philips
-//! standard and configurable pin mappings for I2S clock (BCLK), word select
-//! (WS), and data input/output (DOUT/DIN).
+//!
+//! ## Configuration
+//! I2S supports different data formats, including varying data and channel
+//! widths, different standards, such as the Philips standard and configurable
+//! pin mappings for I2S clock (BCLK), word select (WS), and data input/output
+//! (DOUT/DIN).
//!
//! The driver uses DMA (Direct Memory Access) for efficient data transfer and
//! supports various configurations, such as different data formats, standards
@@ -20,8 +23,7 @@
//! - `system` (to configure and enable the I2S peripheral)
//!
//! ## Examples
-//!
-//! ### initialization
+//! ### Initialization
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::i2s::I2s;
@@ -73,6 +75,10 @@
//! }
//! # }
//! ```
+//!
+//! ## Implementation State
+//! - Only master mode is supported.
+//! - Only TDM Philips standard is supported.
use core::marker::PhantomData;
diff --git a/esp-hal/src/otg_fs.rs b/esp-hal/src/otg_fs.rs
index 91d9b191b0e..63c8c673de2 100644
--- a/esp-hal/src/otg_fs.rs
+++ b/esp-hal/src/otg_fs.rs
@@ -1,11 +1,13 @@
-//! # USB OTG full-speed peripheral
+//! # USB On-The-Go (USB OTG)
//!
//! ## Overview
-//! The USB OTG Full-speed peripheral driver provides support for the USB
-//! On-The-Go (OTG) full-speed functionality on ESP chips, allows communication
+//! The USB OTG Full-speed (FS) peripheral allows communication
//! with USB devices using either blocking (usb-device) or asynchronous
//! (embassy-usb) APIs.
//!
+//! It can operate as either a USB Host or Device, and supports full-speed (FS)
+//! and low-speed (LS) data rates of the USB 2.0 specification.
+//!
//! The blocking driver uses the `esp_synopsys_usb_otg` crate, which provides
//! the `USB bus` implementation and `USB peripheral traits`.
//!
@@ -15,6 +17,7 @@
//! The module also relies on other peripheral modules, such as `GPIO`,
//! `system`, and `clock control`, to configure and enable the `USB` peripheral.
//!
+//! ## Configuration
//! To use the USB OTG Full-speed peripheral driver, you need to initialize the
//! peripheral and configure its settings. The [`Usb`] struct represents the USB
//! peripheral and requires the GPIO pins that implement [`UsbDp`], and
@@ -23,6 +26,15 @@
//! The returned `Usb` instance can be used with the `usb-device` crate, or it
//! can be further configured with [`asynch::Driver`] to be used with the
//! `embassy-usb` crate.
+//!
+//! ## Examples
+//! Visit the [USB Serial] example for an example of using the USB OTG
+//! peripheral.
+//!
+//! [USB Serial]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/usb_serial.rs
+//!
+//! ## Implementation State
+//! - Low-speed (LS) is not supported.
pub use esp_synopsys_usb_otg::UsbBus;
use esp_synopsys_usb_otg::UsbPeripheral;
diff --git a/esp-hal/src/parl_io.rs b/esp-hal/src/parl_io.rs
index a24d07d910b..5b0e17ed91d 100644
--- a/esp-hal/src/parl_io.rs
+++ b/esp-hal/src/parl_io.rs
@@ -1,112 +1,27 @@
-//! # Parallel IO
+//! # Parallel IO (PARL_IO)
//!
+//! ## Overview
//! The Parallel IO peripheral is a general purpose parallel interface that can
//! be used to connect to external devices such as LED matrix, LCD display,
//! Printer and Camera. The peripheral has independent TX and RX units. Each
//! unit can have up to 8 or 16 data signals (depending on your target hardware)
//! plus 1 or 2 clock signals.
//!
+//! ## Configuration
//! The driver uses DMA (Direct Memory Access) for efficient data transfer.
//!
//! ## Examples
-//!
-//! ### Initialization for TX
-//! ```rust, no_run
-#![doc = crate::before_snippet!()]
-//! # use esp_hal::gpio::Io;
-//! # use esp_hal::dma_buffers;
-//! # use esp_hal::dma::{Dma, DmaPriority};
-//! # use esp_hal::parl_io::{ClkOutPin, no_clk_pin, BitPackOrder, ParlIoTxOnly, SampleEdge, TxFourBits, TxPinConfigWithValidPin};
-//! # use crate::esp_hal::prelude::_fugit_RateExtU32;
-//!
-//! # let io = Io::new(peripherals.GPIO, peripherals.IO_MUX);
-//!
-//! # let dma = Dma::new(peripherals.DMA);
-//! # let dma_channel = dma.channel0;
-//!
-//! let (tx_buffer, tx_descriptors, _, _) = dma_buffers!(32000, 0);
-//! let buffer = tx_buffer;
-//!
-//! // configure the data pins to use
-//! let tx_pins = TxFourBits::new(io.pins.gpio1, io.pins.gpio2, io.pins.gpio3,
-//! io.pins.gpio4);
-//!
-//! // configure the valid pin which will be driven high during a TX transfer
-//! let mut pin_conf = TxPinConfigWithValidPin::new(tx_pins, io.pins.gpio5);
-//!
-//! let mut parl_io = ParlIoTxOnly::new(
-//! peripherals.PARL_IO,
-//! dma_channel.configure(
-//! false,
-//! DmaPriority::Priority0,
-//! ),
-//! tx_descriptors,
-//! 1.MHz(),
-//! &clocks,
-//! )
-//! .unwrap();
-//!
-//! // configure a pin for the clock signal
-//! let mut cp = ClkOutPin::new(io.pins.gpio6);
-//!
-//! let mut parl_io_tx = parl_io
-//! .tx
-//! .with_config(
-//! &mut pin_conf,
-//! &mut cp,
-//! 0,
-//! SampleEdge::Normal,
-//! BitPackOrder::Msb,
-//! )
-//! .unwrap();
-//!
-//! let mut transfer = parl_io_tx.write_dma(&buffer).unwrap();
-//!
-//! transfer.wait().unwrap();
-//! # }
-//! ```
-//!
//! ### Initialization for RX
-//! ```rust, no_run
-#![doc = crate::before_snippet!()]
-//! # use esp_hal::gpio::Io;
-//! # use esp_hal::dma_buffers;
-//! # use esp_hal::dma::{Dma, DmaPriority};
-//! # use esp_hal::parl_io::{no_clk_pin, BitPackOrder, ParlIoRxOnly, RxFourBits};
-//! # use crate::esp_hal::prelude::_fugit_RateExtU32;
-//!
-//! # let io = Io::new(peripherals.GPIO, peripherals.IO_MUX);
+//! See the [Parallel IO RX] example to learn how to initialize the RX and
+//! reading data.
//!
-//! # let dma = Dma::new(peripherals.DMA);
-//! # let dma_channel = dma.channel0;
+//! [Parallel IO RX]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/parl_io_rx.rs
//!
-//! let mut rx_pins = RxFourBits::new(io.pins.gpio1, io.pins.gpio2,
-//! io.pins.gpio3, io.pins.gpio4);
-//!
-//! let (_, _, rx_buffer, rx_descriptors) = dma_buffers!(0, 32000);
-//! let mut buffer = rx_buffer;
-//!
-//! let parl_io = ParlIoRxOnly::new(
-//! peripherals.PARL_IO,
-//! dma_channel.configure(
-//! false,
-//! DmaPriority::Priority0,
-//! ),
-//! rx_descriptors,
-//! 1.MHz(),
-//! &clocks,
-//! )
-//! .unwrap();
-//!
-//! let mut parl_io_rx = parl_io
-//! .rx
-//! .with_config(&mut rx_pins, no_clk_pin(), BitPackOrder::Msb, Some(0xfff))
-//! .unwrap();
+//! ### Initialization for TX
+//! See the [Parallel IO TX] example to learn how to initialize the TX and
+//! transferring data.
//!
-//! let mut transfer = parl_io_rx.read_dma(&mut buffer).unwrap();
-//! transfer.wait().unwrap();
-//! # }
-//! ```
+//! [Parallel IO TX]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/parl_io_tx.rs
#![warn(missing_docs)]
diff --git a/esp-hal/src/peripheral.rs b/esp-hal/src/peripheral.rs
index 6aa24f30820..da05b07c551 100644
--- a/esp-hal/src/peripheral.rs
+++ b/esp-hal/src/peripheral.rs
@@ -6,6 +6,7 @@
//! exclusive reference to a peripheral. It offers memory efficiency benefits
//! for zero-sized types.
//!
+//! ## Configuration
//! The `PeripheralRef` struct is used to access and interact with peripherals.
//! It implements the `Deref` and `DerefMut` traits, allowing you to dereference
//! it to access the underlying peripheral. It also provides methods for cloning
diff --git a/esp-hal/src/prelude.rs b/esp-hal/src/prelude.rs
index 216eb3d197c..7dd64ad8581 100644
--- a/esp-hal/src/prelude.rs
+++ b/esp-hal/src/prelude.rs
@@ -1,7 +1,10 @@
-//! The prelude
+//! # The `esp-hal` Prelude
//!
-//! Re-exports all traits required for interacting with the various peripheral
-//! drivers implemented in this crate.
+//! ## Overview
+//! The prelude is the list of things that `esp-hal` automatically imports into
+//! every program. It’s kept as small as possible, and is focused on
+//! things, particularly traits, which are used in almost every single Rust
+//! program.
pub use embedded_dma::{
ReadBuffer as _embedded_dma_ReadBuffer,
diff --git a/esp-hal/src/reset.rs b/esp-hal/src/reset.rs
index d50947f1d15..a1b18f62fce 100644
--- a/esp-hal/src/reset.rs
+++ b/esp-hal/src/reset.rs
@@ -1,32 +1,19 @@
//! # Hardware and Software Reset
//!
//! ## Overview
-//! The Hardware and Software Reset module provides functions for performing
-//! hardware and software resets on ESP chips. It also includes functions for
+//! Espressif chips provide four types of reset that occur at different levels,
+//! namely CPU Reset, Core Reset, System Reset, and Chip Reset. All reset types
+//! mentioned above (except Chip Reset) preserve the data stored in internal
+//! memory.
+//!
+//! The Hardware and Software Reset module provides functions for
+//! performing hardware and software resets and includes functions for
//! retrieving the reset reason and the wakeup cause after a reset.
//!
//! The module defines a set of sleep sources (`SleepSource`) that indicate the
-//! source of the wakeup event. These sources include:
-//! - external signals
-//! - timers
-//! - touchpads
-//! - ULP programs
-//! - GPIOs
-//! - UART
-//! - Wi-Fi
-//! - COCPU interrupts
-//! - BT (Bluetooth)
-//!
-//! The module also includes a set of flags (`WakeupReason`) that represent
-//! different wakeup sources and enable/disable wakeup triggers for specific
-//! events such as:
-//! - GPIO
-//! - timers
-//! - UART
-//! - touch sensors
-//! - ULP
-//! - Wi-Fi
-//! - BT
+//! source of the wakeup event. It also includes a set of flags (`WakeupReason`)
+//! that represent different wakeup sources and enable/disable wakeup triggers
+//! for specific events.
use crate::rtc_cntl::SocResetReason;
diff --git a/esp-hal/src/rmt.rs b/esp-hal/src/rmt.rs
index 720d7ff7c63..fc8d9dbb4c1 100644
--- a/esp-hal/src/rmt.rs
+++ b/esp-hal/src/rmt.rs
@@ -1,11 +1,13 @@
//! # Remote Control Peripheral (RMT)
//!
//! ## Overview
-//! The RMT (Remote Control Transceiver) peripheral was designed to act as an
-//! infrared transceiver. However, due to the flexibility of its data format,
-//! RMT can be extended to a versatile and general-purpose transceiver,
-//! transmitting or receiving many other types of signals.
-//!
+//! The RMT (Remote Control) module is designed to send and receive infrared
+//! remote control signals. A variety of remote control protocols can be
+//! encoded/decoded via software based on the RMT module. The RMT module
+//! converts pulse codes stored in the module’s built-in RAM into output
+//! signals, or converts input signals into pulse codes and stores them in RAM.
+//! In addition, the RMT module optionally modulates its output signals with a
+//! carrier wave, or optionally demodulates and filters its input signals.
//!
//! Typically, the RMT peripheral can be used in the following scenarios:
//! - Transmit or receive infrared signals, with any IR protocols, e.g., NEC
@@ -15,7 +17,7 @@
//! - Modulate the carrier to the output signal or demodulate the carrier from
//! the input signal
//!
-//! ## Channels
+//! ### Channels
//! There are
#![cfg_attr(
esp32,
@@ -36,10 +38,14 @@
#![doc = " "]
//! For more information, please refer to the
#![doc = concat!("[ESP-IDF documentation](https://docs.espressif.com/projects/esp-idf/en/latest/", crate::soc::chip!(), "/api-reference/peripherals/rmt.html)")]
-//! ## Examples
+//! ## Configuration
+//! Each TX/RX channel has the same functionality controlled by a dedicated set
+//! of registers and is able to independently transmit or receive data. TX
+//! channels are indicated by n which is used as a placeholder for the channel
+//! number, and by m for RX channels.
//!
+//! ## Examples
//! ### Initialization
-//!
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::peripherals::Peripherals;
diff --git a/esp-hal/src/rng.rs b/esp-hal/src/rng.rs
index 3014a15366c..3b3f4a3fe33 100644
--- a/esp-hal/src/rng.rs
+++ b/esp-hal/src/rng.rs
@@ -1,25 +1,10 @@
-//! # Random Number Generator
+//! # Random Number Generator (RNG)
//!
//! ## Overview
-//! The Random Number Generator (RNG) Driver for ESP chips is a software module
-//! that provides an interface to generate random numbers using the RNG
-//! peripheral on ESP chips. This driver allows you to generate random numbers
-//! that can be used for various cryptographic, security, or general-purpose
-//! applications.
-//!
-//! The RNG peripheral on ESP chips produces random numbers based on physical
-//! noise sources, which provide true random numbers under specific conditions
-//! (see conditions below).
-//!
-//! To use the [Rng] Driver, you need to initialize it with the RNG peripheral.
-//! Once initialized, you can generate random numbers by calling the `random`
-//! method, which returns a 32-bit unsigned integer.
-//!
-//! Additionally, this driver implements the
-//! [Read](embedded_hal_02::blocking::rng::Read) trait from the `embedded_hal`
-//! crate, allowing you to generate random bytes by calling the `read` method.
-//
-//! # Important Note
+//! The Random Number Generator (RNG) module provides an interface to generate
+//! random numbers using the RNG peripheral on ESP chips. This driver allows you
+//! to generate random numbers that can be used for various cryptographic,
+//! security, or general-purpose applications.
//!
//! There are certain pre-conditions which must be met in order for the RNG to
//! produce *true* random numbers. The hardware RNG produces true random numbers
@@ -41,6 +26,23 @@
//!
//! For more information, please refer to the
#![doc = concat!("[ESP-IDF documentation](https://docs.espressif.com/projects/esp-idf/en/latest/", crate::soc::chip!(), "/api-reference/system/random.html)")]
+//! ## Configuration
+//! To use the [Rng] Driver, you need to initialize it with the RNG peripheral.
+//! Once initialized, you can generate random numbers by calling the `random`
+//! method, which returns a 32-bit unsigned integer.
+//!
+//! ## Usage
+//! This driver implements the [Read](embedded_hal_02::blocking::rng::Read)
+//! trait from the `embedded_hal` crate, allowing you to generate random bytes
+//! by calling the `read` method. The driver also implements the traits from the
+//! [`rand_core`] crate.
+//!
+//! [`rand_core`]: https://crates.io/crates/rand_core
+//!
+//! ## Examples
+//! Visit the [RNG] example for an example of using the RNG peripheral.
+//!
+//! [RNG]: https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/rng.rs
use core::marker::PhantomData;
diff --git a/esp-hal/src/sha.rs b/esp-hal/src/sha.rs
index 092e22a2c3f..9c812087b9b 100644
--- a/esp-hal/src/sha.rs
+++ b/esp-hal/src/sha.rs
@@ -1,11 +1,12 @@
-//! # Secure Hash Algorithm peripheral driver
+//! # Secure Hash Algorithm (SHA) Accelerator
//!
//! ## Overview
-//! This SHA (Secure Hash Algorithm) driver for ESP chips is a software module
-//! that provides an interface to interact with the SHA peripheral on ESP
-//! microcontroller chips. This driver allows you to perform cryptographic hash
-//! operations using various hash algorithms supported by the SHA peripheral,
-//! such as:
+//! This SHA accelerator is a hardware device that speeds up the SHA algorithm
+//! significantly, compared to a SHA algorithm implemented solely in software
+//!
+//! ## Configuration
+//! This driver allows you to perform cryptographic hash operations using
+//! various hash algorithms supported by the SHA peripheral, such as:
//! * SHA-1
//! * SHA-224
//! * SHA-256
@@ -14,7 +15,7 @@
//!
//! The driver supports two working modes:
//! * Typical SHA
-//! * DMA-SHA (Direct Memory Access SHA is NOT implemented yet).
+//! * DMA-SHA
//!
//! It provides functions to update the hash calculation with input data, finish
//! the hash calculation and retrieve the resulting hash value. The SHA
@@ -27,7 +28,7 @@
//! to retrieve the hash value and repeat the process for a new hash calculation
//! if needed.
//!
-//! ## Example
+//! ## Examples
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::sha::Sha;
@@ -60,6 +61,8 @@
//!
//! # }
//! ```
+//! ## Implementation State
+//! - DMA-SHA Mode is not supported.
use core::{convert::Infallible, marker::PhantomData};
diff --git a/esp-hal/src/system.rs b/esp-hal/src/system.rs
index a741baebad0..dae540b9b65 100755
--- a/esp-hal/src/system.rs
+++ b/esp-hal/src/system.rs
@@ -20,7 +20,7 @@
//! It provides an `enable()` method to enable and reset specific peripherals.
//! The available peripherals are represented by the `Peripheral` enum
//!
-//! ## Example
+//! ## Examples
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! let peripherals = Peripherals::take();
diff --git a/esp-hal/src/time.rs b/esp-hal/src/time.rs
index 8341c676e96..26ad3180359 100644
--- a/esp-hal/src/time.rs
+++ b/esp-hal/src/time.rs
@@ -1,6 +1,9 @@
+//! # Time
+//!
+//! ## Overview
//! The `time` module offers a way to get the system uptime.
//!
-//! ### Example
+//! ## Examples
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::time;
diff --git a/esp-hal/src/trace.rs b/esp-hal/src/trace.rs
index 9cdaa317604..ef6d2a35ca0 100644
--- a/esp-hal/src/trace.rs
+++ b/esp-hal/src/trace.rs
@@ -1,7 +1,6 @@
-//! # RISCV Trace Encoder (TRACE)
+//! # RISC-V Trace Encoder (TRACE)
//!
//! ## Overview
-//!
//! The high-performance CPU supports instruction trace interface through the
//! trace encoder. The trace encoder connects to HP CPU’s instruction trace
//! interface, compresses the information into smaller packets, and then stores
@@ -19,7 +18,7 @@
//! That is where instruction trace comes in, which provides trace of the
//! program execution.
//!
-//! ## Example
+//! ## Examples
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::trace::Trace;
diff --git a/esp-hal/src/uart.rs b/esp-hal/src/uart.rs
index 8c15b8ab256..c33cc2602f3 100644
--- a/esp-hal/src/uart.rs
+++ b/esp-hal/src/uart.rs
@@ -1,5 +1,6 @@
//! # Universal Asynchronous Receiver/Transmitter (UART)
//!
+//! ## Overview
//! The UART is a hardware peripheral which handles communication using serial
//! communication interfaces, such as RS232 and RS485. This peripheral provides
//! a cheap and ubiquitous method for full- and half-duplex communication
@@ -12,7 +13,6 @@
//! protocols.
//!
//! ## Configuration
-//!
//! Each UART controller is individually configurable, and the usual setting
//! such as baud rate, data bits, parity, and stop bits can easily be
//! configured. Additionally, the transmit (TX) and receive (RX) pins need to
@@ -35,7 +35,6 @@
//! UART instance using the inverted pins.
//!
//! ## Usage
-//!
//! The UART driver implements a number of third-party traits, with the
//! intention of making the HAL inter-compatible with various device drivers
//! from the community. This includes, but is not limited to, the [embedded-hal]
@@ -46,9 +45,8 @@
//! available. See the examples below for more information on how to interact
//! with this driver.
//!
-//! ### Examples
-//!
-//! #### Sending and Receiving Data
+//! ## Examples
+//! ### Sending and Receiving Data
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::uart::{config::Config, Uart};
@@ -67,7 +65,7 @@
//! # }
//! ```
//!
-//! #### Splitting the UART into TX and RX Components
+//! ### Splitting the UART into TX and RX Components
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::uart::{config::Config, Uart};
@@ -90,7 +88,7 @@
//! # }
//! ```
//!
-//! #### Inverting TX and RX Pins
+//! ### Inverting TX and RX Pins
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::uart::{config::Config, Uart};
@@ -103,7 +101,7 @@
//! # }
//! ```
//!
-//! #### Constructing TX and RX Components
+//! ### Constructing TX and RX Components
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! # use esp_hal::uart::{config::Config, UartTx, UartRx};
diff --git a/esp-hal/src/usb_serial_jtag.rs b/esp-hal/src/usb_serial_jtag.rs
index 9a8622c2bcb..db30ef9fd16 100644
--- a/esp-hal/src/usb_serial_jtag.rs
+++ b/esp-hal/src/usb_serial_jtag.rs
@@ -1,5 +1,6 @@
-//! USB Serial/JTAG Controller
+//! USB Serial/JTAG Controller (USB_SERIAL_JTAG)
//!
+//! ## Overview
//! The USB Serial/JTAG controller can be used to program the SoC's flash, read
//! program output, or attach a debugger to the running program. This is
//! possible for any computer with a USB host (hereafter referred to as 'host'),
@@ -26,7 +27,6 @@
//! connect to a host computer
//!
//! ## Usage
-//!
//! The USB Serial/JTAG driver implements a number of third-party traits, with
//! the intention of making the HAL inter-compatible with various device drivers
//! from the community. This includes, but is not limited to, the [embedded-hal]
@@ -38,9 +38,7 @@
//! with this driver.
//!
//! ## Examples
-//!
//! ### Sending and Receiving Data
-//!
//! ```rust, no_run
#![doc = crate::before_snippet!()]
//! use esp_hal::usb_serial_jtag::UsbSerialJtag;