0% found this document useful (0 votes)
4 views

Module6 Notes

The document provides an overview of μC/OS-II and VxWorks, two real-time operating systems (RTOS) designed for embedded systems. μC/OS-II, developed by Jean J. Labrosse, features multitasking, determinism, and scalability, while VxWorks, developed by Wind River, emphasizes high performance, safety, and security certification. A comparison highlights differences in source models, task management, and inter-process communication mechanisms between the two systems.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Module6 Notes

The document provides an overview of μC/OS-II and VxWorks, two real-time operating systems (RTOS) designed for embedded systems. μC/OS-II, developed by Jean J. Labrosse, features multitasking, determinism, and scalability, while VxWorks, developed by Wind River, emphasizes high performance, safety, and security certification. A comparison highlights differences in source models, task management, and inter-process communication mechanisms between the two systems.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

EC366 Realtime Operating Systems

Module 6

μC/OS-II Features
• Jean J. Labrosse designed ucOS in 1992
• uCOS II in 1998 uCOS III in 2009
• μC/OS name derives from MicroController Operating System
• Also known as MUCOS, UCOS, ..
Characteristics
• Multitasking
• Deterministic
• Portable as ROM image
• Scalable
• It supports many CPU that are used in embedded systems
• Different Platforms support
• Full source code availability (www.micrium.com)
• Elegantly and very well documented in the book by its designer

