Embassy - un framework embarqué moderne basé sur Rust et async

• Framework de nouvelle génération conçu pour développer rapidement des applications embarquées sûres et efficaces
• Assure la sécurité mémoire et des threads à la compilation sans runtime ni garbage collector, et permet le multitâche sans RTOS
• Prend en charge divers microcontrôleurs avec des fonctions clés comme le HAL, le réseau, le Bluetooth, l’USB et le bootloader
• Conçu pour la basse consommation avec un executor à priorités, en prenant en compte à la fois le traitement temps réel et l’autonomie sur batterie
• S’impose comme la plateforme de référence du développement embarqué asynchrone associée à l’écosystème Rust

---

Présentation d’Embassy

• Embassy est un framework de nouvelle génération permettant d’écrire des applications embarquées de manière sûre et efficace grâce à Rust et aux fonctionnalités async
  • Fonctionne sans runtime, garbage collector ni système d’exploitation
  • Garantit la sécurité mémoire et des threads à la compilation

Architecture basée sur Rust + async

• Grâce à la fonctionnalité async/await de Rust, Embassy met en œuvre un multitâche efficace dans les environnements embarqués
  • Les tâches sont transformées à la compilation en machines à états (state machines) et exécutées de façon coopérative
  • Aucune allocation mémoire dynamique nécessaire, exécution sur une pile unique
  • Permet d’obtenir un code plus rapide et plus compact sans changement de contexte d’un RTOS
• Les documents liés mentionnent une supériorité de performances par rapport à un RTOS

Composants principaux (Batteries Included)

• Couche d’abstraction matérielle (HAL)
  • Contrôle des fonctions matérielles via une API Rust sûre
  • Principales cibles prises en charge : STM32, nRF, RP2040, MSPM0, ESP32, CH32, PolarFire SoC, PY32
• Gestion du temps (embassy-time)
  • Fournit des types Instant, Duration, Timer utilisables globalement, sans débordement
• Prise en charge du temps réel et de la basse consommation
  • Possibilité de créer plusieurs executors pour une exécution des tâches basée sur les priorités
  • En veille, le cœur passe automatiquement en mode économie d’énergie, avec réveil basé sur les interruptions
• Réseau (embassy-net)
  • Prend en charge Ethernet, IP, TCP, UDP, ICMP, DHCP
  • La structure asynchrone simplifie la gestion des timeouts et le traitement de multiples connexions
• Bluetooth
  • Prend en charge divers stacks BLE comme trouble, nrf-softdevice, embassy-stm32-wpan
• LoRa, USB, Bootloader
  • Prise en charge du stack LoRaWAN avec lora-rs
  • embassy-usb implémente les classes USB CDC et HID
  • embassy-boot prend en charge des mises à jour de firmware sûres même en cas de coupure d’alimentation

Spécifications techniques et licence

• Version minimale de Rust prise en charge (MSRV) : 1.75 ou supérieure
• Licence : au choix entre Apache-2.0 et MIT
• Le nom du projet est l’abréviation de « EMBedded ASYnc »

[GN⁺]

Avis Hacker News

• Je suis un grand fan du projet Embassy. C’est un exemple parfait de pourquoi l’async Rust est formidable
  Ça fonctionne sans heap, et les abstractions à faible coût permettent l’exécution concurrente même sur des puces monocœur. Sans la complexité d’un RTOS
  C’est vraiment impressionnant de voir l’équipe Embassy grandir à ce point.
  Je recommande aussi reqwless, le client HTTP pour Embassy-net. Il prend même en charge HTTPS
  Avant, je ne pensais pas que Rust embedded était meilleur que le C/C++, mais maintenant je juge mes achats de MCU selon la prise en charge de Rust

  • Je me demande quel kit de développement MCU vous recommanderiez pour tester ça
  • J’aime beaucoup le fait que cela apporte de la sûreté de typage aux HAL. C’est une sorte de couche de protection pour les gens qui débutent dans ce domaine
    Cela dit, je ne comprends toujours pas très bien ce qu’est un watchdog

• Ce que j’apprécie le plus dans Embassy, c’est la couche de motifs applicatifs
  Des tâches de périphérique à longue durée de vie y masquent le timing et la coordination derrière de petites API async
  Par exemple, dans du code comme loop { let btn = ir.wait_for_press().await; }, le compilateur construit automatiquement la machine à états
  Je pense que ce style est un produit naturel de l’async + no-std
  J’aimerais qu’on parle davantage de cette structure applicative que des HAL ou de l’executor
  J’aborde aussi ces idées dans un article gratuit, écrit avec Brad Gibson
  J’ai aussi ouvert le dépôt device-kit, qui sert à expérimenter et documenter ce type de motifs. J’aimerais connaître d’autres dépôts qui tentent quelque chose de similaire

  • C’est utile non seulement pour la logique haut niveau, mais aussi pour le firmware bas niveau
    À l’époque où j’écrivais du firmware de NIC sous forme de machines à états, j’aurais vraiment aimé avoir quelque chose comme l’async de Rust
    On peut imiter les coroutines en C, mais c’est beaucoup trop bricolé (hacky)
    À l’époque, on croyait que les threads d’un RTOS coûtaient cher, mais avec le recul ce n’était peut-être pas forcément vrai
    Même pour le traitement de protocoles comme le 802.11, l’async aurait rendu le code bien plus petit et simple

