Real Time Operating Systems

1. Real Time Operating Systems Michael Thomas Date: Date Rev. 1.00

2. Objective • Identify embedded programming models • Understand basic RTOS definitions and concepts • Points to consider when you “Buy or roll your own”

3. Defining application requirements • Real time: Computing with a deadline • A required level of service has to be provided in a bounded response time • Consequence of missing deadlines: “Hardness” of the problem/application • Hard real-time - absolute deadlines must be met • Firm real-time - low occurrence of missing a deadline can be tolerated • Soft real-time - tolerance in the order of human reaction time (50ms)

4. Basic concepts and definitions • Task: Self contained code that handles a singular functionality or semi-independent portion of the application that handles a specific duty. • Threads: Access to entire memory space • Processes: Memory access area limited based on process creation parameters • Priority

5. Real-time Scheduling Soft Hard Static Dynamic Preemptive Non-preemptive Preemptive Non-preemptive Basic concepts and definitions • Scheduler • Implements the scheduling policy

6. Basic concepts and definitions • Determinism • Exact time taken for each thread to execute is a constant • Kernel • (Scheduler + Memory management + IPC + Synchronization) primitives • Kernel latency (microkernel, picokernel etc) • Kernel space

7. Program Counter Context Register Contents Task Status Priority Typical TCB Task ID Other Info Save context to TCB1 Save context to TCB2 Context switch time current CPU task Load context from TCB2 Load context from TCB1 Context Switch and Task Control Block

8. H8S Stack frames during a context switch task1 ready task2 ready task1 running Context Switch task2 running LOCAL VARIABLES LOCAL VARIABLES task1 task2

9. RUNNING WAITING ISR task 2 Context Switch task 1 Time Preemption • Clock Interrupts occur every ~10 ms (allow OS to run) • OS checks to see if any higher priority process available in ready queue • If so, suspend current process and switch to new process RTOS Context-Switch service Priority

10. Embedded programming models • System designed around task scheduling policy • Endless loop • Simple cyclic executive • Time driven cyclic • Multi-rate cyclic • Multi-rate cyclic for periodic tasks • Multi-rate cyclic with interrupts (bg/fg programming) • Priority based pre-emptive

11. Timer Interrupt Timer Interrupt Timer Interrupt Task1 Task1 Task1 Task1 Task2 Task2 Task2 Task2 Task1 Task1 Task3 Task3 Task3 Task3 Task4 Task4 Task1 Task1 Task5 Task5 Simple cyclic Time driven cyclic Multi-rate cyclic Multi-rate cyclic for periodic

12. Where does an RTOS fit in? • Task management viewpoint:

13. RTOS Services

14. Task Management & Scheduling • Task is considered as a scheduling unit which implements a function • OS services that collectively move tasks from one state to another • Provide context switching services • Task parameters like deadline, period, priority etc need to be specified

15. Task Management • Task states in a typical RTOS: • Dormant • Waiting • Ready • Running • Interrupted

16. Waiting for resources Resources available Interrupt ISR done task deleted Task resumed Task preempted Task Management • State transitions of a task in a typical RTOS

17. Scheduler and Scheduling Policy • Scheduling algorithms generate a feasible execution sequence based on • task priority • task deadlines • resource requirements • Round Robin • Earliest deadline First (EDF) • Maximum Urgency First (MUF) • Priority Ceiling Protocol (Resource based)

18. Interrupt Handling • RTOS Independent Interrupts • ISR preempts the RTOS and runs • Used for events that require accurate timing • RTOS Dependant Interrupts: • ISR is run within the RTOS • RTOS should allow lower level ISR to be pre-empted by higher level ISR (RTOS Dependant Interrupts) • ISR must complete as quickly as possible. • Both Dependant and Independent ISRs can exist in one system

19. Clocks and Timers • Tick timer • Decides granularity of system. • System response time limited by tick timer • Eg: 50 microsec motor control interrupt cannot be handled by a 1 millisec tick timer OS. • Timer primitives • Allow user to specify “Run task every x unit of time” during task creation. eg: scan keyboard

20. Synchronization • Synchronization primitive used to provide: • Mutual exclusion: Critical sections not accessed simultaneously • Conditional synchronization: Ensure tasks run in a specific order • Synchronization constructs: • Mutex (Binary semaphore) • Semaphore (Counting semaphore)

21. Synchronization and Semaphores • Two tasks and single buffer • Producer task and consumer task • Consumer task to wait till producer task is done with buffer. • Synchronization and data integrity achieved by using a semaphore to lock access to buffer. • Issues: • Deadlocks • Priority Inversion: Low priority thread obtains a lock that blocks a higher priority thread

22. Ready to run Running Priority Inversion High priority task H Preemption after resource X released Medium priority task M preemption X Low priority task L time Tasks L & H both need access to resource X Task L has locked this resource and hence delays H. Task M preempts L causing further delay to H; this is priority inversion

23. Inter Task Communication • Primary requirements/characteristics: • Non-blocking communication • Bounded latency • Asynchronous communication • Shared Memory • Mailbox/Message Queues

24. Task 1 Task 3 Task 2 Mailbox/Message Queue Mailbox 1

25. Memory Management • Memory Management Unit (MMU) • Handles Virtual memory operations. • Memory protection esp. in process based OS • Dynamic memory allocation • Heap; non-fragmenting memory allocation techniques • “Pool” allocation mechanism

26. 31 62 127 255 511 Buffer size Free buffer list Dynamic Memory allocation: RTOS heap

27. RTOS classification based on architecture • Soft, Firm and Hard real-time • Pre-emptive, Non pre-emptive • Thread based, Process based • Scheduling policy: RM, EDF, RR, MUF etc • Dynamic, Static • Cost structure

28. RTOS aware debugging • Standard source level debugging not sufficient in multithreaded/multitasking environment. • Potential bugs: • Data corruption due to improper synchronization • Deadlock • Starvation • Stack Overflow • Memory leaks • RTOS-aware debuggers provide tools that help detect such conditions for quicker debugging. • Extra windows showing state of all tasks (running, waiting etc), including buffers currently used by each task, semaphores used etc.

29. Buy vs Roll your Own • Factors: • Cost Structure. • Support and documentation • Scalability • Portability • Debugging tools • Testing

30. Buy vs Roll your Own • Cost Structure. • Royalty per product/ one time payment • Overall development, debugging, testing and support resources for in-house tool usually far outweigh investing in a commercial RTOS • Support and documentation • Insufficient documentation • Small team responsible for R&D and maintenance • Commercial RTOSes are well documented with good support

31. Buy vs Roll your Own • Scalability • In-house tools are usually designed to meet exact specifications so it might be a good fit • Commercial vendors allow significant customization of the kernel (in some cases a GUI for this purpose), so the notion of too much overhead code is unfounded • Some commercial vendors also provide source code to allay engineer fears of “I cant see the code so I don’t know what’s going on”

32. Buy vs Roll your Own • Portability • Porting an in-house solution to different hardware will require significant re-investment of time and resources • Commercial vendors have ports for all major hardware targets and will usually port to others as well • Debugging tools • Debugging tools have to be developed/ported for in house RTOS; usually takes 4x time needed to develop the RTOS • Commercial vendors have readily available debuggers and will port over desired features in most cases

33. Buy vs Roll your Own • Testing • In-house testing; takes 10x development time to properly test RTOS • Commercial RTOSes are sufficiently tested and have also been used by many customers so most bugs will have been ironed out.

34. Objectives: Recap • Identify embedded programming models • Understand basic RTOS definitions and concepts • Points to consider when you “Buy or roll your own”