ba18656e94
1177: STD driver needs a reentrant mutex; logic fixed to be reentrancy-safe r=Dirbaio a=ivmarkov ...or to summarize it in another way, the code in the alarm thread loop is written as if - when calling the user-supplied callback - the callback will *never, ever* call `alarm.set_alarm()`. But this happens of course - at least with the generic timer queue implementation. Not sure if that would happen with `embassy-executor`'s own queue, but probably yes? The end result on Linux is that the code deadlocks because when calling the user-supplied callback, the mutex of the alarms is locked, yet - the code in `set_alarm` tries to take the lock again leading to UB. (I suspect on Windows this will crash rather than deadlock but that's a bit irrelevant.) (Note also that calling the user-supplied callback *outside* of the alarms' lock is also NOK, because at that time, the callback and/or context itself might be invalid as well, as the user might had changed it with a new one by calling `set_callback`. Right?) I also had to fix the logic that computed the next timestamp when the alarm should fire; it was running a simple `for {}` loop, not anticipating that the just-traversed alarm might get a new timestamp. The new code is slightly less efficient, in that on each `loop {}` iteration it always starts traversing the alarms from the beginning, whereas in reality only the timestamp of the alarm that just-fired could've changed, but given the complexities introduced by `RefCell`, I don't think we should bother with these micro-optimizations, for just 4 alarms in total. Co-authored-by: ivmarkov <ivan.markov@gmail.com> |
||
---|---|---|
.github | ||
.vscode | ||
docs | ||
embassy-boot | ||
embassy-cortex-m | ||
embassy-embedded-hal | ||
embassy-executor | ||
embassy-futures | ||
embassy-hal-common | ||
embassy-lora | ||
embassy-macros | ||
embassy-net | ||
embassy-net-driver | ||
embassy-net-driver-channel | ||
embassy-nrf | ||
embassy-rp | ||
embassy-stm32 | ||
embassy-sync | ||
embassy-time | ||
embassy-usb | ||
embassy-usb-driver | ||
embassy-usb-logger | ||
examples | ||
stm32-data@96decdd611 | ||
stm32-gen-features | ||
stm32-metapac | ||
stm32-metapac-gen | ||
tests | ||
xtask | ||
.gitignore | ||
.gitmodules | ||
ci_stable.sh | ||
ci.sh | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
NOTICE.md | ||
README.md | ||
rust-toolchain.toml | ||
rustfmt.toml |
Embassy
Embassy is the next-generation framework for embedded applications. Write safe, correct and energy-efficient embedded code faster, using the Rust programming language, its async facilities, and the Embassy libraries.
Documentation - API reference - Website - Chat
Rust + async ❤️ embedded
The Rust programming language is blazingly fast and memory-efficient, with no runtime, garbage collector or OS. It catches a wide variety of bugs at compile time, thanks to its full memory- and thread-safety, and expressive type system.
Rust's async/await allows for unprecedently easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation, and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is faster and smaller than one!
Batteries included
-
Hardware Abstraction Layers - HALs implement safe, idiomatic Rust APIs to use the hardware capabilities, so raw register manipulation is not needed. The Embassy project maintains HALs for select hardware, but you can still use HALs from other projects with Embassy.
- embassy-stm32, for all STM32 microcontroller families.
- embassy-nrf, for the Nordic Semiconductor nRF52, nRF53, nRF91 series.
-
Time that Just Works - No more messing with hardware timers. embassy_time provides Instant, Duration and Timer types that are globally available and never overflow.
-
Real-time ready - Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities, so that higher priority tasks preempt lower priority ones. See the example.
-
Low-power ready - Easily build devices with years of battery life. The async executor automatically puts the core to sleep when there's no work to do. Tasks are woken by interrupts, there is no busy-loop polling while waiting.
-
Networking - The embassy-net network stack implements extensive networking functionality, including Ethernet, IP, TCP, UDP, ICMP and DHCP. Async drastically simplifies managing timeouts and serving multiple connections concurrently.
-
Bluetooth - The nrf-softdevice crate provides Bluetooth Low Energy 4.x and 5.x support for nRF52 microcontrollers.
-
LoRa - embassy-lora supports LoRa networking on STM32WL wireless microcontrollers and Semtech SX126x and SX127x transceivers.
-
USB - embassy-usb implements a device-side USB stack. Implementations for common classes such as USB serial (CDC ACM) and USB HID are available, and a rich builder API allows building your own.
-
Bootloader and DFU - embassy-boot is a lightweight bootloader supporting firmware application upgrades in a power-fail-safe way, with trial boots and rollbacks.
Sneak peek
use defmt::info;
use embassy_executor::Spawner;
use embassy_time::{Duration, Timer};
use embassy_nrf::gpio::{AnyPin, Input, Level, Output, OutputDrive, Pin, Pull};
use embassy_nrf::Peripherals;
// Declare async tasks
#[embassy_executor::task]
async fn blink(pin: AnyPin) {
let mut led = Output::new(pin, Level::Low, OutputDrive::Standard);
loop {
// Timekeeping is globally available, no need to mess with hardware timers.
led.set_high();
Timer::after(Duration::from_millis(150)).await;
led.set_low();
Timer::after(Duration::from_millis(150)).await;
}
}
// Main is itself an async task as well.
#[embassy_executor::main]
async fn main(spawner: Spawner) {
let p = embassy_nrf::init(Default::default());
// Spawned tasks run in the background, concurrently.
spawner.spawn(blink(p.P0_13.degrade())).unwrap();
let mut button = Input::new(p.P0_11, Pull::Up);
loop {
// Asynchronously wait for GPIO events, allowing other tasks
// to run, or the core to sleep.
button.wait_for_low().await;
info!("Button pressed!");
button.wait_for_high().await;
info!("Button released!");
}
}
Examples
Examples are found in the examples/
folder seperated by the chip manufacturer they are designed to run on. For example:
examples/nrf52840
run on thenrf52840-dk
board (PCA10056) but should be easily adaptable to other nRF52 chips and boards.examples/nrf5340
run on thenrf5340-dk
board (PCA10095).examples/stm32xx
for the various STM32 families.examples/rp
are for the RP2040 chip.examples/std
are designed to run locally on your PC.
Running examples
- Setup git submodules (needed for STM32 examples)
git submodule init
git submodule update
- Install
probe-run
with defmt support.
cargo install probe-run
- Change directory to the sample's base directory. For example:
cd examples/nrf52840
- Run the example
For example:
cargo run --bin blinky
Developing Embassy with Rust Analyzer based editors
The Rust Analyzer is used by Visual Studio Code
and others. Given the multiple targets that Embassy serves, there is no Cargo workspace file. Instead, the Rust Analyzer
must be told of the target project to work with. In the case of Visual Studio Code,
please refer to the .vscode/settings.json
file's rust-analyzer.linkedProjects
setting.
Minimum supported Rust version (MSRV)
Embassy is guaranteed to compile on the latest stable Rust version at the time of release. It might compile with older versions but that may change in any new patch release.
Several features require nightly:
- The
#[embassy_executor::main]
and#[embassy_executor::task]
attribute macros. - Async traits
These are enabled by activating the nightly
Cargo feature. If you do so, Embassy is guaranteed to compile on the exact nightly version specified in rust-toolchain.toml
. It might compile with older or newer nightly versions, but that may change in any new patch release.
Why the name?
EMBedded ASYnc! :)
License
This work is licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.