[tlamponi]

They do help, hard realtime only means that there can be no blocking (critical) section with a possible unbound time limit, toggling an IO register with a lower frequency as the CPu clock can still be done while shovelling in datagrams into the RF stack that can DMA acces in withput any CPu doings anyway..

[kingosticks]

i agree it can be done but it's a fragile balancing act. What I don't agree with is that Rust provides anything particularly special allowing you to do this.

[tlamponi]

> but it's a fragile balancing act.

It only is if its done that way.. Normally you use a small RTOS that provides some sane abstractions to handle such mix of tasks or you can add some code that does that, for simpler applications (where simple does not mean uncritical or not hard RT) that can work fine too, and especially a single core can make things easier to argue about.

> What I don't agree with is that Rust provides anything particularly special allowing you to do this.

Well, compared to what? While there are already some languages (like nesC) or "frameworks" (OS) that do something like that they are well, frameworks and not a language or tied to a specific "runtime (environment)" like nesC is to tinyOS.

Rust itself provides protection against data races, which already helps a lot for making it less fragile, as you call it, and it also provides type-based (thus zero runtime cost) access control and design contract functionality, check:

https://docs.rust-embedded.org/book/static-guarantees/index....

Compared to plain C, ASM or C++ this is something special that rust provides in helping to do that.

Look, I do not argue that two cores do not help to have to separate domains for different level of critical, but quite often you do not require that, I mean I did some hard RT applications with FFT + a PID controller running or some fixed point physic calculations going on plus an user interface + GLCD output and communications (e.g., wifi, zigbee and/or UART) on a very basic 16 MHZ or sometimes (for bigger stuff) 32 MHz AVR chip.

Compared to that AVR chip, which could already handle a lot of not-so-simple hard RT apps here, the ESP C3 RISC-V CPU has:

* 160 MHz – so 5 to 10 times more, and a 4-stage pipeline compared to 3 on the AVR IIRC

* 15 levels of interrupt priority one can configure (the AVR only had a fixed level and the ISR basically had to turn of interrupts completely.

* a general DMA engine that can handle 108 to 128 MB/s so way less work for the CPU to shovel data towards UART, I2C, SPI, the crypto engines or the WiFi Bluetooth stacks.

With all that you got most of the more frequent interrupts stuff gone even while sending lots of stuff over the ether and the CPU can handle the actual app.