From d4c378e059443dbaaaece02a0f5148db62bd4484 Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Fri, 11 Apr 2025 14:28:59 -0700 Subject: Add embassy-imxrt CRC driver --- docs/pages/imxrt.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/pages') diff --git a/docs/pages/imxrt.adoc b/docs/pages/imxrt.adoc index adf5218e8..a84fbae03 100644 --- a/docs/pages/imxrt.adoc +++ b/docs/pages/imxrt.adoc @@ -9,5 +9,5 @@ The link: link:https://github.com/embassy-rs/embassy/tree/main/embassy-imxrt[Emb The following peripherals have a HAL implementation at present +* CRC * GPIO - -- cgit From 8e7e4332b40707e8d36338ad8ec486320bb3538f Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Fri, 11 Apr 2025 15:03:53 -0700 Subject: Add embassy-imxrt RNG driver --- docs/pages/imxrt.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/pages') diff --git a/docs/pages/imxrt.adoc b/docs/pages/imxrt.adoc index adf5218e8..9fcb6725c 100644 --- a/docs/pages/imxrt.adoc +++ b/docs/pages/imxrt.adoc @@ -10,4 +10,4 @@ The link: link:https://github.com/embassy-rs/embassy/tree/main/embassy-imxrt[Emb The following peripherals have a HAL implementation at present * GPIO - +* RNG -- cgit From d64ae225b30bc3a0f7a9b1277188b6e60fc97484 Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Thu, 10 Apr 2025 10:39:54 -0700 Subject: Add UART and DMA drivers Both blocking and async versions are supported. Add separate examples for each mode. --- docs/pages/imxrt.adoc | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs/pages') diff --git a/docs/pages/imxrt.adoc b/docs/pages/imxrt.adoc index bbd65e494..87867e1e0 100644 --- a/docs/pages/imxrt.adoc +++ b/docs/pages/imxrt.adoc @@ -10,5 +10,7 @@ The link: link:https://github.com/embassy-rs/embassy/tree/main/embassy-imxrt[Emb The following peripherals have a HAL implementation at present * CRC +* DMA * GPIO * RNG +* UART -- cgit From 035040e53cba24d7a15a055b605d50c568eb9e57 Mon Sep 17 00:00:00 2001 From: Nathan Vander Wilt Date: Tue, 27 May 2025 11:38:11 -0700 Subject: Update layer_by_layer.adoc to clarify PAC limitations proposed fix for #4226, re. https://github.com/embassy-rs/embassy/issues/4226#issuecomment-2908772500 --- docs/pages/layer_by_layer.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/pages') diff --git a/docs/pages/layer_by_layer.adoc b/docs/pages/layer_by_layer.adoc index 7dba11b5e..0692ee4fa 100644 --- a/docs/pages/layer_by_layer.adoc +++ b/docs/pages/layer_by_layer.adoc @@ -8,7 +8,7 @@ The application we'll write is a simple 'push button, blink led' application, wh == PAC version -The PAC is the lowest API for accessing peripherals and registers, if you don't count reading/writing directly to memory addresses. It provides distinct types to make accessing peripheral registers easier, but it does not prevent you from writing unsafe code. +The PAC is the lowest API for accessing peripherals and registers, if you don't count reading/writing directly to memory addresses. It provides distinct types to make accessing peripheral registers easier, but it does little to prevent you from configuring or coordinating those registers incorrectly. Writing an application using the PAC directly is therefore not recommended, but if the functionality you want to use is not exposed in the upper layers, that's what you need to use. -- cgit From 69abc42077e6de4453d422330a9a07407a36f218 Mon Sep 17 00:00:00 2001 From: 9names <60134748+9names@users.noreply.github.com> Date: Sun, 1 Jun 2025 00:08:09 +1000 Subject: doc: add high-level embassy-boot a-b info --- docs/pages/bootloader.adoc | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'docs/pages') diff --git a/docs/pages/bootloader.adoc b/docs/pages/bootloader.adoc index 53f85d995..b0f0331aa 100644 --- a/docs/pages/bootloader.adoc +++ b/docs/pages/bootloader.adoc @@ -2,6 +2,13 @@ `embassy-boot` a lightweight bootloader supporting firmware application upgrades in a power-fail-safe way, with trial boots and rollbacks. +The update method used is referred to as an A/B partition update scheme. + +With a general-purpose OS, A/B partition update is accomplished by directly booting either the A or B partition depending on the update state. +To accomplish the same goal in a way that is portable across all microcontrollers, `embassy-boot` swaps data page by page (in both directions) between the DFU and the Active partition when a firmware update is triggered. + +Because the original Active application is moved into the DFU partition during this update, the operation can be reversed if the update is interrupted or the new firmware does not flag that it booted successfully. + +See the design section for more details on how this is implemented. + The bootloader can be used either as a library or be flashed directly if you are happy with the default configuration and capabilities. By design, the bootloader does not provide any network capabilities. Networking capabilities for fetching new firmware can be provided by the user application, using the bootloader as a library for updating the firmware, or by using the bootloader as a library and adding this capability yourself. -- cgit From 5da6e31a3e4a1175ddf34e1ebdf83a8d685ea521 Mon Sep 17 00:00:00 2001 From: Dániel Buga Date: Tue, 24 Jun 2025 16:19:33 +0200 Subject: Correct esp-hal link --- docs/pages/overview.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/pages') diff --git a/docs/pages/overview.adoc b/docs/pages/overview.adoc index acd757795..18eaaeb75 100644 --- a/docs/pages/overview.adoc +++ b/docs/pages/overview.adoc @@ -30,7 +30,7 @@ The Embassy project maintains HALs for select hardware, but you can still use HA * link:https://docs.embassy.dev/embassy-nrf/[embassy-nrf], for the Nordic Semiconductor nRF52, nRF53, nRF91 series. * link:https://docs.embassy.dev/embassy-rp/[embassy-rp], for the Raspberry Pi RP2040 as well as RP235x microcontroller. * link:https://docs.embassy.dev/embassy-mspm0/[embassy-mspm0], for the Texas Instruments MSPM0 microcontrollers. -* link:https://github.com/esp-rs[esp-rs], for the Espressif Systems ESP32 series of chips. +* link:https://github.com/esp-rs/esp-hal[esp-hal], for the Espressif Systems ESP32 series of chips. * link:https://github.com/ch32-rs/ch32-hal[ch32-hal], for the WCH 32-bit RISC-V(CH32V) series of chips. * link:https://github.com/AlexCharlton/mpfs-hal[mpfs-hal], for the Microchip PolarFire SoC. * link:https://github.com/py32-rs/py32-hal[py32-hal], for the Puya Semiconductor PY32 series of chips. -- cgit From 8d2657383e29c78bd6b4a4dd7c2977ee970c636d Mon Sep 17 00:00:00 2001 From: Dániel Buga Date: Wed, 2 Jul 2025 10:33:16 +0200 Subject: Link to esp-generate --- docs/pages/new_project.adoc | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs/pages') diff --git a/docs/pages/new_project.adoc b/docs/pages/new_project.adoc index cd943b4f6..906d89f36 100644 --- a/docs/pages/new_project.adoc +++ b/docs/pages/new_project.adoc @@ -11,6 +11,8 @@ Once you’ve successfully xref:#_getting_started[run some example projects], th - link:https://github.com/lulf/embassy-template[embassy-template] (STM32, NRF, and RP) - link:https://github.com/bentwire/embassy-rp2040-template[embassy-rp2040-template] (RP) +=== esp-generate +- link:https://github.com/esp-rs/esp-generate[esp-generate] (ESP32 using esp-hal) == Starting a project from scratch -- cgit From 794477eca3062471a2cdc378730b5c2952cfd2c3 Mon Sep 17 00:00:00 2001 From: Rob Wells Date: Mon, 11 Aug 2025 19:56:31 +0100 Subject: book: Suggest Picotool for RP chips instead of elf2uf2-rs --- docs/pages/faq.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs/pages') diff --git a/docs/pages/faq.adoc b/docs/pages/faq.adoc index b21be9a30..8098e12ac 100644 --- a/docs/pages/faq.adoc +++ b/docs/pages/faq.adoc @@ -6,16 +6,16 @@ Please feel free to add items to link:https://github.com/embassy-rs/embassy/edit == How to deploy to RP2040 or RP235x without a debugging probe. -Install link:https://github.com/JoNil/elf2uf2-rs[elf2uf2-rs] for converting the generated elf binary into a uf2 file. +Install link:https://github.com/raspberrypi/pico-sdk-tools/releases[Picotool] for uploading the binary. Configure the runner to use this tool, add this to `.cargo/config.toml`: [source,toml] ---- [target.'cfg(all(target_arch = "arm", target_os = "none"))'] -runner = "elf2uf2-rs --deploy --serial --verbose" +runner = "picotool load --update --verify --execute -t elf" ---- -The command-line parameters `--deploy` will detect your device and upload the binary, `--serial` starts a serial connection. See the documentation for more info. +Picotool will detect your device and upload the binary, skipping identical flash sectors (the `--update` command-line flag), verify that the binary was written correctly (`--verify`), and then run your new code (`--execute`). Run `picotool help load` for more information. == Missing main macro @@ -209,7 +209,7 @@ MEMORY _stack_start = ORIGIN(RAM) + LENGTH(RAM); ``` -Please refer to the STM32 documentation for the specific values suitable for your board and setup. The STM32 Cube examples often contain a linker script `.ld` file. +Please refer to the STM32 documentation for the specific values suitable for your board and setup. The STM32 Cube examples often contain a linker script `.ld` file. Look for the `MEMORY` section and try to determine the FLASH and RAM sizes and section start. If you find a case where the memory.x is wrong, please report it on link:https://github.com/embassy-rs/stm32-data/issues/301[this Github issue] so other users are not caught by surprise. @@ -334,7 +334,7 @@ There are two main ways to handle concurrency in Embassy: In general, either of these approaches will work. The main differences of these approaches are: -When using **separate tasks**, each task needs its own RAM allocation, so there's a little overhead for each task, so one task that does three things will likely be a little bit smaller than three tasks that do one thing (not a lot, probably a couple dozen bytes). In contrast, with **multiple futures in one task**, you don't need multiple task allocations, and it will generally be easier to share data, or use borrowed resources, inside of a single task. +When using **separate tasks**, each task needs its own RAM allocation, so there's a little overhead for each task, so one task that does three things will likely be a little bit smaller than three tasks that do one thing (not a lot, probably a couple dozen bytes). In contrast, with **multiple futures in one task**, you don't need multiple task allocations, and it will generally be easier to share data, or use borrowed resources, inside of a single task. An example showcasing some methods for sharing things between tasks link:https://github.com/embassy-rs/embassy/blob/main/examples/rp/src/bin/sharing.rs[can be found here]. But when it comes to "waking" tasks, for example when a data transfer is complete or a button is pressed, it's faster to wake a dedicated task, because that task does not need to check which future is actually ready. `join` and `select` must check ALL of the futures they are managing to see which one (or which ones) are ready to do more work. This is because all Rust executors (like Embassy or Tokio) only have the ability to wake tasks, not specific futures. This means you will use slightly less CPU time juggling futures when using dedicated tasks. -- cgit From 8aec341f28a00012e1771d5c35d2647e11830755 Mon Sep 17 00:00:00 2001 From: Dario Nieuwenhuis Date: Wed, 9 Jul 2025 01:49:31 +0200 Subject: executor: return error when creating the spawntoken, not when spawning. --- docs/pages/sharing_peripherals.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/pages') diff --git a/docs/pages/sharing_peripherals.adoc b/docs/pages/sharing_peripherals.adoc index dfb8c1ffe..70b4210e6 100644 --- a/docs/pages/sharing_peripherals.adoc +++ b/docs/pages/sharing_peripherals.adoc @@ -36,8 +36,8 @@ async fn main(spawner: Spawner) { let dt = 100 * 1_000_000; let k = 1.003; - unwrap!(spawner.spawn(toggle_led(&LED, Duration::from_nanos(dt)))); - unwrap!(spawner.spawn(toggle_led(&LED, Duration::from_nanos((dt as f64 * k) as u64)))); + spawner.spawn(unwrap!(toggle_led(&LED, Duration::from_nanos(dt)))); + spawner.spawn(unwrap!(toggle_led(&LED, Duration::from_nanos((dt as f64 * k) as u64)))); } // A pool size of 2 means you can spawn two instances of this task. @@ -103,8 +103,8 @@ async fn main(spawner: Spawner) { let dt = 100 * 1_000_000; let k = 1.003; - unwrap!(spawner.spawn(toggle_led(CHANNEL.sender(), Duration::from_nanos(dt)))); - unwrap!(spawner.spawn(toggle_led(CHANNEL.sender(), Duration::from_nanos((dt as f64 * k) as u64)))); + spawner.spawn(unwrap!(toggle_led(CHANNEL.sender(), Duration::from_nanos(dt)))); + spawner.spawn(unwrap!(toggle_led(CHANNEL.sender(), Duration::from_nanos((dt as f64 * k) as u64)))); loop { match CHANNEL.receive().await { -- cgit From c101acbdc3593936f6e966cb33e8ba72698a1a31 Mon Sep 17 00:00:00 2001 From: Carl Kadie Date: Sat, 6 Sep 2025 14:05:45 -0700 Subject: Update Embassy in the Wild with no_std Raspberry Pi Pico clock demonstrating layered Embassy tasks (I also added a note that newer entries are at the top. If this isn't right, let me know or change.) --- docs/pages/embassy_in_the_wild.adoc | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'docs/pages') diff --git a/docs/pages/embassy_in_the_wild.adoc b/docs/pages/embassy_in_the_wild.adoc index 620794c31..cedbedada 100644 --- a/docs/pages/embassy_in_the_wild.adoc +++ b/docs/pages/embassy_in_the_wild.adoc @@ -2,6 +2,10 @@ Here are known examples of real-world projects which make use of Embassy. Feel free to link:https://github.com/embassy-rs/embassy/blob/main/docs/pages/embassy_in_the_wild.adoc[add more]! +_newer entries at the top_ + +* link:https://github.com/CarlKCarlK/clock[Embassy Clock: Layered, modular bare-metal clock with emulation] +** A `no_std` Raspberry Pi Pico clock demonstrating layered Embassy tasks (Display->Blinker->Clock) for clean separation of multiplexing, blinking, and UI logic. Features single-button HH:MM/MM:SS time-set UI, heapless data structures, and a Renode emulator for hardware-free testing. See link:https://medium.com/@carlmkadie/how-rust-embassy-shine-on-embedded-devices-part-2-aad1adfccf72[this article] for details. * link:https://github.com/1-rafael-1/simple-robot[A simple tracked robot based on Raspberry Pi Pico 2] ** A hobbyist project building a tracked robot with basic autonomous and manual drive mode. * link:https://github.com/1-rafael-1/pi-pico-alarmclock-rust[A Raspberry Pi Pico W Alarmclock] -- cgit