The figure above describes four types of class belonging to the software layer of uC/OS.
Three layers pertain to kernel source files , namely processor-independent code layer,
application-specific code layer and processor-specific code layer.
Processor-Specific code contains functions used to interact with specific hardware and it is
written in assembly language of the processor. Code, describing context switching method and
interrupt handling methods necessary for the execution of upper layer are situated here.
Application-specific and processor-Independent code are written in C language.
Portable:
Most of uC/OS-II is written in highly portable ANSI C, with target microprocessor specific code
written in assembly language. Assembly language is kept to a minimum to make μC/OS -II easy
to port to other processors. OS, μC/OS-II can be ported to a large number of microprocessors as
long as the microprocessor provides a stack pointer and the CPU registers can be pushed onto
and popped from the stack. Also, the C compiler should either provide in-line assembly or
language extensions that allow you to enable and disable interrupts from C.
μC/OS-II can run on most 8-bit, 16-bit, 32-bit or even 64-bit microprocessors or microcontrollers
and, DSPs.
ROMable:
μC/OS-II was designed for embedded applications. This means that if you have the proper tool
chain (i.e. C compiler, assembler and linker/locator), you can embed μC/OS-II as part of a
product.
Scalable:
μC/OS-II is scalable so that you can use only the services that you need in your application. This
allows you to reduce the amount of memory (both RAM and ROM) needed by μC/OS-II on a
product per product basis. Scalability is accomplished with the use of conditional compilation.
You simply specify (through #define constants) which features you need for your product.
Preemptive:
μC/OS-II is a fully-preemptive real-time kernel. This means that μC/OS-II always runs the
highest priority task that is ready. Most commercial kernels are preemptive and μC/OS-II is
comparable in performance with many of them.
Multi-tasking:
The first version of μC/OS-II can manage up to 64 tasks, however, the current version of the
software ucOSII V2.8 priorities can go from 0 (highest priority) to a maximum of 254 (lowest
possible priority). The OS reserves eight (8) of these tasks for system use. Each task has a unique
priority assigned to it. μC/OS-II cannot do round robin scheduling, since no two tasks can have
the same priority.
Deterministic:
Execution time of all μC/OS-II functions and services are deterministic. This means that you can
always know how much time μC/OS-II will take to execute a function or a service.
Task stacks:
Each task requires its own stack, however, μC/OS-II allows each task to have a different stack
size. This allows you to reduce the amount of RAM needed in your application. With μC/OS-II’s
stack checking feature, you can determine exactly how much stack space each task actually
requires.
Services:
uC/OS-II provides a number of system services such as mailboxes, queues, semaphores, fixed-
sized memory partitions, time related functions, etc.
Interrupt Management:
Interrupts can suspend the execution of a task and, if a higher priority task is awakened as a
result of the interrupt, the highest priority task will run as soon as all nested interrupts complete.
Interrupts can be nested up to 255 levels deep.
Robust and reliable:
μC/OS-II is based on μC/OS which has been used in hundreds of commercial applications since
1992. μC/OS-II uses the same core and most of the same functions as μC/OS yet offers more
features.
Task
A task is a program that thinks it has the CPU for itself. A task runs as an infinite loop where all
task behavior happened. Only one task can run at a time. However 255 tasks can cohabit within
the same system. The order of execution is determined by task priority of each task.
A typical task given below:

void Task (void *p_arg)


{
Do something with argument p_arg;
Task initialization;
while(1) {
/* Processing (application Code) */
Wait for event; /* Time to expire ... */
/* Signal from ISR ... */
/* Signal from task ... */
/* Processing (application Code) */
}}
Figure : The five states a task can take.
Task dormant state is set to tasks not currently running.
Ready tasks are running tasks not waiting for an event and which have been preempted.
Waiting tasks are tasks blocking for an event such as tasks waiting or delayed tasks.
Running tasks are started tasks not yet preempted.
ISR running state is set to interrupted tasks, waiting for the return from interrupt.

Changing from one state to another is made by calling the functions displayed on the edges.

VxWorks Features

VxWorks is a real-time operating system (RTOS) developed as proprietary software by Wind


River, an Intel subsidiary of Alameda, California, USA.
VxWorks is designed for use in embedded systems requiring real-time, deterministic
performance and, in many cases, safety and security certification, for industries, such as
aerospace and defense, medical devices, industrial equipment, robotics, energy, transportation,
network infrastructure, automotive, and consumer electronics
VxWorks from WindRiver
• High-performance, multitasking , scalable and hierarchical RTOS
• Host and target based development approach
• Supports ‘Device Software Optimization ─ a new methodology that enables development and
running of device software faster, better and more reliably
Supports advanced processor architectures─

Hard real time applications


• Supports kernel mode execution of tasks
• Provides preemptive as well as round robin scheduling,
• Support POSIX standard asynchronous IOs
• Support UNIX standard buffered I/O interfaces
• Separate context for tasks and ISRs [Each task has a separate TCB, while ISRs a common
stack] Schedules the ISRs separately and has special functions for interrupt handling
_ Watchdog timers
_ Virtual I/O devices including the pipes and sockets
_ Virtual Memory Management functions
Power management functions that enhance the ability to control power consumption
_ Automatic detection and reporting of common memory and other errors
_ Interconnect functions that support large number of protocols

Host-Target Development Approach


Host Windows, Linux or Unix for Embedded Development and cross compiled for target system
processor
_ RTOS ROM resident code downloaded using TCP/IP or serial port to a target board

Scalable OS – only needed OS functions become part of the application codes


_ Configuration file includes the user definitions for the needed IPC functions.
Protection features – for example, if a task is expecting a message from another
task, which is being deleted by using the task-delete function, then RTOS inhibits
the deletion
• No priority inversion problem─ the task gets an inherited priority when option
of priority inheritance selected

VxWorks Basic Functions


• System Level – OS initiate, start, system timer clock rate set, ISR enter and exit,
enable and disable
• Task Service Functions – initiate, resume, activate, run, suspend, (now or after delay)
• Task control functions IPCs – Semaphore, Queue and Pipes, POSIX IPCs
• Network Functions
• IO Functions

Signal
• IPC signal used for exception handling or handling software interrupt event

Three different Semaphore functions for Synchronization .


• Binary Semaphore for event signal flag,
• Mutex Semaphore for mutually exclusive access using resource key (mutex)
• Counting semaphore for counting mechanism

• P-V semaphore functions when POSIX library included

There is no Mailbox in Vxworks. •


Vxworks provides for queuing of the messages.
Queues can be used for priority posting of message using post front as in uC/OS-II
Provides for two ways in which a pending task can unblock
– (a) as per task priority (b) as a FIFO, when accepting or taking an IPC

. Virtual device Functions


_ Pipe Drivers for inter-process communications as an I/O virtual device
_ Network-transparent sockets.
_ Network drivers for shared memory and Ethernet.
_ RAM "disk" drivers for memory resident files

Task functions
• Task creation and activation are two distinct states
• Functions for the task creating, running, waiting, suspending (inhibiting task-execution) and
resuming, spawning (creating followed by activating), task-pending cum suspending .
Comparing uC/OS and VxWorks

uC/OS Vxworks
Developer Micrium, Inc., Silicon Labs Wind River (a wholly owned subsidiary of Intel Corporation)

Source model Closed source, source


available Source not available

Initial release 1991; 27 years ago 1987; 31 years ago

Latest release OS-III / 2016; 2 years ago 2014; 4 years ago

Marketing Embedded devices Embedded systems


target

Platforms ARM Cortex-M3, Cortex- x86 (including Intel Quark), x86-64, MIPS, PowerPC, SH-
M4F, ARM7TDMI; Atmel 4, ARM
AVR

Kernel type Microkernel Monolithic

License Commercial, freeware Proprietary


education use

Official website www.micrium.com/ www.windriver.com/products/vxworks/


products

Development C source code can support Host and target based development approach. Supports Device
any C cross compiler Software Optimization (DSO) methodology. Safety and security
certification

RTOS standard Does not support POSIX Supports RTOS standard POSIX
support functions

Other RTOS _ Watchdog timers


functions _ Virtual I/O devices including the pipes and sockets
_ Virtual Memory Management functions
Power management functions that enhance the ability to control
power consumption
_ Automatic detection and reporting of common memory and
other errors
_ Interconnect functions that support large number of protocols
Task Priority Maximum 256 tasks, each Maximum 256 tasks . Can have number of tasks with same
having unique priority. 0 is priority. 0 is the highest and 255 is the lowest priority.
the highest and 255 is the
lowest priority.

Interrupt Interrupts can suspend the • Separate context for tasks and ISRs [Each task has a separate
Handling execution of a task and, if a TCB, while ISRs a common stack] Schedules the ISRs
higher priority task is separately and has special functions for interrupt handling
awakened as a result of the
interrupt, the highest
priority task will run as
soon as all nested interrupts
complete. Interrupts can be
nested up to 255 levels
deep.
Round Robin Not supported since tasks Tasks with same priorities can be scheduled by Round robin
scheduling with same priority does not method
exist

Priority Not supported. So there is a Can prevent priority inversion, since the task can get an
Inheritance chance of priority inherited priority.
inversion.

Inter Process Semaphore, Mutex, Event Three different Semaphore functions for Synchronization .
Communication flags. MailBox and • Binary Semaphore for event signal flag,
Message QP. Provides for • Mutex Semaphore for mutually exclusive access using
resource key (mutex)
queuing of the messages.
• Counting semaphore for counting mechanism
Queues can be used for There is no Mailbox in Vxworks. •
priority posting of message Provides for two ways in which a pending task can unblock
using post front – (a) as per task priority (b) as a FIFO, when accepting or
taking an IPC

IPC signal used for exception handling or handling software


interrupt event

You might also like