This repository provides Rust device support crates for all STM32 microcontrollers, providing a safe API to that device's peripherals using svd2rust and a community-built collection of patches to the basic SVD files. There is one crate per device family, and each supported device is a feature-gated module in that crate. These crates are commonly known as peripheral access crates or "PACs".
To view the generated code that makes up each crate, visit the stm32-rs-nightlies repository, which is automatically rebuilt on every commit to stm32-rs master. The stm32-rs repository contains the patches to the underlying SVD files and the tooling to generate the crates.
While these crates are widely used, not every register of every device will have been tested on hardware, and so errors or omissions may remain. We can't make any guarantee of correctness. Please report any bugs you find!
You can see current coverage status for each chip here. Coverage means that individual fields are documented with possible values, but even devices with low coverage should have every register and field available in the API. That page also allows you to drill down into each field on each register on each peripheral.
Using Device Crates In Your Own ProjectIn your own project's Cargo.toml
:
[dependencies.stm32f4] version = "0.16.0" features = ["stm32f405", "rt"]
The rt
feature is optional but helpful. See svd2rust for details.
Then, in your code:
use stm32f4::stm32f405; let mut peripherals = stm32f405::Peripherals::take().unwrap();
Refer to svd2rust
documentation for further usage.
Replace stm32f4
and stm32f405
with your own device; see the individual crate READMEs for the complete list of supported devices. All current STM32 devices should be supported to some level.
Whenever the master branch of this repository is updated, all device crates are built and deployed to the stm32-rs-nightlies repository. You can use this in your Cargo.toml
:
[dependencies.stm32f4] git = "https://github.com/stm32-rs/stm32-rs-nightlies" features = ["stm32f405", "rt"]
The nightlies should always build and be as stable as the latest release, but contain the latest patches and updates.
Generating Device Crates / Building Locallysvd2rust
, svdtools
, and form
:
make install
to download pre-built binaries at the current version used by stm32-rscargo
(double check versions against scripts/tool_install.sh
):
cargo install form --version 0.13.0
cargo install svdtools --version 0.5.0
cargo install svd2rust --version 0.36.1
rustup component add rustfmt
make patch
(you probably want -j
for all make
invocations)
cargo-make
runner and then use it instead of make
. Works on MS Windows natively:
cargo install cargo-make
cargo make patch
make svd2rust
make form
Basically, the full process is:
+--------------------------+ +------------------------+ +--------------------------+ +--------------------------+
| ST-supplied SVD archives | | SVD peripheral patches | | Peripheral fields detail | | Perip. fields collecting |
| in 'svd/vendor/' | | in 'devices/patches/' | | in 'devices/fields' | | in 'devices/collect' |
+--------------------------+ +------------------------+ +--------------------------+ +--------------------------+
| | | |
| | (optional) (optional)
`make extract` | | |
| +----------------------------+-----------------------------+
| |
v v
+----------------------------+ +--------------------------+
| ST-supplied SVD files | | SVD device changes |
| in 'svd/' | | in 'devices/' |
+----------------------------+ +--------------------------+
| |
+---------------------------+----------------------------+
|
`make patch`
(using svdtools)
|
v
+------------------------+
| Patched SVD files |
| in 'svd/' |
+------------------------+
|
`make svd2rust`
|
v
+------------------------+
| Generated STM32 crates |
| in 'stm32*/' |
+------------------------+
|
`make form` (optional)
|
v
+------------------------+
| Formatted STM32 crates |
| in 'stm32*/' |
+------------------------+
Motivation and Objectives
This project serves two purposes:
When this project began, many individual crates existed for specific STM32 devices, typically maintained separately with hand-edited updates to the SVD files. This project hopes to reduce that duplication of effort and centralise the community's STM32 device support in one place.
This project is still young and there's a lot to do!
devices/
and grab a reference manual!
stm32*.yaml
file is a patch for a specific device SVD.devices/patches
. Search there if a patch you want to add doesn't already exist!devices/fields
are not a part of the CMSIS-SVD specification but enable type-safe friendly-name interface (enumerated values) for highly detailed crates.devices/collect
is here for collecting in array
s, cluster
s and derive
s to minimize duplication.svd/vendor
to include new SVDs.make extract
to extract the new zip files.devices/
with the new SVD path and include any required SVD patches for this device, such as renaming or merging fields.stm32_part_table.yaml
.scripts/makecrates.py
.scripts/matchperipherals.py
script to find out what existing peripherals could be cleanly applied to this new SVD. If they look sensible, you can include them in your device YAML. This requires a Python environment with the pyyaml
and svdtools
dependencies. Example command: python scripts/matchperipherals.py devices/fields/rcc devices/stm32h562.yaml
scripts/makecrates.py devices/
to update the crates with the new devices.make
to rebuild, which will make a patched SVD and then run svd2rust
on it to generate the final library.If adding a new STM32 family (not just a new device to an existing family), complete these steps as well:
CRATES
field in Makefile
.workflows/ci.yaml
and workflows/nightlies.yaml
.make extract
at least once to pull the SVDs out.make
to rebuild all the crates using svd patch
and svd2rust
.cd stm32f4; cargo build --features stm32f405
If you've added a new peripheral, consider using the matchperipherals.py
script to see which devices it would cleanly apply to.
To generate a new peripheral file from scratch, consider using periphtemplate.py
, which creates an empty peripheral file based on a single SVD file, with registers and fields ready to be populated. For single bit wide fields with names ending in 'E' or 'D' it additionally generates sample "Enabled"/"Disabled" entries to save time.
Please see the svdtools documentation for full details of the patch file format.
Notes for maintainers:
CHANGELOG.md
with changes since last release and new contributorsREADME.md
to bump version number in example snippetscripts/makecrates.py
to update version number for generated PACsmake clean
make -j16 form
for f in stm32c0 stm32f0 stm32f1 stm32f2 stm32f3 stm32f4 stm32f7 stm32h5 stm32h7 stm32l0 stm32l1 stm32l4 stm32l5 stm32g0 stm32g4 stm32mp1 stm32n6 stm32u0 stm32u5 stm32wl stm32wb; cd $f; pwd; cargo publish --allow-dirty --no-default-features; cd ..; end
git tag -a vX.X.X -m vX.X.X
git push vX.X.X
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4