Was euch im Artikel erwartet:<\/p>\n\n\n\n
- \n
- Entwicklung eingebetteter Systeme!<\/li>\n\n\n\n
- Asynchrone Programmierung!<\/li>\n\n\n\n
- Was ist eigentlich Nebenl\u00e4ufigkeit und Parallelit\u00e4t?<\/li>\n\n\n\n
- Den ein oder anderen „schwarzen“ Kommentar zu Vors\u00e4tzen und \u00c4nderungsbereitschaft!<\/li>\n\n\n\n
- und nat\u00fcrlich ganz viel zu Rust!<\/li>\n<\/ul>\n\n\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/janus.rs\/wp-content\/uploads\/2025\/01\/20241228_120637307_iOS.jpg?resize=225%2C300&ssl=1\")
<\/figure>\n<\/div><\/div>\n\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/janus.rs\/wp-content\/uploads\/2025\/01\/nucleo_and_bread_board.jpg?resize=225%2C300&ssl=1\")
<\/figure>\n<\/div><\/div>\n<\/div>\n\n\n\nIst Rust Lernen ein guter Vorsatz f\u00fcr 2025? Ja, aber es ist nur ein Vorsatz!
Taten sind mehr als Worte –> Zum Rust lernen hierhin<\/a>!<\/strong><\/p>\n\n\n\nDu liest noch? Super: Der Artikel gliedert sich wie folgt:<\/p>\n\n\n\n
- \n
- Die Projektidee<\/li>\n\n\n\n
- Eingebettete Programmierung mit Rust<\/li>\n\n\n\n
- Was ist asynchrone Programmierung?<\/li>\n\n\n\n
- Asynchrone eingebettete Programmierung mit Embassy<\/li>\n\n\n\n
- Fazit<\/li>\n<\/ul>\n\n\n\n
Die Projektidee<\/h2>\n\n\n\n
Mein letztes Projekt im Bereich Embedded liegt schon einige Jahre zur\u00fcck. Inzwischen hat man die M\u00f6glichkeit mittels KiCAD<\/a> eine Platine zu designen und dann f\u00fcr wenig Geld eine Produktion, z.B. bei multi-cb<\/a>, in Auftrag zu geben. Sowas l\u00e4sst mein Bastlerherz h\u00f6her schlagen. Das war aber nicht der einzige Grund, dieses Projekt zu starten.<\/p>\n\n\n\n
Bei einem Kundenprojekt habe ich einen Freelancer kennengelernt, der auch an eingebetteten Systemen gearbeitet hat und \u00fcber ihn habe ich Einblicke zum aktuellen Stand der eingebetteten C-Programmierung erhalten.<\/p>\n\n\n\n
Dazu kommt, dass ich seit einiger Zeit interessiert die Entwicklung von Embedded Rust beobachte. Insbesondere des Frameworks Embassy<\/a>, das auf dem Konzept der asynchronen Programmierung basiert. Falls man von asynchroner Programmierung geh\u00f6rt, dann am ehesten im Zusammenhang mit Web-Services anstatt mit bare-metal Entwicklung.<\/p>\n\n\n\n
Aber auch ohne Embassy bringt Rust einen tollen Mehrwert in die Welt der eingebetteten Programmierung: Zur \u00dcbersetzungszeit \u00fcberpr\u00fcft Rust die Hardwarekonfiguration. Cooler ist nat\u00fcrlich Asynchrone eingebettete Programmierung.<\/p>\n\n\n\n
Ja das ist anspruchsvoll aber Rust lernen willst du eigentlich nicht?
Dann lies stattdessen \u00fcber meine Erfahrungen bei der ACHEMA <\/a>und der Rust Nation UK 2024<\/a>!<\/strong><\/p>\n\n\n\nJetzt geht es auf Shopping-Tour<\/h3>\n\n\n\n
So kam es eine Woche vor den Feiertagen zu einer kleinen Einkaufstour bei Reichelt<\/a> (ein g\u00fcnstiger und beliebter Elektronikh\u00e4ndler in Deutschland). Ich wollte eine kleine Sensorplattform aufbauen, mit der ich Temperatur und Helligkeit messen und per UART an den PC schicken kann. Dazu Mein Einkauf:<\/p>\n\n\n\n
- \n
- STM32 NUCLEO-144<\/a> mit einem STM32F767ZI Chip<\/li>\n\n\n\n
- DS18B20<\/a> Programmable Resolution 1-Wire Digital Thermometer<\/li>\n\n\n\n
- BH1750FVI<\/a> – Digital 16bit Serial Output Type Ambient Light Sensor IC <\/li>\n\n\n\n
- Ein Breadboard Set<\/a> mit Power und einigen Kabeln<\/li>\n<\/ul>\n\n\n\n
Die Ziele der „Sensorplattform“ und den Status QUO findet ihr auf GitHub<\/a>.<\/p>\n\n\n\n
Nat\u00fcrlich hatte ich einiges vergessen. Zum Beispiel ein 4,7k Ohm Widerstand f\u00fcr den I2C Bus. Vielen Dank an meinen Vater, der flei\u00dfig und pflichtbewusst auf die Suche ging um meine alten Elektronik-Teile auszugraben, so dass ich sie nach den Festtagen mitnehmen konnte. Nun gut, zur\u00fcck zum Thema: Was ist eingebettete Programmierung und warum mit Rust? Das erfahrt ihr im n\u00e4chsten Abschnitt.<\/p>\n\n\n\n
Eingebettete<\/strong> Programmierung mit RUst<\/h2>\n\n\n\n
Im Grunde basiert eingebettete Programmierung darauf das man die Spannung von PINs steuert. Das Ganze ist nat\u00fcrlich viel komplizierter denn neben Pins gibt es weitere Hardware-Komponenten wie: Speicher, Busse, Timer. Es werden zum Beispiel Kommunikationsprotokolle wie I2C<\/a> eingesetzt, die mit Funktionen wie Direct-Memory-Access (DMA<\/a>) betrieben werden k\u00f6nnen. <\/p>\n\n\n\n
DMA erm\u00f6glicht kontinuierlichere Datenstr\u00f6me und h\u00f6herer Performance. Beispiel: Wird ein Sensor per I2C angesteuert, kann DMA daf\u00fcr sorgen, dass Messwerte ohne CPU-Eingriff in den Speicher wandern, w\u00e4hrend die CPU noch andere Aufgaben erledigt. Das ist besonders bei zeitkritischen Anwendungen vorteilhaft.<\/p>\n\n\n\n
Gl\u00fccklicherweise stellen die meisten Hardware Hersteller sogenannte SVD Dateien zur Verf\u00fcgung, die beschreiben im Detail die Register einer MCU, also die Speicheradresse zum Mapping, Registeradressen und Bitfelder. Diese Informationen wurden schon im C-Ecosystem f\u00fcr die automatische Generierung von low-level Code verwendet. Stichwort CMSIS-SVD<\/a>. F\u00fcr Rust ist das Kommandozeilen-Tool svd2rust <\/a>entstanden: Doch Rust, bzw. svd2rust, bietet noch mehr.<\/p>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/janus.rs\/wp-content\/uploads\/2025\/01\/good_errors_via_traits.png?resize=1024%2C303&ssl=1\")
<\/figure>\n\n\n\nIm Rust-Ecosystem bestehen neben den Hardware-Abstraction-Layers (HALs) auch Peripherie-Access-Crates (PACs). Letztere werden automatisch mittels svd2rust<\/a> generiert. PACs nutzen Rust Traits um bei der \u00dcbersetzung sicherzustellen, dass Peripherie mit Treiber und DMA in der richtigen Art und Weise verkn\u00fcpft wird.<\/p>\n\n\n\n
Im Bild oben sieht man z.B. eine Rust Compilermeldung, die ich erhalten habe als ich eine falsche Peripherie auf das serielle UART Protokoll mappen wollte. Der Hinweis zur L\u00f6sung ist gelb hervorgehoben. <\/p>\n\n\n\n
Setzt ihr auf C f\u00fcr eingebettete Systeme? Toll, andere haben einst aufs Pferd gesetzt!
„Ich setze aufs Pferd!“ – Kaiser Wilhelm II.<\/strong><\/p>\n\n\n\nDer Fehler war, dass ich PA1 statt PA9 als Peripherie ausgew\u00e4hlt habe. In C h\u00e4tte ich zur Laufzeit irgendwas beobachtet, oder wahrscheinlicher: Ich h\u00e4tte nichts beobachtet, und mich dann voller Verwunderung auf die Fehlersuche begeben. Danke Rust! <\/p>\n\n\n\n
Asynchrone eingebettete Programmierung also, aber was ist asynchrone Programmierung, \u00fcberhaupt?<\/p>\n\n\n\n
Was ist asynchrone Programmierung<\/h2>\n\n\n\n
Anstatt asynchrone Programmierung zu definieren, legen wir erst fest was synchrone Programmierung bedeutet. Und zwar, dass ein Funktionsaufruf blockiert – also der Funktionsaufruf wird abgeschlossen und dann wird der n\u00e4chste Funktionsaufruf ausgef\u00fchrt. Der Code unten l\u00e4uft von oben nach unten ab, also so wie er gelesen wird. Das ist so intuitiv, das diese Erkl\u00e4rung wohl eher verwirrt.<\/p>\n\n\n\n
Nehmen wir an Funktionen fragen Datenbanken ab, laden eine Datei herunter oder warten auf einen Sensorwert, der \u00fcber den I2C Bus gesendet wird. Die CPU hat nichts zutun, aber man wartet auf Speicher oder Kommunikation. In der Zeit w\u00e4re es sch\u00f6n die CPU-Zeit in eine andere Aufgabe zu stecken.<\/p>\n\n\n\n
fn main() -> Result<(), Box<dyn std::error::Error>> {\n let reval_a = my_func_a();\n let reval_b = my_func_b();\n printnln!(\"A={}, B={}\", reval_a, reval_b);\n}<\/code><\/pre>\n\n\n\nBei der asynchronen Programmierung st\u00f6\u00dft ein asynchroner Funktionsaufruf eine Aufgabe an, die zu einem gegebenen Zeitpunkt von einem Executor ausgef\u00fchrt wird. So kann es sein dass in dem Code unten die Funktion my_async_b zuerst berechnet wird. Wichtig ist: Im asynchronen Rust findet der Funktionsaufruf nur statt wenn das Ergebnis explizit angefragt wird.<\/p>\n\n\n\n
Im Code unten wird die asynchrone Laufzeit von Tokio<\/a> verwendet. Man sieht so etwas meistens im Zusammenhang mit Server\/Client Anwendungen. Durch den Aufruf der beiden Funktionen passiert erstmal nichts. Damit etwas passiert muss mittels await oder dem join! Makro das Future explizit angefragt werden (Das ist anders als in C++). F\u00fcr die eingebettete Programmierung, die meist nur einen Rechenkern verwendet, ist es sinnvoll den Unterschied zwischen Parallelen und Nebenl\u00e4ufigen Programmfluss zu erkl\u00e4ren.<\/p>\n\n\n\n
#[tokio::main]\nasync fn main() -> Result<(), Box<dyn std::error::Error>> {\n let future_a = my_async_func_a();\n let future_b = my_async_func_b();\n\n let (reval_a, reval_b) = join!(future_a, future_b);\n println!(\"A={}, B={}\", reval_a, reval_b);\n\n let reval_c = my_async_func_c().await;\n}<\/code><\/pre>\n\n\n\nNebenl\u00e4ufigkeit und Parallelit\u00e4t<\/h3>\n\n\n\n
Eine Asynchrone Runtime erzeugt eine nebenl\u00e4ufige Ausf\u00fchrung. Wichtig: Dies ist auch mit einem einzigen Thread oder einem einzigen Rechenkern m\u00f6glich. Insbesondere in eingebetteter Hardware wird h\u00e4ufig ein Chip mit nur einem Rechenkern verbaut. Dies ist auch der Fall f\u00fcr den STM32 Chip auf dem hier verwendeten NUCLEO-Board.<\/p>\n\n\n\n
Eine parallele Ausf\u00fchrung ist erst m\u00f6glich sobald mehr als einen Rechenkern verf\u00fcgbar ist. In dem Fall k\u00f6nnte ein Executor Funktion a und b gleichzeitig auf verschiedenen Kernen ausf\u00fchren. Im Falle eines Single-Cores verh\u00e4lt es sich wie in den Betriebssystemen in den 90igern. Das bedeutet ein Arbeiter wechselt die Aufgaben und weil CPUs und MCUs so schnell sind wirkt es auf uns gleichzeitig oder parallel. Dabei entspricht der Prozess-Scheduler eines Betriebssystems hier einer asynchronen Runtime, z.B. Tokio oder Embassy. Die Bearbeitung der Aufgaben\/Funktionen kann sich \u00fcberlappen, es ist aber weder Gleichzeitigkeit n\u00f6tig noch garantiert.<\/p>\n\n\n\n
Das typische Einsatzszenario f\u00fcr asynchrone Programmierung ist ein Webserver mit vielen Anfragen und langen Wartezeiten aufgrund von Ein und Ausgaben, wie das Auslesen einer Datenbank oder der Zugriff auf eine Datei auf einem anderen Server.<\/p>\n\n\n\n
Jedoch wird genau dieses Prinzip von Embassy f\u00fcr eingebettete Systeme genutzt, um z. B. mehrere Sensoren und Kommunikationsaufgaben zeitgleich zu organisieren, ohne einen echten Betriebssystem-Scheduler zu ben\u00f6tigen. Wir erhalten also einige Features eines Echtzeit-Betriebssystem (RTOS). <\/p>\n\n\n\n
Das ist asynchrone eingebettete Programmierung. Danke Embassy!<\/p>\n\n\n\n
Mit Rust durchstarten? Wir unterst\u00fctzen euch gerne! Vereinbart ein unverbindliches Erstgespr\u00e4ch<\/a>.
Oder gebt uns unverbindlich ein Mittagessen<\/a> aus!<\/strong><\/p>\n\n\n\n\n\nSynchrone Programmierung<\/h3>\n\n\n\n
- \n
- Funktion kehrt erst nach Abschluss der Berechnung zur\u00fcck<\/li>\n\n\n\n
- R\u00fcckgabewert ist tats\u00e4chlicher R\u00fcckgabe<\/li>\n\n\n\n
- Reihenfolge der Aufrufe wohldefiniert<\/li>\n\n\n\n
- Programmfluss ist deutlich einfacher nachzuvollziehen<\/li>\n<\/ul>\n<\/div>\n\n\n\n\n
Asynchrone Programmierung<\/h3>\n\n\n\n
- \n
- Funktion kehrt sofort zur\u00fcck<\/li>\n\n\n\n
- R\u00fcckgabewert ist „In Arbeit“ oder „Erledigt“, der tats\u00e4chliche R\u00fcckgabewert ist nur im Zustand „Erledigt“ abrufbar.<\/li>\n\n\n\n
- Funktion b k\u00f6nnte ihre Berechnung vor Funktion a abschlie\u00dfen<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n
Asynchrone eingebettete Programmierung mit Embassy<\/h2>\n\n\n\n
Anders als Tokio ist Embassy auf bare-metal Hardware ausgelegt. Anstatt klassischer Threads, die vom Betriebssystem verwaltet werden, greift Embassy auf eine eigene Scheduler Implementierung zur\u00fcck, die auf Hardware Interrupts oder nutzerspezifischen Synchronisierungen, wie Timer oder Signale, reagiert um aufzuwachen. Dies bietet eine hervorragende Grundlage um Energie zu sparen, denn dank dieser Konzepte ist klar wann die CPU in den Sleep geschickt werden darf und sollte.<\/p>\n\n\n\n
Weitere wichtige Konzepte sind die Tasks, die dem Scheduler \u00fcbergeben werden. Tasks sind letztendlich asynchrone Rust Funktionen. Synchronisationsprimitiven wie Signale, Channels und Mutexes, erm\u00f6glichen es Tasks Daten auszutauschen. Damit erh\u00e4lt man Features wie in einem RTOS (Echtzeit-Betriebssystem) aber mit einem deutlich geringeren Footprint. <\/p>\n\n\n\n
Im Gegensatz zu einem klassischen RTOS wie FreeRTOS oder Zephyr nutzt Embassy rein Rust-eigene Konzepte wie async\/await, Channels, Signals und Timer. Nat\u00fcrlich gibt es Anwendungsf\u00e4lle bei denen man nicht um ein RTOS herumkommt, da das kooperative Scheduling auch mit einer High-Priority Variante immer erst auf einen Task-Abschluss warten muss, so dass absolut harte Echtzeit-Anforderungen im ms Bereich gegebenfalls nicht gehalten werden k\u00f6nnen.<\/p>\n\n\n\n
Nun gut, aber wie nutzt man Embassy?<\/p>\n\n\n\n
Aufsetzen der Peripherie, Interrupts und Tasks<\/h3>\n\n\n\n
Embassy Nutzer k\u00f6nnen in der Main Funktion Tasks „spawnen“ und diese werden standardm\u00e4\u00dfig kooperativ in einem Scheduler ausgef\u00fchrt. F\u00fcr Echtzeitkritische Module ist der Einsatz eines weiteren High-Priority Schedulers m\u00f6glich.<\/p>\n\n\n\n
Aber lasst uns das Code-Snippet unten untersuchen. Die Main Funktion wird wie bei Tokio, nur diesmal mit #[embassy_executor::main], annotiert. Zuerst wird eine Representation der STM32 Peripherie mit einem init Aufruf erzeugt. Dann verkettet das Makro
bind_interrupts!<\/code> unsere Peripherie (USART, I2C) mit den entsprechenden Interrupt-Routinen von Embassy. <\/p>\n\n\n\nBei usart handelt es sich um einen Treiber f\u00fcr die serielle Kommunikation mit einem Computer. Im Falle des NUCLEO Boards wird hierf\u00fcr die USB-Verbindung verwendet. Mit der Funktion split k\u00f6nnen Empf\u00e4nger und Transmitter an unterschiedliche Tasks \u00fcbergeben werden. Falls mehr als ein Task senden oder Transmitten soll ist die Sicherstellung der Synchronisierung, z.B. mittels Mutex, n\u00f6tig. Anderenfalls wird der Rust-Compiler eine Fehlermeldung ausgeben.<\/p>\n\n\n\n
Wir konzentrieren uns in diesem Artikel Ausschnitte f\u00fcr mehr Details schaut euch den kompletten Code in GitHub <\/a>an. Der Task uart_status_report_transmitter verwendet den uarts Transmitter tx um Status-Reports zu senden. Der zweite Task uart_receiver_and_cmd_forwarder wird eingesetzt um Nachrichten von einem Rechner zu empfangen. Bisher haben wir die Channel und Signale im Code ignoriert. Dabei sind diese, neben Timer, unsere Werkzeuge um Nebenl\u00e4ufigkeit zu verwenden, <\/p>\n\n\n\n
#[embassy_executor::main]\nasync fn main(spawner: Spawner) {\n let p = embassy_stm32::init(Default::default());\n \/\/...\n \/\/ bind interrupts\n bind_interrupts!(struct Irqs {\n USART3 => embassy_stm32::usart::InterruptHandler<embassy_stm32::peripherals::USART3>;\n I2C1_EV => embassy_stm32::i2c::EventInterruptHandler<embassy_stm32::peripherals::I2C1>;\n I2C1_ER => embassy_stm32::i2c::ErrorInterruptHandler<embassy_stm32::peripherals::I2C1>;\n });\n let mut usart = setup_usart_developer_console!(p, Irqs, UsartConfig::default());\n \/\/ ...\n \/\/ spawn a task for uart sending and receiving each\n let (tx, rx) = usart.split();\n spawner.spawn(uart_receiver_and_cmd_forwarder(rx, CHANNEL_COMMANDS.sender())).unwrap();\n spawner.spawn(uart_status_report_transmitter(tx)).unwrap();\n \/\/ ...\n spawner.spawn(process_light_sensor(\n &LIGHT_SENSOR_SIGNAL,\n i2c\n )).unwrap();\n \/\/ ...\n loop {\n button.wait_for_rising_edge().await;\n CHANNEL_COMMANDS.sender().send(Commands::LightSensor(LightSensorCommands::SingleMeasurment)).await;\n Timer::after(Duration::from_millis(50)).await;\n }\n}<\/code><\/pre>\n\n\n\nBisher wissen wir nur wie Tasks aufgesetzt werden, der Vorteil Asynchrone eingebettete Programmierung spielt sich jedoch durch die Interaktion der Tasks aus.<\/p>\n\n\n\n
Interaktion zwischen Tasks<\/h3>\n\n\n\n
Mit der Hilfe von Channels und anderen Synchronisationsmechanismen, wie Signal, ist eine Event-artige Kommunikation zwischen den Tasks m\u00f6glich. Weiterhin ist das Teilen von Daten, die mittels eines Mutexes synchronisiert werden, m\u00f6glich.<\/p>\n\n\n\n
Im Code-Block oben sind die Variablen CHANNEL_COMMANDS und LIGHT_SENSOR_SIGNAL f\u00fcr die Abgabe des Kontrollflusses und somit die Steuerung des Schedulers und der Kommunikation zwischen Tasks zust\u00e4ndig.<\/p>\n\n\n\n
So werden Kommandos von dem uart Empf\u00e4nger Task uart_receiver_and_command_forwarder an einem Task zur Verarbeitung von Kommandos weitergeleitet (nicht im Ausschnitt zu sehen). Es ist m\u00f6glich mehrere Sender zu verwenden, wie unten in der Schleife, die pr\u00fcft ob der User-Button bet\u00e4tigt wurde. Wenn das der Fall ist wird erst der Kommando Prozessor informiert, der dann ein LIGHT_SENSOR_SIGNAL ausl\u00f6st um einen einzelnen Sensorwert zu ermitteln. <\/p>\n\n\n\n
- DS18B20<\/a> Programmable Resolution 1-Wire Digital Thermometer<\/li>\n\n\n\n
- STM32 NUCLEO-144<\/a> mit einem STM32F767ZI Chip<\/li>\n\n\n\n