Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
STM32-HAL
This library provides high-level access to STM32 peripherals.
Requirements
- Provide high-level access to most STM32 peripherals
- Support these STM32 families:
F3
,F4
,L4
,L5
,G
,H
,U
, andW
- Allow switching MCUs with minimal code change
- Provide a consistent API across peripheral modules
- Support both DMA and non-DMA interfaces
- Be suitable for commercial projects
- Implement embedded-hal traits for all applicable peripherals
- Provide a clear, concise API
Specifications
- Base code on instructions described in reference manuals (RM); document inline with the relevant excerpts [4]
- Use STM32 Peripheral Access Crates to allow high-level register access [2]
- Wrap PAC register blocks in structs that represent the applicable peripheral, and access features of these peripherals using public methods [1]
- Use
#[cfg]
blocks, and thecfg_if!
macro to handle differences between MCUs; use separate modules where large differences exist [2, 3] - Use both peripheral struct methods, and
embedded-hal
trait implementations for non-DMA interfaces; use additional struct methods for DMA interfaces [4, 5, 7] - Favor functionality, ergonomics, and explicit interfaces [6, 8]
- Provide examples and documentation that demonstrate peripheral use with interrupts and DMA [6]
Current family support: F3, F4, L4, L5, G0, G4, H7, and WB. U5 is planned once its SVD files and PAC become available. WL support is a WIP, with many features not implemented.
Getting started
Review the syntax overview example
for example uses of many of this library's features. Copy and paste its whole folder (It's set up
using Knurling's app template), or copy parts of Cargo.toml
and main.rs
as required.
The blinky example, written by toudi, provides a detailed example and instructions for how to set up a blinking light (ie hello world) using an STM32F411 "blackpill" board. Its readme provides instructions for how to get started from scratch, and its code contains detailed comments explaining each part.
The conductivity module example is a complete example of simple production firmware. It uses the DAC, I2C, Timer, and UART peripherals, with a simple interupt-based control flow.
Additional examples in the examples folder demonstrate how to use various STM32 peripherals; most of these examples focus on a single peripheral.
When specifying this crate as a dependency in Cargo.toml
, you need to specify a feature
representing your MCU. If this is for code that runs on an MCU directly (ie not a library), also
include a run-time feature, following the template l4rt
. For example:
= "0.7.3"
= "0.6.13"
= { = "^1.0.0", = ["l4x3", "l4rt"]}
If you need embedded-hal
traits, include the embedded-hal
feature.
You can review this section of Cargo.toml to see which MCU and runtime features are available.
Example highlights:
use cortex_m;
use entry;
use ;
!
Why this module is different from stm32yxx-hal
libraries
There are some areas where design philosophy is different. For example: GPIO
type-checking, level-of-abstraction from registers/PAC, role of DMA, role of embedded-hal
traits in the API,
feature parity among STM32 families, code documentation, and clock config.
Docs caveat
The Rust docs page is built for STM32L4x3
, and some aspects are not accurate for other
variants. We currently don't have a good solution to this problem, and may
self-host docs in the future.
Contributing
PRs are encouraged. Documenting each step using reference manuals is encouraged where applicable.
Most peripheral modules use the following format:
- Enums for various config settings, that implement
#[repr(u8)]
for their associated register values - A peripheral struct that has public fields for config. This struct also includes
a private
regs
field that is the appropriate reg block. Where possible, this is defined generically in the implementation, eg:U: Deref<Target = pac::usart1::RegisterBlock>
. Reference the stm32-rs-nightlies Github to identify when we can take advantage of this. - If config fields are complicated, we use a separate
PeriphConfig
struct owned by the peripheral struct. This struct implsDefault
. - A constructor named
new
that performs setup code enable_interrupt
andclear_interrupt
functions, which accept an enum of interrupt type.- Add
embedded-hal
implementations as required, that call native methods. Note that we design APIs based on STM32 capabilities, and apply EH traits as applicable. We only expose these implementations if theembedded-hal
feature is selected. - When available, base setup and usage steps on instructions provided in Reference Manuals. These steps are copy+pasted in comments before the code that performs each one.
- Don't use PAC convenience field settings; they're implemented inconsistently across PACs.
(eg don't use something like
en.enabled()
; useen.set_bit()
.) - If using a commonly-named configuration enum like
Mode
, prefix it with the peripheral type, eg useRadarMode
instead. This prevents namespace conflicts when importing the enums directly.
Example module structure:
/// Select pulse repetition frequency. Modifies `FCRDR_CR` register, `PRF` field.
/// Available interrupts. Enabled in `FCRDR_CR`, `...IE` fields. Cleared in `FCRDR_ICR`.
/// Represents a Fire Control Radar (FCR) peripheral.
/// Wrap our native methods with `embedded-hal` traits.
STM32WB and WL radio
This library doesn't include any radio functionality for the STM32WB. If you'd like to use it with bluetooth, use this HAL in conjuction with with @eupn's stm32wb55 bluetooth library.
STM32WL radio support is WIP, and will be provided through interaction withnewAM's stm32wl-hal library.
Errata
- SDIO and ethernet unimplemented
- SAI unimplemented on G4
- DMA unimplemented on F4
- The DMA2 peripheral is unimplemented
- Only bxCAN is implemented - the fdCAN used on newer families is unimplemented
- USB unimplemented for H7
- USART synchronous mode, and auto-baud-rate detection unimplemented
- USART interrupts unimplemented on F4
- H7 clocks are missing advanced features
- H7 clock default is suitable for single-core 480Mhz variants only.
- PWM input unimplemented
- CRC unimplemented for L5, F4, G0, and G4
- Flash read/write unimplemented on H7
- Low power timers (LPTIM) and low power usart (LPUSART) unimplemented
- ADC unimplemented on F4
- ADC3 unimplemented on H7
- Low power modes beyond csleep and cstop aren't implemented for H7
- WB and WL are missing features relating to second core operations and RF
- WL is missing support for many peripherals
- L4+ MCUs not supported