Embedded Rust RTOS vs. C RTOS

That's under very light CPU load. So an async approach, with no preemption, can work. If there's any significant compute going on, it won't work as well.

A useful number to measure on a scope is worst case interrupt latency. This is what matters if there's a hard real-time constraint. They measured standard deviation, but not worst case. The usual test setup is that an input signal (typically a square wave) goes to an input pin, interrupt happens if interrupts not prevented, task starts, task turns on an output pin. You watch input to output delay on a scope and look for outliers.

If you're running entirely run to completion, the outliers are determined by the longest compute task. This is a problem if there's a compute task.

This is historically where QNX shines. Interrupt is processed and schedules a thread. About all that happens at interrupt level is thread activation. The thread turns on the output pin. You can look on a scope for scheduling outliers. The best case latency is higher than doing the work at interrupt level, but the worst case latency is constant, even if lower priority threads are compute bound.

This is the difference between real time and "near real time" scheduling.

Title should be changed. Async Rust != RTOS. RTOS's are preemptively multithreaded while async is done cooperatively with yield points.

Perhaps "Embedded async Rust vs. C RTOS"

(2022)

> In the web world async/await has already won from threads

Slightly off topic but threads were never supported by the web (even now you only have message passing between workers) so it's a bit hollow to say async won.

Those damn compilers are going to take our jobs!!!