On Arduinos, it's actually "for (;;)", which surprised me.

https://github.com/arduino/ArduinoCore-avr/blob/master/cores...

Unlikely, they talk about 50hz and 10hz tasks. Real time OS often allow you to create threads that run at a given rate and must comolete. Like the 50hz task would have 20ms to complete.

Very likely:

  while(true) {
    ...[50hz tick tasks]
    if(tick%5==0) {
    ...[10hz tick tasks]
    }
    
    wait_for_next_tick();
    tick++;
  }

`wait_for_next_tick();` in any microcontroller-based embedded system will put the CPU to sleep, often lowering your overall power consumption from the mA range it uses while actively running, to the uA range.

Some systems, like those based on coin cells, will completely shut down the chip, leaving only a single timer or input active, and when triggered will turn back on and initialise the entire CPU again to handle the input/timer. Some microcontrollers give you a small allocation of you can preserve under these conditions. That's how you get year+ runtimes on tiny batteries.

Edit: if you want to nerd out on this, I would start with Jack Ganssle's excellent guide: http://www.ganssle.com/reports/ultra-low-power-design.html

If they are rolling their own os or are using microcontrollers sure, but if they are using a safety critical rtos like vxworks or integrity then it has rate monotonic scheduling built in using os threads.

Nope, more likely there are internal CPU timers which emits hardware interrupts on which the tasks are performed

No, he is correct. Alot of embedded software uses a more complex form of that exact technique that he is shown in the code.

You technically can have a dedicated timer interrupt for every task but there are usually alot more tasks than HW timers, so instead they use a dedicated HW timer for time-keeping and use that as reference for all other tasks.

Exactly. IF there is operating system used (it's not always needed), programmers implement separate OS tasks. For simpler systems (like just reading some sensors) real time os is not needed, then such loops are implemented as a template (with much more error checking and restarting). Typically that "wait for tick" function just waits until hardware timer sets overflow flag (not even full interrupt), and this is done to have simple, easy to reason about system.

I guess I should also say at the bottom of those while loops there’s always some wait function attached to a timer