I've been pondering the designs of these kinds of OS for embedded use, and wanted to ask a few questions.

I believe these systems generally rely on preemptive schedulers to allocate time to distinct 'tasks' is this always the case? what about an RTOS that claims to be a "real time" RTOS that guarantees certain time constraints, how do they achieve that?

 

From what I have learned so far with FreeRTOS on ESP32...

Tasks can be set up to run on certain input events, timers, and internal triggers or run at specific interrupts. How "real time" it actually is will depend on if it is run from an interrupt and the priority of the interrupt.

 

The hard real time schedulability problem has no general solution. You analyze a specific case, make a specific solution and do worst-case analysis and testing.

 

I wonder why the "scheduling" can't be abandoned, replaced by a pure state machine where code runs as and when relevant events occur.

 

The very best real time response will be achieved by not using an OS. Driving everything by interrupts.

But, in an environment where the events occur randomly, no response time can be guaranteed.

 

The very best real time response will be achieved by not using an OS. Driving everything by interrupts.

But, in an environment where the events occur randomly, no response time can be guaranteed.

Yes, that's what I was pondering, a large state machine where interrupts drive what happens next, everything is basically idle, only doing real CPU work when an interrupt(event) occurs.

 

I wonder why the "scheduling" can't be abandoned, replaced by a pure state machine where code runs as and when relevant events occur.

Because you then can't provide any timing guarantees, which pretty much rules it out as being classified as a real-time operating system.

 

I've been pondering the designs of these kinds of OS for embedded use, and wanted to ask a few questions.

I believe these systems generally rely on preemptive schedulers to allocate time to distinct 'tasks' is this always the case? what about an RTOS that claims to be a "real time" RTOS that guarantees certain time constraints, how do they achieve that?

On top of everything else, there are some sets of requirements that cannot be met with any available technology. Each system is a brand-new design problem unto itself. As has already been observed there are no general-purpose solutions that are guaranteed to work in all cases.

 

I wonder why the "scheduling" can't be abandoned, replaced by a pure state machine where code runs as and when relevant events occur.

Sure, you can replace classic "scheduling" with a hierarchical state machine. That's mainly what I write for small embedded systems without critical deadlines, usually with some task scheduling interrupt tasks in 'background'. RTOS and State-Machines are not mutually exclusive...

IMO the raw RTOS (something like FreeRTOS ) programming blocking "flowchart" model is outdated with modern embedded hardware and language usage. Blocking superloop threads with mutexes and semaphores are vestiges of a primitive CPU and I/O hardware. It's not that a good RTOS won't work as a improvement over sequential super-loop/interrupt systems, it's just that there are better methods today than the 80's concept of pseudo-concurrent uniprocessor programming at the controller level that's mainly event-driven by I/O registers and dataflow. You can use a raw RTOS to implement event-driven state machine frameworks that don't use the default blocking model. The main con is initial programming complexity with languages like C but it doesn't take long to generate mental pattern and templates if you have software 'engineering' experience.

The absolute lowest latencies and response times are driven by concurrent hardware that only sends events to the processing CPU that changes main processing program 'state' when the critical hardware module sequence is done.
https://www.embedded.com/programming-embedded-systems-the-easy-way-with-state-machines/
https://forum.allaboutcircuits.com/threads/whats-reason-to-choose-an-rtos.178559/post-1623760

https://barrgroup.com/blog/introduction-hierarchical-state-machines
https://www.state-machine.com/