Real-time programming and its strict time constraints change the way a developer thinks. Instead of using the typical state machine implementation, the application is partitioned into multiple tasks. One task satisfies a portion of the application, whereas another task has other responsibilities. For instance, in the Atmel | START example, there is one task that blinks the LEDs, one task that writes the time to an OLED screen, and several other tasks with different responsibilities. In a real-time system, these tasks run concurrently, and a portion of their code will be executed every time the scheduler allows them to. This is different from the typical linear application code where everything is evaluated sequentially and always in the same order.
If there are tasks that are more important than others and require faster response time, the RTOS can be configured to allow higher priority tasks to interrupt lower priority ones. This is called preemption.
For the application to run correctly, it is important to make sure that the tasks do not interrupt each other at times where it can cause harm. An example of this might be if a task reads the value of a shared resource before another task is finished doing computations on it. Then the read value might be wrong, which again might cause other problems. It is important to know how to use task communication to ensure mutual exclusion to prevent such errors. This is discussed in the Task Communication section.
The figures below outlines a simple program sequence for homebrewing and what a transition from linear programming to parallel or concurrent tasks would look like.
