1 / 39

Chapter 5 Real-Time Operating Systems

Chapter 5 Real-Time Operating Systems. Objectives Multitasking scheduling Inter-task communication RTX51-Tiny RTOS programming Benefits of using RTOS. 5.1 Overview. The RTOS provides an abstraction layer between the hardware and application software.

jessica-jarvis
Download Presentation

Chapter 5 Real-Time Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 5Real-Time Operating Systems Objectives • Multitasking scheduling • Inter-task communication • RTX51-Tiny RTOS programming • Benefits of using RTOS

  2. 5.1 Overview • The RTOS provides an abstraction layer between the hardware and application software. • They are often called akernel or executiveprocess, not a full-blown Operating System.

  3. Tasks • Application software is split up into multitasking blocks called ‘Tasks’. • Tasks are generic computational blocks with • Timing constraints • Synchronization and communication relationships with other tasks • Generally each device is represented by its own task.

  4. Contd. • Tasks can be in one of four states • SLEEPING • READY • RUNNING • BLOCKED

  5. Contd. • Ways to move between tasks: • SLEEPING -> READY through an RTOS system function called from a different task. • READY -> RUNNING from being selected for execution by the RTOS. There can only be one RUNNING task at a time. • RUNNING -> READY if its time-slice runs out or if a higher priority task is ready to run. • BLOCKED -> READY after the event a task has been waiting for occurs. • RUNNING -> BLOCKED when the task is told to wait for an event to occur. • BLOCKED -> RUNNING after the event a task has been waiting for occurs and has higher priority than current RUNNING task. • RUNNING -> SLEEPING once task has finished execution.

  6. Task scheduling • RTOS decides which task to run using a scheduler, based on a system clock. • RTOS system clock ‘ticks’ based on hardware timer overflow, generally Timer 0. • At each clock tick: • Processor executes RTOS program • RTOS updates tables that track task state, interval count, timeout count, etc. • RTOS decides which task should get to execute

  7. 5.2 RTX51-Tiny • RTX51 is a commercial RTOS from Keil, available in Full or Tiny version. • RTX51-Tiny comes with the PK51 Professional Developer’s Kit. • RTX51-Tiny features: • Only 900 bytes of code space required • Requires one hardware timer, Timer 0 • Supports round-robin and cooperative task scheduling • Supports intertask signaling

  8. Contd. • RTX51-Full supports extra features: • Preemptive task scheduling • Task priorities • Task interrupts • Messaging routines • Semaphores • Memory allocation routines

  9. Task declaration #include <rtx51tny.h> int counter1; void task0 (void) _task_ 0 { // RTX51 begins task 0 counter1 = 0; // initialize counter os_create_task (1); // make task 1 ready os_delete_task (0); // stop task 0 (init is // completed). } void task1 (void) _task_ 1 { while (1) { // infinite loop counter1++; // increment counter 1 } }

  10. Contd.

  11. Contd. • Task declaration is similar to C function declaration with a ‘_task_’ attribute. • Each task must be assigned a number from 0-255 in Full or 0-15 in Tiny. • Tasks do not return or take any parameters except void. • RTX51-Tiny always starts execution at task number 0. • RTX51-Full must start the RTOS from main()

  12. 5.3 Task Scheduling • RTX51 supports preemptive, round-robin, and cooperative task scheduling algorithm. • RTX51 scheduler chooses the task to run by: • The highest priority of all tasks that are READY • The task that has been waiting for the longest time if all tasks have the same priority • RTOS only switches tasks if the first rule is violated, except in round-robin scheduling

  13. 5.3.1 Round-Robin Multitasking • Default scheduling method for RTX51-Tiny • Every task is run in turn for an equal length of time called the time-slice • Time-slice is defined during compile, based off number of ticks of the system clock

  14. Round-Robin example #include <rtx51tny.h> int counter0; int counter1; int counter2; void job0 (void) _task_ 0 { // RTX51 begins in task0 counter0 = 0; // initialize counters counter1 = 0; counter2 = 0; os_create_task (1); // start task 1 os_create_task(2); // start task 2 while (1) { // infinite loop counter0++; // increment counter 0 } }

  15. Contd. void job1 (void) _task_ 1 { while (1) { // infinite loop counter1++; // increment counter1 } } void job2 (void) _task_ 2 { while (1) { // infinite loop counter2++; // increment counter2 } }

  16. Right after RTOS initialization All 3 tasks are created and READY to run

  17. Contd. • When there is only one task, the RTOS always chooses job0 to run after its time-slice. • When all three tasks are READY to run, job1 runs after job0, and job2 runs after job1. • The time-slice is defined in ‘Conf_tny.A51’. ; Define Hardware-Timer tick time in 8051 machine cycles INT_CLOCK EQU 10000 ; default is 10000 cycles ; ; Define Round-Robin Timeout in Hardware-Timer ticks. Default is 5 Hardware- ; Timer ticks. 0 disables Round-Robin Task Switching TIMESHARING EQU 5

  18. 5.3.2 Cooperative Multitasking • Configure RTX51 to schedule in cooperative mode by setting the TIMESHARING variable in ‘Conf_tny.A51’ to 0. TIMESHARING EQU 0 • Tasks switches are only performed when the running task voluntarily gives up control of the processor.

  19. Code example #include <rtx51tny.h> int counter0; int counter1; void job0 (void) _task_ 0 { // RTX51 begins in task 0 os_create (1); // make task 1 READY while (1) { // infinite loop // increment counter if (++counter0 == 0) { // signal task 1 os_send_signal (1); // wait for signal; releases // CPU control os_wait (K_SIG, 0, 0); }

  20. Contd. os_wait (K_TMO, 1, 0); // wait for 1 tick // give up CPU } } void job1 (void) _task_ 1 { while (1) { // infinite loop os_wait (K_SIG, 0, 0); // wait for signal // give up CPU // increment counter 1 counter1++; os_send_signal (0); // signal task 0 } }

  21. Contd. • Task 0 gives up control of processor at ‘os_wait’, where it waits for an event to occur. • Before doing so, task 0 signals task 1 making it READY to execute. • Tasks have to manually control execution order using communication methods like signals.

  22. 5.3.3 Priority-Driven Preemptive Multitasking • Requires task priorities that are not available in RTX51-Tiny. • Tasks can be assigned a priority from 0-3, with 0 being the lowest priority. 0 is also the default priority for RTX51-Tiny tasks. • Declare task priority by adding a ‘_priority_’ parameter. void job1 (void) _task_ 1 _priority_ 1 {

  23. Contd. • Preemption is necessary sometimes to meet task deadlines. • Preemptive scheduler can switch tasks before the time-slice for the RUNNING task runs out

  24. Preemption example #include <rtx51tny.h> int counter0; int counter1; void job0 (void) _task_ 0 _priority_ 0 {// RTX51 starts off in task 0 os_create (1); // start task 1 while (1) { // infinite loop // increment counter 0 if (++counter0 == 0) // signal task 1 os_send_signal (1);

  25. Contd. os_wait (K_TMO, 1, 0); // wait for 1 tick } } void job1 (void) _task_ 1 _priority_ 1 { while (1) { // infinite loop os_wait (K_SIG, 0, 0); // wait for signal // increment counter 1 counter1++; } }

  26. (a) While task1 is blocked (b) When task1 preempts task0 (c) While task1 is active (d) When task1 waits for signal

  27. 5.4 RTOS Events • Events can be used by tasks to communicate between each other or to help coordinate execution flow • Four common RTOS events: • Signals • Messages • Semaphores • Interrupts

  28. 5.4.1 Signal Event Based Communication • Signaling is the fastest method of communication. • No actual information is exchanged, a signal is simply a single-bit flag. • It is important for coordinating execution flow amongst tasks. • Only one signal can be saved per task, and any extra signals are ignored.

  29. Contd. void task1 (void) _task_ 1 { ... os_send_signal(2); // signal task 2 os_clear_signal (1); // clear task 1 flag os_wait (K_SIG, 0, 0); // wait for signal ... } • Tasks can send and clear signal for any other task, including itself. • Tasks waiting for signal are BLOCKED. The RTOS unblocks that task once the event is received.

  30. 5.4.2 Message Event Based Communication • Messaging is only available in RTX51-Full. • A message is a set of data that gets transferred through message queues or mailboxes. • Messages in RTX51 are 16-bit data values or a pointer to data buffer. • RTX51 has eight mailboxes that are not tied to any single task, numbered 0-7.

  31. Contd. • Tasks send messages or are BLOCKED until the message can be sent or timeout occurs. int message; ... // send data in variable ‘message’ to mailbox 2; // timeout after 10 ticks os_send_message (2, message, 10); • Tasks can wait for messaging event and store the message to variable. // wait for message in mailbox 3 and store // in &message; or timeout in 10 ticks os_wait (K_MBX + K_TMO + 3, 10, &message);

  32. 5.4.3 Semaphores • Semaphores are only available for RTX51-Full. • Semaphores help prevent resource sharing conflicts between tasks. • RTX51 has eight binary semaphores, numbered 8-15. // wait for token from semaphore 14 os_wait (K_MBX + 14, 0, 0); // protected task functions ... // finished with semaphore, return token os_send_token (14);

  33. 5.4.4 Task Interrupts • RTX51-Full supports attaching hardware interrupt vectors to tasks. • Each interrupt source can only be assigned to one task. • Multiple interrupts can be assigned to a single task. • Attaching an interrupt does not automatically set the corresponding interrupt enable flag. In fact, the relevant flags are only enabled when tasks begin to wait for an interrupt event.

  34. Contd. void task1 (void) _task_ 1 { // attach interrupt 14 (Timer 3 overflow) os_attach_interrupt (14); while (1) { // wait for interrupt os_wait (K_INT, 0, 0); ... } }

  35. 5.5 When to use RTOS • Large projects benefit from using an RTOS • Standardized system functions (task switching, task communication, etc.) makes coding easier • Tasks makes large systems more modular and easier to debug • Generally when a system has a dozen or more tasks that all have timing constraints

  36. Contd. • Ultra-compact systems may be better off without using an RTOS • Small systems are easier to code from scratch and can incorporate processor optimizations, making the system more efficient than one using RTOS • A full-featured RTOS may not fit within the size limits of an ultra-compact system.

  37. Summary • RTOS standardizes system functions and makes coding real-time systems easier • Three predominant scheduling methods are: preemptive, round-robin, and cooperative • Intertask communication can be done through signals or messages • Large systems benefit from RTOS, while compact systems can be more efficient if it is custom-written

More Related