4 ms·
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 use
by Animats 1mo 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.
- kjs3 1mo agoWhen your goal is to show your pet language is 'better', you pick the benchmarks that 'prove' it.
- inamberclad 1mo agoNo, this is really the whole point of an RTOS. It can preempt low priority tasks to respond to critical events.
- kjs3 1mo agoI'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.
- okanat 1mo agoTrue RTOS scheduling is equally possible on Rust. RTIC does it already.
- wiremine 1mo agoAgreed. I really like Embassy, and the write up is a fun read. But, this isn't what "real" embedded software looks like.
- mrheosuper 1mo agoI wanted to switch to Rust for new embedded project. I was looking for native RTOS, and embassy came up. But i always feel like it's hacky to me. What i want is RTOS that is similar to FreeRTOS or Zephyr.
- whytevuhuni 1mo agoWhy is that? What do those have that embassy does not (or vice-versa)?
- mrheosuper 1mo agoIt's not about features, i believe i am not that advance user. It's just different from the RTOS i used to work on. Most of exist C RTOS work quite similar(FreeRTOS, Zephyr, ThreadX), the difference is mostly in API and Software support arround the core kernel. But Embassy, with different task switching mechanism, mean i need to learn another new concept, understanding the pros/cons. That is not what i want to do when busy adapting to Rust.
- rcxdude 1mo agoIn my experience unless you're really at the edge you can basically just treat it like regular threads, and you'll probably run into fewer concurrency issues than you would with threads. Probably the bigger problem is just the rough edges in async rust, though they are getting filed down over time.
- yuriks 1mo agoEmbassy 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/struct.InterruptExecutor.html 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 1mo agoIn 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.
- topspin 1mo 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 1mo agoFWIW, 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.
- topspin 1mo agoI am aware. That "dozen or so" is a problem: when everything is an interrupt, there are no interrupts: it's just scheduling, and things that must be scheduled frequently can't suffer "a dozen or so" overhead. For the SRP model to really hum, you need the silicon that solves this.
- monocasa 1mo agoI've found that it doesn't matter except for something that you want at the absolute highest priority anyway, which then by definition doesn't need to jump through the same hoops because nothing can preempt it anyway.
- topspin 26d agoIt's more about frequency than priority. When something has to be serviced tens of thousands of times a second, "a dozen or so" becomes a problem. If you have the silicon that solves this, you can retain the model. If you don't then you have to resort to workarounds. Fortunately we typically have more efficient means to deal with such hardware, but not always, and it would be a shame to break the intended model when this is the case.
- a-dub 1mo 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.