[tlamponi]

And ESP's rust support provides threads and async supprot nonetheless.

With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.

[bri3d]

The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations.

This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.

[tlamponi]

They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.

[kingosticks]

"low-latency processing of IO input" may well be talking about hard realtime stuff, for which threads/async on a single core doesn't help you.

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