ONE Problem confuse us

Embassy executor

Features

• No alloc, no heap needed. Task are statically allocated.

• No "fixed capacity" data structures, executor works with 1 or 1000 tasks without needing config/tuning.

• Integrated timer queue: sleeping is easy, just do Timer::after_secs(1).await;.

• No busy-loop polling: CPU sleeps when there’s no work to do, using interrupts or WFE/SEV.

• Efficient polling: a wake will only poll the woken task, not all of them.

• Fair: a task can’t monopolize CPU time even if it’s constantly being woken. All other tasks get a chance to run before a given task gets polled for the second time.

• Creating multiple executor instances is supported, to run tasks at different priority levels. This allows higher-priority tasks to preempt lower-priority tasks.

The Rust’s macro grammar used in embassy

About time interrupt of timer

I am curious about the startup and interrupt

GitHub - rust-embedded/cortex-m: Low level access to Cortex-M processors

Low level access to Cortex-M processors. Contribute to rust-embedded/cortex-m development by creating an account on GitHub.

https://github.com/rust-embedded/cortex-m?tab=readme-ov-file

This repository contains various crates useful for writing Rust programs on Cortex-M microcontrollers:

• cortex-m: CPU peripheral access and intrinsics

• cortex-m-rt: Startup code and interrupt handling

• cortex-m-semihosting: Support for semihosting debugging

• cortex-m-interrupt-number: Shared trait for interacting with peripheral access crates

• panic-itm: Panic handler that sends messages over the ITM/SWO output

• panic-semihosting: Panic handler that sends messages over semihosting

try to figure out the executor in embassy with stm32f401 example

The Execution Flow of Blinky

The critical implementation part

To Implement our TCB, We should now some grammar of lifetime

Things we need to know about rust grammar

Important things done in uC/OS

track the process of debug