1. The Real-Time Kernel is a portable, ROMable,
scalable, preemptive real-time, multitasking
kernel for microprocessors and
microcontrollers.
µC/OS-II
2. Features
• MicroC/OS-II [24] is a fully preemptive kernel
written in ANSI C by Jean J. Labrosse.
• It can manage up to 64 tasks out of which eight
are reserved for system use in the current
version.
• This leaves 56 tasks available for the user
applications.
• Each task has a unique priority assigned to it,
which means that MicroC/OS-II cannot do round-
robin scheduling.
• There are 64 priority levels.
3. • MicroC/OS-II is a scalable kernel, in that the user can select only the
kernel features required in the application and leave the rest, thus
reducing the amount of memory needed by the system.
• The kernel provides API for enabling and disabling the scheduler.
• When the scheduler is disabled, the kernel behaves as a non-
preemptive system.
• MicroC/OS-II also provides a feature that provides run-time
statistics. When this feature is enabled, a system task executes
every second and computes the percent CPU usage.
4. • The priorities are dynamic, i.e., they can be
changed during the execution.
• On the negative side, there are only 56 user
tasks available and all the tasks should have
different priorities.
• Moreover, MicroC/OS-II also doesn’t support
POSIX standard unlike many other commercial
kernels.
5. • MicroC/OS-II provides services like mailboxes,
queues, semaphores, fixed-sized memory
partitions, time-related functions, etc.
• Because of its simplicity and lightweight, this
kernel is suitable for small embedded systems
that require high-performance.
6. Example 1
#include "includes.h"
/**********************************************************************************************************
* CONSTANTS
*********************************************************************************************************
*/
#define TASK_STK_SIZE 512 /* Size of each task‘s stacks (# of WORDs) */
#define N_TASKS 10 /* Number of identical tasks */
/*
*************************************************************************
********************************
* VARIABLES
*************************************************************************
********************************
*/
OS_STK TaskStk[N_TASKS][TASK_STK_SIZE]; /* Tasks stacks */
OS_STK TaskStartStk[TASK_STK_SIZE];
char TaskData[N_TASKS]; /* Parameters to pass to each task */
OS_EVENT *RandomSem; A semaphore
(explain later)
10. PC_DOSSaveReturn()
Save the current status of DOS for the future restoration.
Interrupt vectors and the RTC tick rate.
Set a global returning point by callingsetjump().
uC/OS-II can come back here when it terminates.
PC_DOSReturn()
11. Task Management Functions
The functions to create task, suspend and
resume, and time setting and time retrieving
functions
• OSTaskCreate()
• OSTaskSuspend()
• OSTaskResume()
• OSTimeSet()
• OSTimeGet()
12. Task Management Functions
OSTaskCreate()
Create tasks with the given arguments.
Tasks become “ready” after they are created.
Task is an active entity which could do some
computations.
Each task has own Priority, CPU registers, stack,
text, housekeeping status.
The µC/OS-II picks up the highest-priority task to
run on context-switching.
13. Prototype function of OSTaskCreate()
• Unsigned byte OSTaskCreate(void(*task) (void
*taskPointer),void*pmdata,OS_STK*taskStack
Pointer,unsigned byte taskPriority)
• Mucos task priority is also the task identifier.
• There is no task ID defining function in Mucos
because each task has to be asssigned a
distinct priority.
14. Task parameters passing PA:
• *taskPointer – a pointer to the codes of task
being created
• *pmdata – pointer for an optional message data
reference passed to the task, if none, we assign it
as NULL
• *taskStackPointer – pointer to the stack of task being
created.
• Task priority is must be within 8 to 15, if macro
OS_LOWEST_PRIO sets lowest priority equal to 23
15. function of OSTaskCreate() returs the
following:
• OS_NO_ERR – when creation suceeds
• OS_PRIO_EXIST – if priority value that passed
already exists
• OS_PRIO_INVALID - if priority values passed is
more than the OS_PRIO_LOWEST
• OS_NO_MORE_TCB –when no more memory
block for the task control is available.
17. OSTaskSuspend()
• It is used to suspend or block the task
Unsigned byte TaskSuspend(Unsigned byte taskPriority)
Task parameters passing PA:
• Task priority is must be within 8 to 15
Returning RB :
• OS_NO_ERR – when blocking suceeds
• OS_TASK_SUSPEND_PRIO – if priority value that passed
already does not exists
• OS_PRIO_INVALID - if priority values passed is more than
the 15
• OS_TASK_SUSPEND_IDLE – if attempting to suspend an idle
task that is illegal
18. OSTaskResume()
• Resuming or enabling unblocking a task
Unsigned byte TaskResume(Unsigned byte taskPriority)
Task parameters passing PC:
• Task is to resume and must be within 8 to 15 when
OS_LOWEST_PRIO is 23 and number of task =8
Returning RB :
• OS_NO_ERR – when blocking suceeds
• OS_TASK_RESUME_PRIO – if priority value that passed
already resumed
• OS_PRIO_INVALID - if priority values passed is more than
the 23
• OS_TASK_NOT_SUSPEND – if attempting to resume a not
suspended(blocked) task
19. OSTimeSet()
• Setting time in system clock
Void OSTimeSet(Unsigned int count)
• it returns no value
Parameter passing PD:
• It passes a 32 bit integer for the count
20. OSTimeGet()
• Getting time of system clock
Unsigned int OSTimeGet(void)
returns current number of ticks as an unsigned
integer. The passing parameter as argument is
none
RE:
Returns 32bit integer, current number of ticks at
the system clock
21. OS-STK
• Each task must have its own stack space.
• It can allocate stack space either statically(at
compile-time) or dynamically(at run-time).
Static OS_STK MyTaskStack[stack_size]
Or
OS_STK MyTaskStack[stack_size]
• We can allocate the stack size dynamically
using c complier malloc() function
22. OS_STK *pstk;
Pstk – (OS_STK*)malloc(stack_size);
If (pstk != (OS_STK*)0)
{
Create the task;
}
23. OsTaskStkChk()
• Determine how much stack space a task
actually uses.
• Stack checking allows to reduce the amount of
RAM needed by your application code by not
over allocating stack space
• OsTaskStkChk() computes the amount of free
stack space by walking from the bottom of
stack
26. OSTaskDel()
• To delete a task
• Deleting a task means that the task is returned to
the dormant state
• It does mean that the code for the task is actually
deleted
• The task code is simply no longer scheduled by
µC/OS-II
• Note:TASK DORMANT state corresponds to a task
that resides in program space but has not been
made avaliable to µC/OS-II
27.
28. Unsigned byte OSTaskDel(Unsigned byte taskPriority)
Checking condition before OSTaskDel()
• Not attempting to delete a task from within an
ISR
• Verifies the task to be delete exists
• Not aremmpting to delete the idle task be
29. OSTaskDelReq()
• Requesting to delete a task
• Task owns resources such as memory buffers
of a semaphore.
• If another task attempts to delete this task,
the resources are not freed and thus are lost
• First task that owns resources to delete itself
30. • OS_TASK_NOT_EXIST - if the task to delete
has already deleted or has not been created
• OS_NO_ERR – the request has been accepted
• OS_TASK_DEL_REQ - another task has
requested that this task needs to be deleted
31. OSTaskChangePrio()
• Changing a task’s priority
• When you create a task, you assign the task a
priority
• At runtime, you can change the priority of any
task by calling OSTaskChangePrio()
Unsigned byte OSTaskChangePrio (Unsigned byte taskoldPriority,
Unsigned byte tasknewPriority)
32. OSTaskQuery()
• Getting the information about the task
• Copy of the contents of the desired task’s
OS_TCB
unsigned byte OSTaskQuery(task priority,OS_TCB 8pdata)
33. Time Delay Functions
• Clock tick established that requires that provide
periodic interrupt to keep track of time delays
and timeouts
• The periodic time source is called as clock tick
and should occur between 10 and 100 times per
second or hertz.
OSTimeDly()
OSTimeDlyHMSM()
OSTimeDlyResume()
34. OSTimeDly()
• allows the calling task to delay itself for a user
specified number of clock ticks.
• Calling this function causes a context switch and
forces to execute the next highest priority task
that is ready to run
• The task calling OSTimeDly() is made ready to
run as soon as the time specified expires or if
another task cancels the delay by calling
OSTimeDlyResume()
35. Void OSTimeDly(unsigned short delay count)
• It returns no parameter
Task parameters passing PF:
• A 16 bit integer, delay count , to delay a task at
least till the system clock count inputs(ticks)
equal to delay count
36. OSTimeDlyResume()
• Resuming a delayed task by OSTimeDly()
• OSTimeDlyResume() resumes a previously
delayed task, whether the delay parameter
was in terms of the system clock ticks
• Defined delay is more than 65,535 system
clock ticks, it will not resume
37. unsigned byte OSTimeDlyResume(unsigned byte taskpriority )
Returning RG:
• OS_NO_ERR = true ,when resume after delay succeeds
• OS_TASK_NOT_EXISTS – if task was not created earlier.
• OS_PRIO_INVALID - if priority values passed is more than the
OS_PRIO_LOWEST(=23)
• OS_TASK_NOT_DLY – if task was not delayed
Task parameters passing PG:
Task priority is the priority of that task that is delayed before
resumption
38. OSTimeDlyHMSM()
• Delaying by defining a time delay in units of
hours, minutes, seconds and milliseconds
• It delays up to 65,535 ticks a task with delay
time defined by hr ours between 0 to 55,mn
minutes between 0 to 59,sec seconds
between 0 to59 and mils milliseconds
between 0 to 999.
39. Void OSTimeDlyHMSM(unsigned byte hr, unsigned byte mn, unsigned byte
sec,unsigned short ms )
Returning RH:
• OS_NO_ERR = ,when four arguments are valid and resume after
delay succeeds
• OS_TIME_INVALID_HOURS, OS_TIME_INVALID_MINUTES,
OS_TIME_INVALID_SECONDS, OS_TIME_INVALID_MILLI– if
arguments are greater than 55,59,59and 999 respectively.
• OS_TIME_ZERO_DLY – if all arguments passed are 0
Task parameters passing PH:
hr,mn,sec,ms are the delay times in hours ,minutes, seconds,
milliseconds by which task delays before resuming
40. Critical Sections
• A critical section is a portion of code that is not
safe from race conditions because of the use of
shared resources.
• They can be protected by interrupt
disabling/enabling interrupts or semaphores.
• The use of semaphores often imposes a more
significant amount of overheads.
• A RTOS often use interrupts disabling/enabling to
protect critical sections.
• Once interrupts are disabled, neither context
switches nor any other ISR’s can occur
41. • Interrupt latency is vital to an RTOS!
– Interrupts should be disabled as short as possible
to improve the responsiveness.
– It must be accounted as a blocking time in the
schedulability analysis.
• Interrupt disabling must be used carefully:
` E.g., if OSTimeDly() is called with interrupt
disabled, themachine might hang!
43. • The states of the processor must be carefully
maintained across multiple calls of
OS_ENTER_CRITICAL() and
OS_EXIT_CRITICAL().
• There are three implementations in uC/OS-II:
– Interrupt enabling/disabling instructions.
– Interrupt status save/restore onto/from stacks.
– Processor Status Word (PSW) save/restore
onto/from memory variables.
45. OS_CRITICAL_METHOD=1
• Interrupt enabling/disabling instructions.
• The simplest way! However, this approach
does not have the sense of “save” and
"restore”.
• Interrupt statuses might not be consistent
across kernel services/function calls!!
46. OS_CRITICAL_METHOD=2
• Processor Status Word (PSW) can be
saved/restored onto/from stacks.
• PSW’s of nested interrupt enable/disable
operations can be exactly recorded in stacks.
47. OS_CRITICAL_METHOD=3
• The compiler and processor allow the PSW to be
saved/restored to/from a memory variable.
void foo(arguments)
{
OS_CPU_SR cpu_sr;
cpu_sr = get_processor_psw();
disable_interrupts();
/* critical section */
set_processor_psw(cpu_sr);
48. Ready list
• Ready list is a special bitmap to reflect which
task is currently in the ready state.
• Each task is identified by its unique priority in
the bitmap.
• A primary design consideration of the ready
list is how to efficiently locate the highest-
priority ready task.
49. Ready list
• Each task is assigned a unique priority level
between 0 to OS_LOWEST_PRIO.
• Each task that is ready to run is placed in a ready
list consisting of two variables, OSRdyGrp and
OSRdyTbl[].
• Task priorities are grouped in OSRdyGrp. Each bit
in OSRdyGrp indicates when a task in a group is
ready to run.
• When a task is ready to run, it also sets its
corresponding bit in the ready table,OSRdyTbl[].
51. • Lower three bits of the task priority are used
to determine the bit poistion in OSRdyTbl[],
• And next three most significant bits are used
to determine the index into OSRdyTbl[],
• OSMapTbl[] is used to equate an index from 0
to 7 to a bit mask
52. Make a task ready to run:
OSRdyGrp |= OSMapTbl[prio >> 3];
OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07];
Remove a task from the ready list:
if ((OSRdyTbl[prio >> 3] &= ~OSMapTbl[prio & 0x07]) == 0)
OSRdyGrp &= ~OSMapTbl[prio >> 3];
Contents of OSMapTbl[]
53. OSUnMapTbl[]
• OSUnMapTbl[] is a priority resolution table.
Eight bits represent when tasks are ready in a
group.
• The least significant bit has the highest
priority.
• Using this byte to index OSUnMapTbl[] returs
the bit position of the highest priority bit set –
a number between 0 and 7
54.
55. Finding the highest-priority
task ready to run:
y = OSUnMapTbl[OSRdyGrp];
x = OSUnMapTbl[OSRdyTbl[y]];
prio = (y << 3) + x;
If OSRdyGrp contains 01101000 or 0x68, then
table lookup OSUnMapTbl[OSRdyGrp] yields a
value of 3,which corresponds to bit 3 in
OSRdyGrp
56. Task Scheduling
• The scheduler always schedules the highest
priority ready task to run .
• Task-level scheduling and ISR-level scheduling
are done by OS_Sched() and OSIntExit(),
respectively.
• The difference is the saving/restoration of
PSW (or CPU flags).
• uC/OS-II scheduling time is a predictable
amount of time, i.e., a constant time.
58. 1.Rescheduling will not be done if the scheduler
is locked or an ISR is currently serviced.
2. Find the highest-priority ready task.
3. If it is not the current task, then skip!
4. (4)~(6) Perform a context-switch.
59. OS_TASK_SW()
• After the scheduler has determined that a
more important task needs to run,
OS_TASK_SW() is called to perform a context
switch
• OS_TASK_SW() is a macro that normally
invokes a microprocessor software interrupt
because µC/OS-II assumes that context
switching will be done by interrupt level code
60. • A context switch must save all CPU registers and
PSW of the preempted task onto its stack,and
then restore the CPU registers and PSW of the
highest-priority ready task from its stack.
• Task-level scheduling will emulate that as if
preemption/scheduling is done in an ISR.
– OS_TASK_SW() will trigger a software interrupt
– The interrupt is directed to the context switch handler
OSCtxSw(), which is installed when µC/OS-II is
initialized.
61. • Interrupts are disabled during the locating of
the highest-priority ready task to prevent
another ISR’s from making some tasks ready.
• By default, context switches are handled at
the interrupt-level.
• Therefore task-level scheduling will invoke a
software interrupt to emulate that effect
63. • OSTCBCur points to the OS_TCB of the task being
suspended(low priority task).
• The CPU’s stack pointer points to the current top-
of-stack of the task being pre-empted.
• OSTCBHighRdy points to the OS_TCB of the task
that will execute after completing the context
switch.
• The . OS_TCBStkPtr field in the OS_TCB points to
the top-of-stack of the task to resume.
• The stack of task to resume contains the desired
register values to load into the CPU These values
could have been saved by a previous context
switch
65. • Calling OS_TASK_SW , which forces the
processor to save the current value of the
PSW and the PC onto the current task’s stack.
• The software interrupt handler starts by
saving the general purpose registers R1,R2,R3
and R4, in this order.
• The stack pointer register is then saved in to
current task’s OS_TCB .
• At this point, both the CPU’s SP register and
OSTCBCur -> OSTCBStkPtr are pointing to the
same location into the current task’s stack.
67. • Because the new current task is now the task
being resumed, the context switch code copies
OSTCBHighRdy to OSTCBCur.
• The stack pointer of the task to resume is
extracted from the OS_TCB and loaded into the
CPU’s SP register.
• At this points to the stack location containing the
value of register R4.
• The general purpose registers are popped from
the stack in the reverse order
• The PC and PSW are loaded back into the CPU by
executing a return from interrupt instruction.
68. Locking and Unlocking the
Scheduler
• OSSchedLock() prevents high-priority ready tasks from
being scheduled to run while interrupts are still
recognized.
• OSSchedLock() and OSSchedUnlock() must be used in
pairs.
• After calling OSSchedLock(), you must not call kernel
services which might cause context switch, such as
OSFlagPend(), OSMboxPend(), OSMutexPend(),
OSQPend(),OSSemPend(), OSTaskSuspend(),
OSTimeDly, OSTimeDlyHMSM(), until OSLockNesting ==
0. Otherwise,the system will be locked up.
72. 1) The application code consist of project or product files. For
convenience, we simply called these app.c and app.h but your
application can contain any number of files and they do not have to
be called app.*. The application code is typically where you would
find main().
(2) semiconductor manufacturers provide library functions in source
form for accessing the peripherals on their CPU (Central Processing
Unit) or MCU (Micro Controller Unit). These libraries are quite
useful and often save valuable time. Since there is no naming
convention for these files, *.c and *.h are assumed.
(3) The Board Support Package (BSP) is code that you would typically
write to interface to peripherals on your target board. For example
you can have code to turn on and off LEDs (light emitting diodes),
functions to turn on and off relays, and code to read switches and
temperature sensors.
73. (4) µC/CPU is an abstraction of basic CPU-specific functionality. These
files define functions to disable and enable interrupts, data types
(e.g., CPU_INT08U, CPU_FP32) independent of the CPU and
compiler and many more functions.
(5) µC/LIB consists of a group of source files to provide common
functions for memory copy, string manipulation and character
mapping. Some of the functions replace stdlib functions provided
by the compiler. These are provided to ensure that they are fully
portable from application to application and (most importantly)
from compiler to compiler.
(6) µC/Clk is an independant clock/calendar management module,
with source code for easily managing date and time in a product.
µC/FS uses the date and time information from µC/Clk to update
files and directories with the proper creation/modification/access
time.
74. (7) µC/CRC is a stand-alone module for calculating
checksums and error correction codes. This
module is used by some of µC/FS device drivers.
(8) This is the µC/FS platform-independent code,
free of dependencies on CPU and memory
device. This code is written in highly-portable
ANSI C code. This code is only available to µC/FS
licensees.
(9) This is the µC/FS system driver for FAT file
systems. This code is only available to µC/FS
licensees.
75. (10) This is the collection of device drivers for µC/FS. Each
driver supports a certain device type, such as SD/MMC
cards, NAND flash or NOR flash. Drivers are only
available to µC/FS licensees.
(11) This is the µC/FS code that is adapted to a specific
platform. It consists of small code modules written for
specific drivers called ports that must be adapted to
the memory device controllers or peripherals
integrated into or attached to the CPU. The
requirements for these ports are described in Appendix
C, Porting Manual.
76. (12) µC/FS does not require an RTOS. However,
if µC/FS is used with an RTOS, a set of
functions must be implemented to prevent
simultaneous access of devices and core µC/FS
structures by multiple tasks.
(13) This µC/FS configuration file defines which
µC/FS features (fs_cfg.h) are included in the
application.
77. Goals of Micro C/OS II
The goal of this project is to extend uC/OS-II
with Fixed Priority Deferred Preemption
(FPDS) scheduling and reservations.
78. We identified the following sub goals:
1. Investigation of Timers, Timing mechanisms and
Timed Events in RT systems.
2. Implementation of periodic tasks in uC/OS-II, based
on (1).
3. Implementation of FPDS in uC/OS-II.
4. Implementation of reservations in uC/OS-II.
5. Analysis of the implementation in terms of overhead.
6. Apply FPDS and reservations extension to the camera
platform
![Features
• MicroC/OS-II [24] is a fully preemptive kernel
written in ANSI C by Jean J. Labrosse.
• It can manage up to 64 tasks out of which eight
are reserved for system use in the current
version.
• This leaves 56 tasks available for the user
applications.
• Each task has a unique priority assigned to it,
which means that MicroC/OS-II cannot do round-
robin scheduling.
• There are 64 priority levels.](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)