-4

I am beginner and I am little bit confused about the difference between a task in RTOS and state machines. let's take an example of state machine I am willing to implement: 

enum states{
  READY_STATE
  RUNNING_STATE
  BLOCKED_STATE
  FINISHED_STATE
}STATES;

What are the benefits of using RTOS and creating tasks if this state machine can be enumerated with events/interrupts without using any RTOS?

Pryda
  • 899
  • 5
  • 14
  • 37
  • How would a context switch occur between tasks on a state machine without something resembling a kernel? – rcgldr Mar 16 '18 at 09:37
  • I guess that would be based on events, something like `event = read_event();` followed by a switch loop – Pryda Mar 16 '18 at 09:42
  • You might also look at the difference between preemptive and cooperative multitasking. In the last one, a single task is run up to the point where it blocks and hands the control back to the scheduler (which would effectively be an eventloop) – Lanting Mar 16 '18 at 09:49
  • You are comparing chalk with cheese. They do not fulfil the same purpose, and are not mutually exclusive. It is common for an RTOS task to implement a state-machine - allowing many concurrent communicating state machines to exist. – Clifford Mar 16 '18 at 12:58
  • 2
    Umm.. the RTOS kernel IS a state-machine. It's inputs are hardware interrupts and system calls, it's outputs are a set of running threads. – Martin James Mar 16 '18 at 13:35
  • You can implement FSM on any pre-emptive RTOS, it will just run inside an RTOS task/process. For example, you can use this implementation https://gist.github.com/ankurs/355708 (note this one uses dynamic memory approach with free() and malloc() calls) – ecle Mar 19 '18 at 03:27

1 Answers1

2

RTOS is used to handle program complexity by placing unrelated tasks in different procedures, so that they can execute seemingly simultaneously. For example, it might make sense to split application logic, GUI and serial communication in 3 independent processes.

Whether this gives true multi-processing, or multi-processing simulation, depends on the number of CPU cores available. Traditionally, most RTOS are multi-processing simulation on single-core.

A state machine on the other hand, is a program design specification, which may or may not have the purpose of splitting up complexity. So it is not necessarily related to RTOS.

You can however design a "poor man's RTOS" as a manner of finite state machine, where you give each state a certain time slice and expect the state to be finished before it elapses (or the watchdog will bite). This can give the same real-time behavior as a RTOS, but there will only be one single stack and no "true" context switches.

Picking bare metal or RTOS depends a lot on the program complexity. Unless the original program design is state of the art (it rarely is), bare metal programs tend to become a pain when they grow up to somewhere between 50k-100k LOC. In these situations, picking a RTOS from the start would perhaps have been wiser.

On the other hand, if you don't think the program will ever grow that large, bare metal is so much easier to work with. RTOS introduces extra complexity, and extra complexity introduces bugs. The golden rule is to always keep software as simple as possible.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • 1
    Tasks need not be "unrelated" - if fact functional partitioning does not need an RTOS - a simple non-real-time, round-robin time-slicing or cooperative scheduler can do that. For real-time performance task partitioning is about schedulability and guaranteeing response times, so a "task" is determined by the length and determinism of its execution. Neither is it about "simulating" multiprocessing - multiprocessing and multitasking are distinct concepts. Again it is about scheduling rather than concurrency. – Clifford Mar 16 '18 at 13:06