Upload
ngotram
View
236
Download
2
Embed Size (px)
Citation preview
μC/OS-II
Mike Holenderski
Department of Mathematics and Computer ScienceSystem Architecture and NetworkingEindhoven University of Technology
23 April 2013
Outline
• Introduction to operating systems
• Introduction to μC/OS-II
• Tasks
• Scheduling
• Interrupts
• Exercises
2
Why operating systems?
3
Operating system
Operating system
4
• Provide applications with a hardware abstraction layer- Generic interfaces (APIs) hiding hardware details- Convenient abstractions, addressing common problems
• File system, unix pipes, tasks, ...
- Multiplex application tasks on the shared resources• Processor, bus, network, memory, timers, ...
• Monolithic vs. microkernel based operating system- Microkernel:
• Kernel implements only basic services (task and memory management, and task communication)
• Higher level services are implemented on top• Increased maintainability, security and stability
Real-time operating system
• Manage tasks and communication between tasks- Interrupt handling- Task scheduling- Context switching between tasks- Task synchronization and communication:
• Semaphores, mutexes, timers, ...
• Known and high performance- low and bounded latencies and jitter for API calls and ISRs
• Small memory foot print (for embedded use)- Configurable (no cost for unused functionality)
5
Example: OSEK/VDX
• Joint project in German/French automotive industry
• Motivation:- High, recurring expenses in the development of control
software (i.e. non-application)- Incompatibility of control units made by different
manufactures due to different interfaces and protocols
• Goal: “create an industry standard for an open-ended architecture for distributed control units in vehicles”- Support for portability and reusability, through:
• Specification of abstract interfaces (i.e. independent of applications and hardware)
• Configurable and efficient architecture
6
Example: OSEK/VDX
• Several OSEK specifications:- Operating System
• Real-time execution of ECU software and base for the other OSEK/VDX modules
- Communication• Data exchange within and between ECUs
- Network Management• Configuration and monitoring
7
Example: OSEK OS
• Task management- Basic and Extended tasks- Activation, suspension and termination of tasks- Task switching- Note: tasks, semaphores, ... must be statically allocated!
• Synchronization- Priority Ceiling
• Interrupt management
• Alarms (i.e. Timers)
• Error treatment
8
OSEK OS: task states
9
OSEK/VDX Operating System
Specification 2.2.3
18 © by OSEK OSEK OS 2.2.3
4.2.2 Basic tasks
The state model of basic tasks is nearly identical to the extended tasks state model. The only exception is that basic tasks do not have a waiting state. running In the running state, the CPU is assigned to the task, so that its instructions
can be executed. Only one task can be in this state at any point in time, while all the other states can be adopted simultaneously by several tasks.
ready All functional prerequisites for a transition into the running state exist, and the task only waits for allocation of the processor. The scheduler decides which ready task is executed next.
suspended In the suspended state the task is passive and can be activated.
running
suspendedstart
activate
terminate
preempt
ready
Figure 4-3 Basic task state model
Transition Former state
New state
Description
activate suspended ready4 A new task is set into the ready state by a system service. The OSEK operating system ensures that the execution of the task will start with the first instruction.
start ready running A ready task selected by the scheduler is executed. preempt running ready The scheduler decides to start another task. The
running task is put into the ready state. terminate running suspended The running task causes its transition into the
suspended state by a system service.
Figure 4-4 States and status transitions for basic tasks
4.2.3 Comparison of the task types Basic tasks have no waiting state, and thus only comprise synchronisation points at the beginning and the end of the task. Application parts with internal synchronisation points shall be implemented by more than one basic task. An advantage of basic tasks is their moderate requirement regarding run time context (RAM). 4 Task activation will not immediately change the state of the task in case of multiple activation requests. If the task is not suspended, the activation will only be recorded and performed later.
OSEK/VDX Operating System
Specification 2.2.3
OSEK OS 2.2.3 © by OSEK 17
ready All functional prerequisites for a transition into the running state exist, and the task only waits for allocation of the processor. The scheduler decides which ready task is executed next.
waiting A task cannot continue execution because it shall wait for at least one event (see chapter 7, Event mechanism).
suspended In the suspended state the task is passive and can be activated.
running
suspendedstart
wait
activate
terminate
release
preempt
ready
waiting
Figure 4-1 Extended task state model
Transition Former state
New state
Description
activate suspended ready A new task is set into the ready state by a system service. The OSEK operating system ensures that the execution of the task will start with the first instruction.
start ready running A ready task selected by the scheduler is executed. wait running waiting The transition into the waiting state is caused by a
system service. To be able to continue operation, the waiting task requires an event.
release waiting ready At least one event has occurred which a task has waited for.
preempt running ready The scheduler decides to start another task. The run-ning task is put into the ready state.
terminate running suspended The running task causes its transition into the suspended state by a system service.
Figure 4-2 States and status transitions for extended tasks
Termination of a task is only possible if the task terminates itself ("self-termination"). This restriction reduces complexity of an operating system. There is no provision for a direct transition from the suspended state into the waiting state. This transition is redundant and would add to the complexity of the scheduler.
Extended task Basic task
[OSEK/VDX OS 2.2.3]
Example: OSEK OS
• Task management- Basic and Extended tasks- Activation, suspension and termination of tasks- Task switching
• Synchronization- Priority Ceiling
• Interrupt management
• Alarms (i.e. Timers)
• Error treatment
10
What is μC/OS-II?
• Real-time operating system
• Used in medical, military, aerospace, automotive, consumer electronics, ...
• Commercial, but “open source”
11
Properties of μC/OS-II
• Fixed-priority preemptive multitasking- Up to 64 or 256 tasks (configurable)
• Small and deterministic overheads- Short and predictable interrupt path
• Scalable- Many services: semaphores, mutexes, flags, mailboxes, ...- Enable services with conditional compilation directives
• Nested interrupts- Up to 255 levels deep
12
μC/OS-II architecture
13
CPU Timer
Hardware
Software
μC/OS-II Configuration(application specific)
μC/OS-II(processor independent code)
μC/OS-II Port(processor specific code)
Application Software
Application structure
14
void main(void) { OSInit(); OSTaskCreate(Task1, (void*)100, (void*)&Task1Stack[TASK_STACK_SIZE-1], 4); OSTaskCreate(Task2, ...); RandomSem = OSSemCreate(1); OSStart();}
15
OSTaskCreate()
INT8U OSTaskCreate(void (*task)(void* pd), void* pdata, OS_STK* ptos, INT8U prio);
task function
argument totask function
pointer to the stack
task priority
Task example
16
OS_STK Task1Stack[TASK1_STACK_SIZE];
void Task1 (void* data) { INT8U err; INT16U delay = data; INT16U x; for (x = 0;; x++) { OSSemPend(RandomSem, 0, &err); if (x % 3 == 0) ToggleLeds(GREEN); OSSemPost(RandomSem); OSTimeDly(data); }}
void main(void) { ... OSTaskCreate(Task1, 50, &Task1Stack[TASK1_STACK_SIZE-1], 5); ...}
Task: one shot vs. thread
• Both are dispatched by the scheduler within an interrupt handler
• One shot- Cannot block or self suspend- Executed within the context of the interrupt handler
• Thread- Can block or self suspend- Preserves its context
• Has its own stack
17
Task: one shot vs. thread
• Both are dispatched by the scheduler within an interrupt handler
• One shot- Cannot block or self suspend- Executed within the context of the interrupt handler
✓Thread- Can block or self suspend- Preserves its context
• Has its own stack
18
Task as a thread
• Task Control Block (TCB)- Stack Pointer, unique priority, ...
• Task context- Local task variables- Special registers (Program Counter, Status Register (PSW))- Preserving context:
• Store and load the task context on the task’s stack
• Task switch- Store the task’s context on its stack- Store the Stack Pointer inside the TCB
19
Scheduler
• Fixed-Priority Preemptive Scheduler• Unique priorities (lower number means higher priority)• Triggered synchronously and asynchronously (w.r.t. control flow)
- Implemented by OSSched() and OSIntExit()- (i) selects highest priority task, and (ii) switches if it has higher priority
than current task• The ready state of all tasks is managed with global variables
- OSRdyTbl[] and OSRdyGrp
20
Task
SchedulerSuspend
Task
SchedulerTimerexpired
01234567
89101112131415
1617181920212223
2425262728293031
3233343536373839
4041424344454647
4849505152535455
5657585960616263
Task Priority #
Lowest Priority Task(Idle Task)
Highest Priority Task
X
Y
OSRdyTbl[OS_LOWEST_PRIO / 8 + 1]01234567
OSRdyGrp
[7]
[6]
[5]
[4]
[3]
[2]
[1]
[0]
0 0 Y Y Y X X X
Bit position in OSRdyTbl[OS_LOWEST_PRIO / 8 + 1]
Bit position in OSRdyGrp andIndex into OSRdyTbl[OS_LOWEST_PRIO / 8 + 1]
Task's Priority
Figure 3-3, µC/OS-II1s Ready List The following piece of code is used to place a task in the ready list: OSRdyGrp |= OSMapTbl[prio >> 3]; OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07];
Listing 3.5, Making a task ready-to-run. where prio is the task's priority. As you can see from Figure 3-3, the lower 3 bits of the task's priority are used to determine the bit position in OSRdyTbl[], while the next three most significant bits are used to determine the index into OSRdyTbl[]. Note that OSMapTbl[] (see OS_CORE.C) is a table in ROM, used to equate an index from 0 to 7 to a bit mask as shown in the table below:
Index Bit mask (Binary)
[Labrosse, 2002]
22
Scheduler
• Making a task ready
• Checking if a task is ready
OSRdyGrp |= OSMapTbl[prio >> 3];OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07];
y = OSUnMapTbl[OSRdyGrp];x = OSUnMapTbl[OSRdyTbl[y]];prio = (y << 3) + x;
Interrupts
• Interrupt handler dispatched by an incoming interrupt
• Has higher priority than any task (interfere with tasks)- Needs to have a short and predictable execution time- Tasks can disable interrupts
• OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL()• Can lead to increased interrupt latency or missed interrupts• Keep interrupts disabled for as little time as possible!• Use only for short critical sections
• Represents high priority events (need to be handled)- Sometimes sufficient to only disable the scheduler
• Task maintains control of the CPU, but incoming interrupts are handled
23
Interrupt Service Routine
24
void OSTickISR(void) { Save processor registers; Call OSIntEnter(); Call OSTimeTick(); Call OSIntExit(); Restore processor registers; Execute a return from interrupt instruction;}
Interrupts
25
Task A
save context A
ISR
restore context A
Task A
Task B
restore context B
time
interrupt latency
interrupt response
interrupt overhead
interrupt recovery
Interrupt timing
• Interrupt latency- Max time interrupts are disabled- Time to start executing first instruction of the ISR
• Interrupt response- Interrupt latency- Time to save CPU context (registers PC, PWD)- Time to enter the ISR ( OSIntEnter())
• Interrupt recovery- Time to exit the ISR ( OSIntExit())- Time to restore CPU context
26
Timer interrupts
27
• Timer interrupts are especially important- Task delays in control applications, network packet
timeouts, ...
Timer interrupts
28
Task 1
Task 2
Task 3
Task 1
Task 2
Task 3
Timer interrupts
29
Task 1
Task 2
Task 3
Multiplexer
Timer interrupts
30
Task 1
Task 2
Task 3
OSTimeTick()
Timer interrupts
31
Timer interrupts
32
• Timer interrupts are especially important- Task delays in control applications, network packet
timeouts, ...
• Timed evens in uC/OS-II- No periodic tasks!- Single primitive:
• Delay a task for number of ticks: OSTimeDly() - Relative to the current time
• Handled by the tick handler OSTimeTick()- Called within the timer interrupt handler- Loops through all tasks, decrementing OSTimeDly and
checking if it is 0
OSTimeTick()
33
void OSTimeTick (void) {OS_TCB *task;
for all tasks {OS_ENTER_CRITICAL();if (task->OSTCBDly > 0) {
if (--task->OSTCBDly == 0) {OSRdyGrp |= task->OSTCBBitY;OSRdyTbl[task->OSTCBY] |= task->OSTCBBitX;
}}OS_EXIT_CRITICAL();
}OS_ENTER_CRITICAL();OSTime++;OS_EXIT_CRITICAL();
}
OSTimeTick()
34
void OSTimeTick (void) {OS_TCB *task;
for all tasks {OS_ENTER_CRITICAL();if (task->OSTCBDly > 0) {
if (--task->OSTCBDly == 0) {OSRdyGrp |= task->OSTCBBitY;OSRdyTbl[task->OSTCBY] |= task->OSTCBBitX;
}}OS_EXIT_CRITICAL();
}OS_ENTER_CRITICAL();OSTime++;OS_EXIT_CRITICAL();
}
Worst-Case Response Time analysis
35
• Smallest x satisfying:
• WCRT of the timer interrupt handler:- B0 : interrupt latency- WC0 : (interrupt response - latency) + OSTimeTick() +
interrupt recovery- AJ0 : clock jitter- WT0 : timer interrupt frequency
x = Bi + WCi +X
j<i
⇠x + AJj
WTj
⇡WCj
1
Worst-Case Response Time analysis
36
• Smallest x satisfying:
• WCRT of the highest priority task:- B1 : longest time a lower priority task disabled interrupts- WC1 : worst-case path through Task()
- AJ1 : AJ0 + WR0 - BR0 = AJ0 + B0 + WC0 - BC0
- WT1 : task period
x = Bi + WCi +X
j<i
⇠x + AJj
WTj
⇡WCj
1
Exercises
• Measure- Tick interrupt latency (suggest how to measure)- Tick interrupt overhead
• OSTimeTick() (best and worst case)
• Compare μC/OS-II with Johan’s kernel- Measure the above for Johan’s kernel
• Instantiate the WCRT analysis for Johan’s kernel and task set from Exercise C1
37
Exercises
• Implement periodic tasks on top of uC/OS-II- Given the following task structure:
What are the key issues here? Propose an improvement. Hint: use semaphores, and either timers in os_tmr.c or the timer hook OSTimeTickHook() to handle the arrival of periodic events.
38
void Task1 (void* data) { INT16U period = data; INT16U k = 0; INT32U offset = OSTimeGet(); for (;;) { ... OS_ENTER_CRITICAL(); delay = ++k*period - (OSTimeGet() - offset); OS_EXIT_CRITICAL(); OSTimeDly(delay); }}
Exercise
• Optional (for the very ambitious): implement one-shot tasks in uC/OS-II
39
References
• “MicroC/OS-II, The Real-time Kernel”, J. Labrosse, 2002, Second Endition
• “μC/OS-II Reference Manual”- Chapter 16 from the book- Available online
• μC/OS-II source code- Download from http://micrium.com
40