• J’aime vraiment Embassy
  Je viens du C bare metal et de FreeRTOS, et j’ai enfin l’impression que l’embarqué dispose d’une toolchain moderne
  L’écosystème autour est particulièrement excellent — intégration probe-rs + cargo run, logs defmt, embedded_hal, stm32-rs, etc.
  J’ai aussi essayé RTIC, mais je suis resté sur Embassy à cause de l’ergonomie de la syntaxe async
  J’ai été surpris de voir que ça compile et s’exécute directement sous macOS. Avant, il fallait toujours Linux, mais maintenant c’est possible directement sur une puce M
  Il m’a fallu un peu de temps pour comprendre le concept de partage d’accès aux périphériques, mais comme les règles de verrouillage sont imposées à la compilation, il y a très peu de bugs
  La qualité des piles USB et réseau est aussi très élevée. J’utilise PLDM over USB et une pile TCP sur Ethernet, et tout fonctionne parfaitement
  Le point faible, c’est qu’il est difficile d’intégrer des gens habitués aux exemples fournis par les vendors, et si le vendor ne connaît pas Rust, le débogage collaboratif devient compliqué
  Malgré ça, je le recommande fortement dans l’écosystème STM

  • Quand j’ai compilé Embassy il y a quelque temps, j’ai été surpris de voir plus de 100 dépendances être tirées. Pour du hobby c’est bien, mais pour l’industrie, je pense qu’il y a encore du chemin
  • Je me demandais s’il prenait aussi en charge le multicœur comme l’ESP32, et apparemment c’est possible avec un second executor et embassy_sync pour communiquer

• Embassy et l’async Rust sont la plus grande innovation qu’ait connue le monde de l’embarqué ces dix dernières années
  Les RTOS en C sont de bonnes idées sur le principe, mais pénibles à utiliser en pratique. Un framework léger comme Embassy est une évolution naturelle
  Embassy peut en fait presque être vu comme un OS temps réel. Pour plus de détails, voir cet article

• Je suis en train de réécrire Glicol en no-std, et la combinaison embassy-rs + 2350 est excellente
  Si vous comptez vous mettre au développement embarqué en 2026, je recommande vivement cette stack

• C’est un peu hors sujet, mais je me demande par quoi il vaut mieux commencer quand on débute en développement embarqué
  Après plus de 10 ans uniquement en développement web, je suis en train d’étudier le livre sur Rust. J’ai commandé un Raspberry Pi, mais peut-on vraiment considérer ça comme de l’embarqué ?

  • Je recommanderais plutôt une carte ST Nucleo qu’un Raspberry Pi. Elle intègre un programmateur SWD, donc le flashage et le débogage sont faciles
    Un modèle comme la NUCLEO-F767ZI, avec port USB, est un bon choix
  • J’ai acheté une ESP32-C6 Touch LCD pour 25 $, et c’est presque comme une Fitbit sans bracelet
    Il y a le Wi‑Fi, le BLE, un capteur 6 axes, et les démos C se lancent immédiatement. LVGL est aussi excellent
    Je n’ai pas encore essayé Rust dessus, mais comme c’est basé sur RISC-V, c’est intéressant. Elecrow et Makerfabs sont aussi bien pour les débutants
  • Je conseillerais d’acheter une carte avec un RP2040 et un kit de démarrage en composants électroniques, puis de se mettre directement au code
    En Rust, rp-hal est bien pour débuter, et Embassy peut venir un peu plus tard
  • Le Raspberry Pi permet aussi de manipuler les GPIO, donc c’est bien pour acquérir des réflexes d’embarqué
    Si vous voulez aller vers quelque chose de plus bare metal, je recommanderais une carte ESP32. Ce n’est pas cher, et il existe de nombreux formats avec chargeur de batterie ou écran intégré

• J’ai créé un relais LoRa avec Embassy pour l’utiliser avec l’app Bitchat (basée sur nrf52)
  Dans l’ensemble, ça fonctionne de façon très fluide, et les paniques venaient du côté Nordic SoftDevice

  • Bitchat n’est pas basé sur le BLE ? Je me demande si tu as implémenté directement le protocole LoRa, ou si tu fais un pont vers quelque chose comme Meshtastic

• J’étais en train de construire avec Embassy un contrôleur de pédale pour ampli guitare à modélisation Spark
  Il contrôle l’ampli en BLE, et j’ai trouvé intéressant que la pile BLE Rust soit totalement open source
  Cela dit, c’est encore à un stade précoce, donc l’API change souvent et il fallait figer une révision git dans Cargo
  Malgré ça, l’avenir du projet semble prometteur

• Microsoft utilise aussi Embassy pour des EC (Embedded Controller)
  Voir Open Device Partnership pour plus de détails

• Ariel OS est un système d’exploitation construit au-dessus d’Embassy. Ça vaut le détour

  • Indépendant d’Embassy, mais si vous cherchez du multitâche préemptif, Xous mérite aussi un coup d’œil

[pmnxis]

J’ai déjà mené avec embassy-rs le développement d’un produit jusqu’à sa mise en production sur un STM32G030C8T6, et à l’usage il y a tout de même quelques inconvénients.
Quand on doit accéder à des HAL peu répandus, il faut finalement recourir à l’approche qu’on utilisait avec le framework RTIC.
À cause de l’async, il y a un risque important d’inefficacité mémoire, donc il faut être vigilant.
Pour développer dans un environnement avec 32 KB ou moins de mémoire flash, c’est très contraignant. (log + symboles de debug, etc.)
Quand on veut développer en dehors de l’écosystème NRF/STM/ESP/RP, cela devient en pratique très difficile.
Découvrir le Rust embarqué avec embassy-rs est une bonne chose, mais si l’on vise ensuite la production en série ou une progression de carrière, il me semble préférable de se familiariser davantage avec RTIC.
D’un autre côté, je crains que son accessibilité, au point d’en faire une sorte d’Arduino avancé pour Rust, ne finisse paradoxalement par poser problème lorsqu’on veut faire du développement plus complexe.