Programming Microcontroller RTX - Real Time Operating System - RTOS Autumn term 2012

1. Programming Microcontroller RTX - Real Time Operating System - RTOS Autumn term 2012 RTX - RTOS

2. Tasks of the Operating System (1/3) RTOS - RTX • Key tasks of the OS (Kernel) • Additional general tasks (OS) • External general tasks (Utilities) • Image processing

3. Tasks of the OS (2/3) RTOS - RTX • Kernel • Resource Management • Attribution of CPU time • Task-, Process- or (Thread-) management • Memory Management • Peripheral Devices • Time of the Day and Date

4. Tasks of the OS (3/3) RTOS - RTX • Additional general tasks (OS) • I/O management (Driver) • File management • Interrupt treatments • Processing "Power-up", "Power-down", "Shut-up", "Shut-down"… • Troubleshooting • External general tasks (Utilities) • Image processing

5. RTOS: Basic themes RTOS - RTX • Real time • Multitasking res. multiprogramming • Scheduling • Tasks, Threads and Processes

6. Real Time (RT) computer RTOS - RTX • RT computer works synchronously to the rhythm of the technical process • It responds on time to its needs • It takes measures on times

7. Multitasking res. multiprogramming RTOS - RTX • Multitasking OS allows the programming with temporally independent parallel units • Simulation of mutually independent, quasi-parallel operating processors • Example

8. Multitasking res. multiprogramming RTOS - RTX • Multiple tasks can run simultaneously on one computer • A task can be started before the other tasks have been completed • Example: Windows7

9. Tasks, threads and processes RTOS - RTX • A task is a ideal program unit with a time response • The code for a specific task is defined once • Many task can be generated and started from this definition • Tasks can run concurrently • Task can be started while another is still working • Depending on the OS, Task are always known and existing • They can be started or terminated • They can communicate with each other • Quasi-parallelism is realized by switching from one to another task

10. The task states are managed with FIFO Each task state contains its own FIFO State of a task RTOS - RTX

11. Description of the task states RTOS - RTX • Not-Existing • Does not exist in OS, which contain only active tasks • Running • Task, which is currently executed by the CPU • Ready-To-Run • All the conditions, which are needed to run the task are, are realized • CPU is currently occupied with the execution of another task • Blocked • Task is waiting because of synchronization tools • Semaphore, Event-flags, Suspend/Resume etc.

12. Scheduling RTOS - RTX • Scheduling is the process, which attributes CPU time to the threads, processes or task • Non preemptive Scheduling • Task exchanges are only realized at given points • Task must systematically give back CPU time • Preemptive scheduling • Preemptive means interruption • Task can loose CPU time at any point during its execution • Can be realized only with “Interrupt-Response-Program” • Clock tics

13. Round Robin Scheduling RTOS - RTX • Each task becomes a certain number of CPU time quanta • Task will be stopped, if it is not finished after this amount of time • If the task is finished before, it will be interrupted immediately • The active task are managed with a list • When the task A is interrupted, it will be put at the end of the list

14. Priority Scheduling RTOS - RTX • All the task have the same priority • All the task have predefined priorities • The priority for each task must be unique • Several tasks can have the same priority • Os Algorithm manage their precedence (Round Robin) • The priority is set explicitly or implicitly at task start and will be changed explicitly later • The priority remains the same during all the existence of the task (static) • Priority are changed dynamically by the scheduler

15. Definition and starting of a task within Keil RTOS - RTX • Definition of the task code • __task void task_name (void) { /* Initialization of the task resources */ … while(1) { /* Execution of the task algorithms */ … } } • Create and start the task • int main (void) { … /* 2 variants to create and start the task */ os_tsk_create (task_name, prio); os_tsk_create_user (task_name, prio, \ task_stack, sizeof(task_stack)); … }

16. Classical problems of the parallel data processing RTOS - RTX • Introduction example : Digital Voltmeter (DVM) • A/D conversion time: 75 ms • LCD must be “refreshed” after 50 ms • The multitasking enables to enhance the design and the program speed • Solution for the screen flickering

17. Code example • Problem of this solution • “Acquisition” and “Display” tasks can access to the data simultaneously • Sometimes wrong values will be displayed • Program must guaranty the mutual exclusion

18. Mutual Exclusion (MUTEX) RTOS - RTX • 2 train must bypass trough a critical section (Tunnel) • Only one train is authorized to go through the tunnel at the given moment • Both locomotive drivers are blind and deaf • The can only deposit or retire a stone in a bowl

19. First solution RTOS - RTX • Procedure for the locomotive conductors • #define EMPTY 0 #define OCCUPIED 1 int bowl; // semaphore while (bowl == OCCUPIED) { /*make Siesta*/ } //search a stone bowl = OCCUPIED ; // drive the train through the critical tunnel bowl = EMPTY ;

20. Frage zur ersten Lösung • Is this procedure really sure? • No, because the exclusion is not enough sure (danger of collision)

21. // Cover the bowl, wait if already covered *1) while (bowl == NOT_EMPTY) {}; // Search a stone bowl = NOTEMPTY ; // Uncover the bowl // Drive the train through the critical tunnel bowl = EMPTY ; // *2) // continue the non critical part of the journey Comments *1) Wait if the cover is already on the bowl *2) Access possible, even with covered bowl Is this procedure really sure? Yes, because it fulfills the mutual exclusion Solution with a privileged section

22. SEMAPHORE • Flag, which can be accessed only within privileged section • Dijkstra 1968 • Coordination using privileged actions • *1) init-value defines the number of trains allowed in the critical part • Value = 1 → binary semaphore • Value > 1 → general semaphore

23. Definition of the privileged functions proberen try verhogen increment Privileged function P(int * s) & V(int * s)

24. #define n 1 // for a binary semaphore #define n > 1 // for a general semaphore int s = n; probeeren (&s); // go though critical region verhogen (&s); // go though rest of job Using of the privileged functions within tasks

25. The waiting loop of probeeren occupies the CPU almost by 100% while (s == 0) { /* nothing */ } Solution Task which calls the waiting process must be put in a waiting list Problem of the waiting loop of probeeren

26. Procedure wait(int* s)

27. Procedure signal (int *s)

28. Definition of the semaphore variable selon Dijkstra • Definition of the semaphore variable • ints >= 0 • Rules for the semaphore variable • Binary semaphore: s = {0, 1} • General semaphore: 0 <= s <= n • Each semaphore variable contains its own waiting list • Writing into and reading from is realized in privileged mode • wait(int*s) & signal(int*s)are privileged functions

29. signal and wait functions of Keil RTOS - RTX • Semaphore functions of Keil • void os_sem_init (OS_ID semaphore, U16 token_count); • OS_RESULT os_sem_send (OS_ID semaphore); • OS_RESULT os_sem_wait (OS_ID semaphore, U16 timeout); • Telegram functions of Keil • void os_mbx_init (OS_ID mailbox, U16 mbx_size); • OS_RESULT os_mbx_send (OS_ID mailbox, void *message_ptr, U16 timeout); • OS_RESULT os_mbx_wait (OS_ID mailbox, void **message, U16 timeout);

30. Keil code for the locomotiv conductors RTOS - RTX

31. Keil code for parallel data processing RTOS - RTX