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

SOC Consortium Course Material

Real-time OS

Speaker: 沈文中

April. 9, 2003

National Taiwan University

Adopted from National Chiao-Tung University

SOC Course Material

2SOC Consortium Course Material

Real-tim

e OS

Outline

Introduction to RTOS Introduction to μC/OS-II


Real-tim

e OS

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


Real-tim

e OS

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


Real-tim

e OS

Outline

Introduction to RTOS Introduction to μC/OS-II


Real-tim

e OS

μ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

http://www.ucos-ii.com


Real-tim

e OS

μ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


Real-tim

e OS

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 application AFS Utilities

C, C++ libraries

uHAL routines

Development board

AFS supportroutines


Real-tim

e OS

Kernel

Basic jobs of uC/OS-II kernel

• Task management

• Interrupt handling

• Inter-process communication


Real-tim

e OS

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


Real-tim

e OS

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)


Real-tim

e OS

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


{

/* User Code */

OSTaskDel(PRIO_SELF);

}

Task that delete itself


Real-tim

e OS

Task States

WaitingWaiting

DormantDormantReadyReady RunningRunning ISRISR

Task Create

Task Delete

Highest Priority Task

Task is Preempted

Task Pending EventsTask Gets Event

Task Delete

Interrupt

Int. Exit

Task Delete


Real-tim

e OS

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


Real-tim

e OS

Task Control Block

uC/OS-II use TCB to keep record of each task

States

Stack Pointer

Priority

Misc …

Link Pointer


Real-tim

e OS

Task Control Block(cont.)


Real-tim

e OS

Exchanging CPU Control


{

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


Real-tim

e OS

Exchanging CPU Control

A B B C A

Interrupt Handler

OS

Task

Time

Scheduling

System Call

Interrupt

Interrupt Exit

Only one of OS, Task, Interrupt Handler gets CPU control at a time


Real-tim

e OS

Task Scheduling

Time

ISR

Low-priority Task

High-priority Task

ISR makes thehigh-priority task ready

low-priority taskRelinquishes the CPU

Non-preemptive


Real-tim

e OS

Task Scheduling

Preemptive

uC/OS-II adopts preemptive scheduling

Time

ISR

Low-priority Task

High-priority Task


high-priority taskRelinquishes the CPU


Real-tim

e OS

Context Switching

Context SwitchingThe process of swap in/out the context of tasks when scheduler choose a new task to run.

ContextUsually means values in registers used by the task.

Switching Steps1. 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


Real-tim

e OS

Context Switching

Time

ISR

Low-priority Task

High-priority Task


ContextSwitching

ContextSwitching

high-priority taskRelinquishes the CPU


Real-tim

e OS

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


Real-tim

e OS

Critical Region

Protecting critical region

• OS_ENTER_CRITICAL( )

temporarily disable interrupt

• OS_EXIT_CRITICAL( )

re-enable interrupt


Real-tim

e OS

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


Real-tim

e OS

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 1Task 1

Task 2Task 2

RS-232RS-232

Send data via RS232

Send data via RS232

Semaphore

Request/Release

Request/Release


Real-tim

e OS

Semaphore

Using Semaphore in uC/OS-II

OSSemCreate()

OSSemPend()

OSSemPost()

OSSemQuery()

OSSemAccept()


Real-tim

e OS

Message Mailbox

Used for Inter-Process Communication (IPC)

A pointer in MailBox points to the transmitted message

TaskTask

ISRISR

TaskTask

“message”

Mail BoxPost

Post

Pend


Real-tim

e OS

Message Queues

Array of MailBox

FIFO & FILO configuration

TaskTask

ISRISR

TaskTask

“message”

Mail QueuesPost

Post

Pend


Real-tim

e OS

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()


Real-tim

e OS

Memory Management

Semi-dynamic memory allocation Allocate statically and dispatch dynamically Explore memory requirements at design time

Task 1Task 1 Task 2Task 2 Task 3Task 3

allocate statically

partition into memory blocks

dispatch dynamically

OS Initializing OS running


Real-tim

e OS

Memory Management

Using Memory in uC/OS-II

OSMemCreate()

OSMemGet()

OSSemPut()

OSSemQuery()


Real-tim

e OS

Interrupt

Interrupt ControllerA device that accepts up to 22 interrupt sources from other pheripherals and signals ARM processor

Interrupt HandlerA 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.


Real-tim

e OS

Interrupt

Peripheral sends interrupt request to interrupt controller

Interrupt controller sends masked request to ARM

ARM executes interrupt handler to determine int. source

Peripheral BPeripheral B

InterruptController

InterruptController

Peripheral APeripheral A

ARMProcessor

ARMProcessor

bus


Real-tim

e OS

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


Real-tim

e OS

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


Real-tim

e OS

Starting C/OS-II

Initialize hardware & uC/OS-IIARMTargetInit(), OSInit()

Initialize hardware & uC/OS-IIARMTargetInit(), OSInit()

Allocate resourcesOSMemCreate(), OSMboxCreate(), …etc

Allocate resourcesOSMemCreate(), OSMboxCreate(), …etc

Create at least one taskOSTaskCreate()

Create at least one taskOSTaskCreate()

Start SchedulerOSStart()

Start SchedulerOSStart()


Real-tim

e OS

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()


Real-tim

e OS

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


Real-tim

e OS

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


Real-tim

e OS

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.


Real-tim

e OS

Priority Inversion (continued)


Real-tim

e OS


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.


Real-tim

e OS


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.


Real-tim

e OS

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


Real-tim

e OS

Driver

Original configuration of a System –

No additional Hardware

ApplicationApplication

OSOS

HALHAL

Development BoardDevelopment Board


Real-tim

e OS

Driver

New configuration of a System – additional Hardware added

We must add driver into system to provide easy access of new hardware


OSOS

HALHAL

Development BoardDevelopment BoardNew HardwareNew Hardware

DriverDriver


Real-tim

e OS

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


OSOS

HALHAL

Development BoardDevelopment BoardNew HardwareNew Hardware

API

CommandData


Real-tim

e OS

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


Real-tim

e OS

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


Real-tim

e OS

Driver

Why divide driver into two parts• Easy to replace underlying hardware

• Unique interface to applications

• Easy to adopt pre-written assembly code


Real-tim

e OS

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();

}


Real-tim

e OS

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


Real-tim

e OS

Driver Design Flow

startstart

Decide I/O interface(I/O address, I/O method)

Decide I/O interface(I/O address, I/O method)

Write Assembly codeto control hardware

Write Assembly codeto control hardware

Write API base on previouslyDeveloped commands

Write API base on previouslyDeveloped commands

Write interrupt handlerWrite interrupt handler

Pack assembly codeinto commands

Pack assembly codeinto commands

endend

Test assembly codeTest assembly code

Test DriverTest Driver

Documents

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