SOC Consortium Course Material Real-time OS Speaker: 沈文中 April. 9, 2003 National Taiwan University Adopted from National Chiao- Tung University SOC Course Material

SOC Consortium Course Material Real-time OS 1 Outline  Introduction to RTOS  Introduction to μC/OS-II

SOC Consortium Course Material Real-time OS 2 Real Time OS  Real-time OS (RTOS) is an intermediate layer between hardware devices and software programming  “Real-time” means keeping deadlines, not speed  Advantages of RTOS in SoC design Shorter development time Less porting efforts Better reusability  Disadvantages More system resources needed Future development confined to the chosen RTOS

SOC Consortium Course Material Real-time OS 3 Soft and Hard Real Time  Soft real-time Tasks are performed by the system as fast as possible, but tasks don’t have to finish by specific times Priority scheduling Multimedia streaming  Hard real-time Tasks have to be performed correctly and on time Deadline scheduling Aircraft controller, Nuclear reactor controller

SOC Consortium Course Material Real-time OS 4 Outline  Introduction to RTOS  Introduction to μC/OS-II

SOC Consortium Course Material Real-time OS 5 μC/OS-II  Written by Jean J. Labrosse in ANSI C  A portable, ROMable, scalable, preemptive, real-time, multitasking kernel  Used in hundreds of products since its introduction in 1992  Certified by the FAA for use in commercial aircraft  Available in ARM Firmware Suite (AFS)  Over 90 ports for free download 

SOC Consortium Course Material Real-time OS 6 μC/OS-II Features  Portable 8-bit ~ 64 bit  ROMable small memory footprint  Scalable select features at compile time  Multitasking preemptive scheduling, up to 64 tasks

SOC Consortium Course Material Real-time OS 7  C/OS-II vs.  HAL  uHAL is shipped in ARM Firmware Suite  uHAL is a basic library that enables simple application to run on a variety of ARM-based development systems  uC/OS-II use uHAL to access ARM-based hardware uC/OS-II & User applicationAFS Utilities C, C++ libraries uHAL routines Development board AFS support routines

SOC Consortium Course Material Real-time OS 8 Kernel  Basic jobs of uC/OS-II kernel Task management Interrupt handling Inter-process communication

SOC Consortium Course Material Real-time OS 9 Kernel API  Service routines provided by uC/OS-II Kernel Task management APIs Time management APIs Memory management APIs Inter-process communication APIs Synchronization APIs  To make a System Call means to call Kernel API

SOC Consortium Course Material Real-time OS 10 Task  Task is an instance of program  Task thinks that it has the CPU all to itself  Task is assigned a unique priority  Task has its own set of stack  Task has its own set of CPU registers (backup in its stack)  Task is the basic unit for scheduling  Task status are stored in Task Control Block (TCB)

