Async Rust vs. C RTOS: Ein Embedded-Showdown

Das ist bei sehr geringer CPU-Last. Ein Async-Ansatz ohne Preemption kann also funktionieren. Wenn nennenswerte Berechnungen anstehen, funktioniert er nicht so gut.

Eine nützliche Zahl, die man auf einem Oszilloskop messen sollte, ist die Interrupt-Latenz im schlechtesten Fall. Das ist entscheidend, 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, der Interrupt wird ausgelöst, wenn Interrupts nicht verhindert werden, die Aufgabe startet, die Aufgabe schaltet einen Ausgangspin ein. Man beobachtet die Verzögerung von Eingang zu Ausgang auf dem 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 solche Aufgabe 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 dem 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 rechenintensiv sind.

Das ist der Unterschied zwischen Echtzeit- und "Beinahe-Echtzeit"-Scheduling.