nrf-hal: one Rust hardware abstraction layer per Nordic nRF chip, and a gap at nRF54

One crate per chip, because each part needs a different target triple

nrf-hal is a hardware abstraction layer for the nRF51, nRF52 and nRF91 families of microcontrollers, implemented against the `embedded-hal` interface. The publishing decision is the first thing to understand. Every nRF chip has its own crate, and the README's table pairs each one with its documentation, its crates.io page, and the Rust target it builds for. The `nrf51-hal` crate targets `thumbv6m-none-eabi`, the `nrf52805-hal`, `nrf52810-hal`, and `nrf52811-hal` crates target `thumbv7em-none-eabi`, the `nrf52832-hal`, `nrf52833-hal`, and `nrf52840-hal` crates target `thumbv7em-none-eabihf`, and the `nrf9160-hal` crate targets `thumbv8m.main-none-eabihf`. So this is not one library with a feature flag per peripheral. It is a family of libraries, and picking the crate is part of choosing the chip.

The repository holds a common crate and a directory per device

Based on the repository layout, the code is split so that the shared parts live in one place and the chip-specific parts live in their own directories. There is a `nrf-hal-common` directory alongside `nrf51-hal`, `nrf52805-hal`, `nrf52810-hal`, `nrf52811-hal`, `nrf52832-hal`, `nrf52833-hal`, `nrf52840-hal`, and `nrf9160-hal`. A `nrf52840-hal-tests` directory exists for the tests of the most used part, and there are `nrf5340-app-hal` and `nrf5340-net-hal` directories for the application core and network core of that chip. The `examples/` directory is extensive, with a separate example per peripheral family: `blinky-button-demo`, `ccm-demo`, `comp-demo`, `ecb-demo`, `gpiote-demo`, `hello-world`, `i2s-controller-demo`, `i2s-peripheral-demo`, `lpcomp-demo`, `monotonic-blinky`, `nvmc-demo`, `ppi-demo`, `pwm-blinky-demo`, `pwm-demo`, `qdec-demo`, `rtc-demo`, `rtic-demo`, `spi-demo`, `spis-demo`, `twi-ssd1306`, `twim-demo`, `twis-demo`, and `twis-dma-demo`. The breadth of that list is a better feature catalogue than any prose summary.

Development starts by copying a template Cargo.toml

There is no install command in the README, because this is a library rather than an application, so the setup is a dependency line and a target choice. The repository tells you how to work on it, and the instruction is to copy and edit the `Cargo.example.toml` file to `Cargo.toml`. The file will require editing depending on the target you wish to work with, and it contains some further instructions. There is a parallel note for editor setup, checking out the `.vscode/settings.json` file when used in the context of Visual Studio Code. By default, all of these files are configured to work with the nRF52840 target, which is a sensible default for a developer and a trap for anyone who forgets to change it. There is also a `Cargo.ci.toml` for continuous integration and an `xtask` directory, which is the conventional Rust place for repository automation tasks.

The README points at Nordic's own documentation for the hardware details

A hardware abstraction layer is only as good as the register documentation behind it, and nrf-hal does not try to replace that. The README includes a table of device reference manuals from Nordic, mapping each supported device to its product specification and to the DK reference guide for its development kit, with version numbers for each. The nRF52805, nRF52810, nRF52811, nRF52832, nRF52833, nRF52840 and nRF9160 all have entries, and a footnote notes that some of these devices do not have a separate development kit and share the NRF52 DK instead. The versions are pinned in the table, which tells you the maintainers track Nordic's documentation revisions. This is a deliberate division of labour. The HAL gives you a safe Rust interface, and the vendor documentation remains the authority on what the peripheral actually does, which is a good thing for a register-level library.

nRF54 is not covered, and the README says to use embassy-nrf

The one real gap in this project is stated in a single sentence near the end of the hardware section. There are currently no crates for nRF54 parts, pull requests are welcome, and in the meantime the README recommends the `embassy-nrf` crate for this purpose. It adds a clarification that matters: in spite of its name, `embassy-nrf` also supplies a normal `embedded-hal` style interface. So the migration advice is not a step down in abstraction level, it is a different crate with a different name. The distinction between the two approaches is that nrf-hal is a family of per-chip crates, while the recommendation points at a crate that covers the newer family under a different organisation. If your hardware is nRF54, this repository is the wrong starting point and no amount of configuration will change that.

The release history is old while the repository is not

The maintenance picture needs two numbers read together, because on their own each is misleading. The release list shows v0.15.0 on 2022-02-11, v0.15.1 on 2022-05-31, and v0.16.0 on 2022-10-26. By the standard of published crates, nothing has been released in a long time. The last push, however, was on 2026-09-10, and the repository carries a CI workflow badge, a `CHANGELOG.md`, a `CONTRIBUTING.md`, and an `xtask` directory. The README also points you at the changelog to see what changed in the last releases, which is the document to read before upgrading. The likely reading is that the work continues on the master branch while the released 0.16 line sits where it was left, but the README does not say that outright, so the honest advice is to check the changelog and the branch state for yourself rather than assume either story.

Dual licensed, so it drops into most firmware without a licence review

The licence is the easiest part of the decision. nrf-hal is licensed under either the Apache License, Version 2.0, with the text in the LICENSE-APACHE file, or the MIT license, with the text in LICENSE-MIT, at your option. The repository root carries both files, so a team whose compliance process prefers MIT can take that path, and a team that wants the Apache patent grant can take the other. The contribution rules are explicit about the default. Unless you state otherwise, any contribution intentionally submitted for inclusion in the work, as defined in the Apache-2.0 license, is dual licensed on the same terms without any additional conditions. The GitHub repository license metadata records Apache-2.0, which matches the primary option but understates the choice, so the LICENSE-APACHE and LICENSE-MIT files are what to read.

Editorial conclusion

nrf-hal fits a Rust embedded team targeting a specific nRF51, nRF52, or nRF91 part that already wants an `embedded-hal` style interface, and who prefer a per-chip crate over one crate with runtime feature flags. It is the wrong choice for nRF54 hardware, since the README states there are no crates for those parts and recommends `embassy-nrf` instead. Before you adopt it, copy `Cargo.example.toml` to `Cargo.toml` and edit it for your target, check the CHANGELOG, because the newest listed release is v0.16.0 from 2022 while the last push was on 2026-09-10, and decide which HAL you want before you write peripheral code against it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nrf-rs/nrf-hal on GitHub
4. README
5. Releases