Async Rust vs. C RTOS: Ein Embedded-Showdown
Embedded Rust RTOS vs. C RTOS
In diesem technischen Blogbeitrag vergleichen wir Embassy (async Rust) mit FreeRTOS (C) auf einem STM32F446-Mikrocontroller. Beide Implementierungen führen dieselben Aufgaben aus: LED blinken, Button-Interrupts verarbeiten und Nachrichten über eine Queue senden. Gemessen werden Interrupt-Latenz, Programmgröße, RAM-Nutzung und Programmierbarkeit. Der Autor erwartet, dass das RTOS bei Latenz und Speicher besser abschneidet, während Rust bei statischem Speicher und Komfort punkten könnte. Die Ergebnisse werden anhand von Oszilloskop-Messungen und Compiler-Reports präsentiert.
Ich bin voreingenommen, aber ich hoffe, dass dieser Blogbeitrag einen fairen Vergleich liefert.
- Animats
Das ist bei sehr geringer CPU-Last. Ein Async-Ansatz ohne Präemption kann also funktionieren. Wenn jedoch nennenswerte Berechnungen anstehen, funktioniert das nicht so gut.
Eine nützliche Zahl, die man auf einem Oszilloskop messen sollte, ist die Interrupt-Latenz im schlechtesten Fall. Darauf kommt es an, wenn es eine harte Echtzeitbedingung gibt. Sie haben die Standardabweichung gemessen, aber nicht den schlechtesten Fall. Der übliche Testaufbau ist: Ein Eingangssignal (typischerweise eine Rechteckwelle) geht an einen Eingangspin, ein Interrupt erfolgt, sofern Interrupts nicht verhindert werden, die Aufgabe startet, die Aufgabe schaltet einen Ausgangspin ein. Man beobachtet die Verzögerung von Eingang zu Ausgang auf einem Oszilloskop und sucht nach Ausreißern.
Wenn man vollständig run-to-completion arbeitet, werden die Ausreißer durch die längste Berechnungsaufgabe bestimmt. Das ist ein Problem, wenn es eine Berechnungsaufgabe gibt.
Historisch gesehen ist das der Punkt, an dem QNX glänzt. Der Interrupt wird verarbeitet und plant einen Thread. Auf Interrupt-Ebene passiert im Wesentlichen nur die Thread-Aktivierung. Der Thread schaltet den Ausgangspin ein. Man kann auf einem Oszilloskop nach Planungs-Ausreißern suchen. Die Latenz im besten Fall ist höher, als wenn man die Arbeit auf Interrupt-Ebene erledigt, aber die Latenz im schlechtesten Fall ist konstant, selbst wenn Threads mit niedrigerer Priorität rechengebunden sind.
Das ist der Unterschied zwischen Echtzeit- und "Beinahe-Echtzeit"-Scheduling.
- CupricTea
Der Titel sollte geändert werden. Async Rust ist nicht gleichbedeutend mit einem RTOS. RTOS sind präemptiv multithreaded, während async kooperativ mit Ausstiegspunkten arbeitet.
Vielleicht "Embedded async Rust vs. C RTOS".
- joshchngs
Dieser Artikel ist inzwischen fast 5 Jahre alt, was ihn in Embedded-Rust-Begriffen ziemlich alt macht. Ich denke, die allgemeine Landschaft hat sich nicht allzu sehr verändert, aber ich wäre vorsichtig, mich auf irgendwelche Details daraus zu verlassen.