SOC Consortium Course Material Real-time OS 11 Task Structure Task structure:  An infinite loop  An self-delete function void ExampleTask(void *pdata) { for(;;) { /* User Code */ /* System Call */ /* User Code */ } Task with infinite loop structure void ExampleTask(void *pdata) { /* User Code */ OSTaskDel(PRIO_SELF); } Task that delete itself

SOC Consortium Course Material Real-time OS 12 Task States Waiting Dormant Ready Running ISR Task Create Task Delete Highest Priority Task Task is Preempted Task Pending EventsTask Gets Event Task Delete Interrupt Int. Exit Task Delete

SOC Consortium Course Material Real-time OS 13 Task Priority  Unique priority (also used as task identifiers)  64 priorities max (8 reserved)  Always run the highest priority task that is READY  Allow dynamically change priority

SOC Consortium Course Material Real-time OS 14 Task Control Block uC/OS-II use TCB to keep record of each task States Stack Pointer Priority Misc … Link Pointer

SOC Consortium Course Material Real-time OS 15 Task Control Block(cont.)

SOC Consortium Course Material Real-time OS 16 Exchanging CPU Control void ExampleTask(void *pdata) { for(;;) { /* User Code */ /*System Call */ /* User Code */ } OSMboxPend(); OSQPend(); OSSemPend(); OSTaskSuspend(); OSTimeDly(); OSTimeDlyHMSM(); More… uC/OS-II Kernel API Control returns from task to OS when Kernel API is called

SOC Consortium Course Material Real-time OS 17 Exchanging CPU Control ABBCA Interrupt Handler OS Task Time Scheduling System Call Interrupt Interrupt Exit Only one of OS, Task, Interrupt Handler gets CPU control at a time

SOC Consortium Course Material Real-time OS 18 Task Scheduling Time ISR Low-priority Task High-priority Task ISR makes the high-priority task ready low-priority task Relinquishes the CPU  Non-preemptive

SOC Consortium Course Material Real-time OS 19 Task Scheduling  Preemptive uC/OS-II adopts preemptive scheduling Time ISR Low-priority Task High-priority Task ISR makes the high-priority task ready high-priority task Relinquishes the CPU

SOC Consortium Course Material Real-time OS 20 Context Switching  Context Switching The process of swap in/out the context of tasks when scheduler choose a new task to run.  Context Usually means values in registers used by the task.  Switching Steps 1.Save registers of current task to stack (curr) 2.Load new task’s SP into CPU 3.Restore registers of new task from stack (new) 4.Resume execution of new task

SOC Consortium Course Material Real-time OS 21 Context Switching Time ISR Low-priority Task High-priority Task ISR makes the high-priority task ready Context Switching Context Switching high-priority task Relinquishes the CPU

SOC Consortium Course Material Real-time OS 22 Critical Region Code need to be treated indivisibly  Code have to be executed without interrupt creating task…etc  Non-reentrant code accessing shared variable…etc

SOC Consortium Course Material Real-time OS 23 Critical Region  Protecting critical region OS_ENTER_CRITICAL( ) temporarily disable interrupt OS_EXIT_CRITICAL( ) re-enable interrupt

SOC Consortium Course Material Real-time OS 24 Events  A way for Synchronization and Communication Pend(Wait for an event) Post(Signal an event)  Events in uC/OS-II Semaphore Counting Semaphore Message Mailbox Message Queues

SOC Consortium Course Material Real-time OS 25 Semaphore  Semaphore serves as a key to the resource  A flag represent the status of the resource  Prevent re-entering Critical Region  Can extent to counting Semaphore Task 1 Task 2 RS-232 Send data via RS232 Semaphore Request/Release

SOC Consortium Course Material Real-time OS 26 Semaphore Using Semaphore in uC/OS-II  OSSemCreate()  OSSemPend()  OSSemPost()  OSSemQuery()  OSSemAccept()

SOC Consortium Course Material Real-time OS 27 Message Mailbox  Used for Inter-Process Communication (IPC)  A pointer in MailBox points to the transmitted message Task ISR Task “message” Mail Box Post Pend

SOC Consortium Course Material Real-time OS 28 Message Queues  Array of MailBox  FIFO & FILO configuration Task ISR Task “message” Mail Queues Post Pend

SOC Consortium Course Material Real-time OS 29 MailBox & Queues Using MailBox in uC/OS-II  OSMboxCreate()  OSMboxPend()  OSMboxPost()  OSMboxQuery()  OSMboxAccept() Using Queue in uC/OS-II  OSQCreate()  OSQPend()  OSQPost()  OSQPostFront()  OSQQuery()  OSQAccept()  OSQFlush()

SOC Consortium Course Material Real-time OS 30 Memory Management  Semi-dynamic memory allocation  Allocate statically and dispatch dynamically  Explore memory requirements at design time Task 1 Task 2 Task 3 allocate statically partition into memory blocks dispatch dynamically OS InitializingOS running

SOC Consortium Course Material Real-time OS 31 Memory Management Using Memory in uC/OS-II  OSMemCreate()  OSMemGet()  OSSemPut()  OSSemQuery()

SOC Consortium Course Material Real-time OS 32 Interrupt  Interrupt Controller A device that accepts up to 22 interrupt sources from other pheripherals and signals ARM processor  Interrupt Handler A routine executed whenever an interrupt occurs. It determines the interrupt source and calls corresponding ISR. Usually provided by OS.  Interrupt Service Routine (ISR) Service routines specific to each interrupt source. This is usually provided by hardware manufacturer.

SOC Consortium Course Material Real-time OS 33 Interrupt  Peripheral sends interrupt request to interrupt controller  Interrupt controller sends masked request to ARM  ARM executes interrupt handler to determine int. source Peripheral B Interrupt Controller Interrupt Controller Peripheral A ARM Processor ARM Processor bus

SOC Consortium Course Material Real-time OS 34 Interrupt  Default interrupt handler: uHALr_TrapIRQ() 1.Save all registers in APCS-compliant manner 2.Call StartIRQ(), if defined 3.Determine interrupt source, call the corresponding interrupt service routine (ISR) 4.Call FinishIRQ(), if defined 5.Return from interrupt

SOC Consortium Course Material Real-time OS 35 Interrupt  When an interrupt occurs, no further interrupt accepted  To achieve real-time, the period of interrupt disabled should be as short as possible  Do only necessary jobs in ISR, leave other jobs in a deferred Task

SOC Consortium Course Material Real-time OS 36 Starting  C/OS-II Initialize hardware & uC/OS-II ARMTargetInit(), OSInit() Initialize hardware & uC/OS-II ARMTargetInit(), OSInit() Allocate resources OSMemCreate(), OSMboxCreate(), …etc Allocate resources OSMemCreate(), OSMboxCreate(), …etc Create at least one task OSTaskCreate() Create at least one task OSTaskCreate() Start Scheduler OSStart() Start Scheduler OSStart()

SOC Consortium Course Material Real-time OS 37 Porting Application Necessary coding changes  variables use local variables for preemption use semaphore to protect global variables (resources)  data transfer arguments => mailbox/queue  memory allocation malloc() => OSMemCreate() OSMemGet()

SOC Consortium Course Material Real-time OS 38 Porting Application assign task priorities  unique priority level in uC/OS-II only 56 levels available priority can be change dynamically  call OSTimeDly() in infinite loop task ensure lower priority task get a chance to run MUST: if lower priority task is pending data from higher priority task

SOC Consortium Course Material Real-time OS 39 Priority Inversion Task 1 (H) Task 2 (M) Task 3 (L) Task 3 gets semaphore (2) Task 1 preempts Task 3 (3) Task 1 fails to get semaphore (5) Task 2 preempts task 3 (7) Task 3 resumes (9) Task 3 releases the semaphore (11) (1) (4) (6) (8) (12) (10) Priority Inversion running waiting

SOC Consortium Course Material Real-time OS 40 Priority Inversion  A long existing terminology, recently it becomes a buzzword due to “Pathfinder” on Mars (RTOS: VxWorks).  It refers to a lot of situation, may even be used intentionally to prevent starvation.  Unbounded priority inversion : Priority inversion occurs in unpredictable manners – this is what we care about.

SOC Consortium Course Material Real-time OS 41 Priority Inversion (continued)

SOC Consortium Course Material Real-time OS 42 Priority Inversion (continued)  The problem is that τ 1 and τ 3 share a common data structure, locking a mutex to control access to it. Thus, if τ 3 locks the mutex, and τ 1 tries to lock it, τ 1 must wait. Every now and then, when τ 3 has the mutex locked, and τ 1 is waiting for it, τ 2 runs because it has a higher priority than τ 3. Thus, τ 1 must wait for both τ 3 and τ 1 to complete and fails to reset the timer before it expires.

SOC Consortium Course Material Real-time OS 43 Priority Inversion (continued)  Solution : priority inheritance protocol and priority ceiling protocol.  Priority ceiling : raises the priority of any locking thread to the priority ceiling for each lock.  Priority inheritance : raises the priority of a thread only when holding a lock causes it to block a higher priority thread.

SOC Consortium Course Material Real-time OS 44 Driver  What is a Driver A named entity that support basic I/O of a device A handler that manages interrupt from a device A description to a device, registered and managed by OS An abstraction layer for user application to access device easily

SOC Consortium Course Material Real-time OS 45 Driver Original configuration of a System – No additional Hardware Application OS HAL Development Board

SOC Consortium Course Material Real-time OS 46 Driver New configuration of a System – additional Hardware added We must add driver into system to provide easy access of new hardware Application OS HAL Development Board New Hardware Driver

SOC Consortium Course Material Real-time OS 47 Driver  High-level API Interactive with OS Interface to Application  Low-level Command Direct access to hardware (usually written in assembly)  Data Private data to driver Application OS HAL Development Board New Hardware API CommandData

SOC Consortium Course Material Real-time OS 48 Driver  Command Layer A set of functions/macros to manipulate hardware Interrupt handler Usually written in Assembly to get optimized speed Keep essential commands only  Common essential commands Read, Write, Init, Enable, Disable

SOC Consortium Course Material Real-time OS 49 Driver  API layer Interactive with OS to maintain resources Interactive with OS to acknowledge interrupt and task scheduling Provides unique interface to application to achieve device abstraction Encapsulate driver internal data Combine commands to provide various functionality  Data Driver Status Data Buffer

SOC Consortium Course Material Real-time OS 50 Driver Why divide driver into two parts Easy to replace underlying hardware Unique interface to applications Easy to adopt pre-written assembly code

SOC Consortium Course Material Real-time OS 51 Driver API Example Available commands: Read_Byte Write_Byte Init_Device Enable_Device Disable_Device Set_serial_baudrate(int baud) { OS_Request_Device(); Disable_Device(); Write_Byte(CONF_BASE, baud); Enable_Device(); OS_Release_Device(); }

SOC Consortium Course Material Real-time OS 52 Driver Send_serial(char data[], int len) { OS_Request_Device(); for(I=0;I<len;I++) Write_Byte(IO_BASE, data[I]); OS_Release_Device(); } Available commands: Read_Byte Write_Byte Init_Device Enable_Device Disable_Device API Example

SOC Consortium Course Material Real-time OS 53 Driver Design Flow start Decide I/O interface (I/O address, I/O method) Decide I/O interface (I/O address, I/O method) Write Assembly code to control hardware Write Assembly code to control hardware Write API base on previously Developed commands Write API base on previously Developed commands Write interrupt handler Pack assembly code into commands Pack assembly code into commands end Test assembly code Test Driver