Embedded Rust RTOS vs. C RTOS

kkooi about 4 hours ago 19 commentsRead Article on tweedegolf.nl

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

60% Positive

Analyzed from 687 words in the discussion.

Discussion (19 Comments)Read Original on HackerNews

Animats•about 2 hours ago

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.

topspin•about 1 hour ago

> The best case latency is higher than doing the work at interrupt level

One approach is to do everything in ISRs, a la RTIC. That requires efficient, vectored, nested, tail-chained, base priority-ed interrupt silicon, and a lot of it, but it is feasible and elegant where this exists, such as Cortex NVIC. Emerging RISC-V devices with xCLIC (ch32v, gd32v, newer ESP32 and others) are potentially even better.

I really appreciate that the author took the time to add the Embassy vs RTIC addendum.

monocasa•7 minutes ago

FWIW, just having a mask in the interrupt controller is normally enough to give you the same thing at the cost of a dozen or so cycles in the critical path. Basically you just keep a mask per priority that can be built up cheaply at init time (or even compile time if you're cute about it), you apply the appropriate mask in the interrupt prologues and epilogues, and pretty much as soon as you apply the new mask in the prologue you go ahead and acknowledge the interrupt.

yuriks•about 2 hours ago

Embassy can (these days, not sure if this is more recent than the article) do preemption, but it works by setting up multiple task pools and executors for each priority level: https://docs.embassy.dev/embassy-executor/git/cortex-m/struc... Non-realtime compute heavy tasks can be processed in the background executor and interrupted by latency sensitive ones.

AnyTimeTraveler•about 2 hours ago

In my experience, it is pretty rare to run much actual work on a microcontroller. Testing at effectively idle represents most of my usecases.

For the times where there is a background load: RTIC has task priorities and pre-emption, so you can run your compute-intensive task with a lower priority and react to interrupts in a timely manner.

a-dub•41 minutes ago

> You watch input to output delay on a scope and look for outliers.

better to acquire these or use timestamped gpio and compute real statistics- but for the sake of illustrative metaphor, sure.

wiremine•about 2 hours ago

Agreed. I really like Embassy, and the write up is a fun read. But, this isn't what "real" embedded software looks like.

kjs3•about 2 hours ago

When your goal is to show your pet language is 'better', you pick the benchmarks that 'prove' it.

inamberclad•about 2 hours ago

No, this is really the whole point of an RTOS. It can preempt low priority tasks to respond to critical events.

kjs3•about 1 hour ago

I'm quite clear on what the point of an RTOS is, thank you. But I wasn't addressing that, which is the point you seem to have missed.

joshchngs•5 minutes ago

This article is almost 5 years old now, which makes it fairly ancient in Embedded Rust terms. I think the general landscape hasn't changed all that much, but I'd be cautious of relying on any details from it.

CupricTea•about 1 hour ago

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"

bArray•about 1 hour ago

The title in the article is literally "Async Rust vs RTOS showdown!" and the article shows "Embassy/Rust against FreeRTOS/C". There should also be a (2022) appended.

You just need to read the Reddit comments to see why this is not a useful comparison [1] [2].

[1] https://www.reddit.com/r/rust/comments/sik3g0/async_rust_vs_...

[2] https://www.reddit.com/r/embedded/comments/she3u9/async_rust...

odo1242•about 1 hour ago

The article itself seems to have the right title: Async Rust vs RTOS showdown!

The title on HN should probably be updated to that

fla•42 minutes ago

Technically RTOS’s can also be cooperatively multithreaded, to some degree at least (see FreeRTOS). The comparison is valid IMO as threading with fixed yield points is an abstraction that isn’t exclusive to async Rust.

aw1621107•about 2 hours ago

(2022)

rakel_rakel•about 1 hour ago

ha! I was happily surprised to see this article posted because it felt like it was picking up where the technical discourse was before LLM's took over.

2022 explains that perfectly, albeit leaves me less happy.

vatsachak•about 2 hours ago

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

IshKebab•about 1 hour ago

> 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.