Operating Systems Services

Following are the five services provided by an operating systems to the convenience of the users.

Program Execution
The purpose of a computer systems is to allow the user to execute programs. So the operating systems provides an environment where the user can conveniently run programs. The user does not have to worry about the memory allocation or multitasking or anything. These things are taken care of by the operating systems. Running a program involves the allocating and deallocating memory, CPU scheduling in case of multiprocess. These functions cannot be given to the user-level programs. So user-level programs cannot help the user to run programs independently without the help from operating systems.

I/O Operations
Each program requires an input and produces output. This involves the use of I/O. The operating systems hides the user the details of underlying hardware for the I/O. All the user sees is that the I/O has been performed without any details. So the operating systems by providing I/O makes it convenient for the users to run programs. For efficiently and protection users cannot control I/O so this service cannot be provided by userlevel programs.

File System Manipulation

The output of a program may need to be written into new files or input taken from some files. The operating systems provides this service. The user does not have to worry about secondary storage management. User gives a command for reading or writing to a file and sees his her task accomplished. Thus operating systems makes it easier for user programs to accomplished their task.This service involves secondary storage management. The speed of I/O that depends on secondary storage management is critical to the speed of many programs and hence I think it is best relegated to the operating systems to manage it than giving individual users the control of it. It is not difficult for the user-level programs to provide these services but for above mentioned reasons it is best if this service s left with operating system.

Communications
There are instances where processes need to communicate with each other to exchange information. It may be between processes running on the same computer or running on the different computers. By providing this service the operating system relieves the user of the worry of passing messages between processes. In case where the messages need to be passed to processes on the other computers through a network it can be done by the user programs. The user program may be customized to the specifics of the hardware through which the message transits and provides the service interface to the operating system.

Error Detection
An error is one part of the system may cause malfunctioning of the complete system. To avoid such a situation the operating system constantly monitors the system for detecting the errors. This relieves the user of the worry of errors propagating to various part of the system and causing malfunctioning. This service cannot allowed to be handled by user programs because it involves monitoring and in cases altering area of memory or deallocation of memory for a faulty process. Or may be relinquishing the CPU of a process that goes into an infinite loop. These tasks are too critical to be handed over to the user programs. A user program if given these privileges can interfere with the correct (normal) operation of the operating systems.

Embedded Systems/Real-Time Operating Systems

A Real-Time Operating System (RTOS) is a computing environment that reacts to input within a specific time period. A real-time deadline can be so small that system reaction appears instantaneous. The term real-time computing has also been used, however, to describe "slow real-time" output that has a longer, but fixed, time limit. Learning the difference between real-time and standard operating systems is as easy as imagining yourself in a computer game. Each of the actions you take in the game is like a program running in that environment. A game that has a real-time operating system for its environment can feel like an extension of your body because you can count on a specific "lag time:" the time between your request for action and the computer's noticeable execution of your request. A standard operating system, however, may feel disjointed because the lag time is unreliable. To achieve time reliability, real-time programs and their operating system environment must prioritize deadline actualization before anything else. In the gaming example, this might result in dropped frames or lower visual quality when reaction time and visual effects conflict.

Contents

1 Methods 2 Objectives 3 The Fundamentals 4 Real-Time Kernel

5 Basic Kernel Services

Methods
An operating system is considered real-time if it invariably enables its programs to perform tasks within specific time constraints, usually those expected by the user. To meet this definition, some or all of the following methods are employed:

The RTOS performs few tasks, thus ensuring that the tasks will always be executed before the deadline The RTOS drops or reduces certain functions when they cannot be executed within the time constraints ("load shedding") The RTOS monitors input consistently and in a timely manner The RTOS monitors resources and can interrupt background processes as needed to ensure realtime execution The RTOS anticipates potential requests and frees enough of the system to allow timely reaction to the user's request The RTOS keeps track of how much of each resource (CPU time per timeslice, RAM, communications bandwidth, etc.) might possibly be used in the worst-case by the currentlyrunning tasks, and refuses to accept a new task unless it "fits" in the remaining un-allocated resources.

Objectives
An RTOS must respond in a timely manner to changes, but that does not necessarily mean that an RTOS can handle a large throughput of data. In fact in an RTOS, small response times are valued much higher than power, or data speed. Sometimes an RTOS will even need to drop data to ensure that it meets its strict deadlines. In essence, that provides us with a perfect definition: an RTOS is an operating system designed to meet strict deadlines. Beyond that definition, there are few requirements as to what an RTOS must be, or what features it must have. Some RTOS implementations are very powerful and very robust, while other implementations are very simple, and suited for only one particular purpose. An RTOS may be either event-driven or time-sharing. An event-driven RTOS is a system that changes state only in response to an incoming event. A time-sharing RTOS is a system that changes state as a function of time

The Fundamentals
To most people, embedded systems are not recognizable as computers. Instead, they are hidden inside everyday objects that surround us and help us in our lives. Embedded systems typically do not interface with the outside world through familiar personal computer interface devices such as a mouse, keyboard and graphic user interface. Instead, they interface with the outside world through unusual interfaces such as sensors, actuators and specialized communication links. Real-time and embedded systems operate in constrained environments in

which computer memory and processing power are limited. They often need to provide their services within strict time deadlines to their users and to the surrounding world. It is these memory, speed and timing constraints that dictate the use of real-time operating systems in embedded software.

Real-Time Kernel
The heart of a real-time OS (and the heart of every OS, for that matter) is the kernel. A kernel is the central core of an operating system, and it takes care of all the OS jobs:
1. Booting 2. Task Scheduling 3. Standard Function Libraries

Now, we will talk about booting and bootloaders later, and we will also devote several chapters to task scheduling. So we should mention at least one thing about standard function libraries: In an embedded system, there is rarely enough memory (if any) to maintain a large function library. If functions are going to be included, they must be small, and important.In an embedded system, frequently the kernel will boot the system, initialize the ports and the global data items. Then, it will start the scheduler and instantiate any hardware timers that need to be started. After all that, the Kernel basically gets dumped out of memory (except for the library functions, if any), and the scheduler will start running the child tasks.

Basic Kernel Services

In the discussion below, we will focus on the "kernel" the part of an operating system that provides the most basic services to application software running on a processor. The "kernel" of a real-time operating system ("RTOS") provides an "abstraction layer" that hides from application software the hardware details of the processor (or set of processors) upon which the application software will run.

Interrupt Routines in an RTOS Environment - Part 1

Interrupt routines in most RTOS environments must follow two rules that do not apply to task code. Rule 1. An interrupt routine must not call any RTOS function that might block the caller. Therefore, interrupt routines must not get semaphores, read from queues or mailboxes that might be empty, wait for events, and so on. If an interrupt routine calls an RTOS function and gets blocked, then, in addition to the interrupt routine, the task that was running when the interrupt occurred will be blocked, even if that task is the highest- priority task. Also, most interrupt routines must run to completion to reset the hardware to be ready for the next interrupt. Rule 2. An interrupt routine may not call any RTOS function that might cause the RTOS to switch tasks unless the RTOS knows that an interrupt routine, and not a task, is executing. This means that interrupt routines may not write to mailboxes or queues on which tasks may be waiting, set events, release semaphores, and so on - unless the RTOS knows it is an interrupt routine that is doing these

things. If an interrupt routine breaks this rule, the RTOS might switch control away from the interrupt routine (which. the RTOS think is a task) to run another task, and the interrupt routine may not complete for a long time, blocking at least all lower-priority interrupts and possibly all interrupts. In the next few figures, well examine these rules. Rule 1: No Blocking In Figure we examine the software for the control of the nuclear reactor. This time, the task code and the interrupt routine share the temperature data with a semaphore. This code will not work. It is in violation of rule 1. If the interrupt routine happened to interrupt vTaskTestTemperatures while it had the semaphore, then when the interrupt routine called GetSemaphore, the RTOS wou1d notice that the semaphore was already taken and block. This will stop both the interrupt routine and vTaskTestTemperatures (the task that was interrupted), after which the system would grind to a halt in a sort of one-armed deadly embrace. With both the interrupt routine and vTaskTestTemperatures blocked, no code will ever release the semaphore. (Some RTOSs have an alternative - and equally useless - behavior in this situation: when the interrupt routine calls GetSemaphore, these RTOSs notice that vTaskTestTemperatures already has the semaphore and, since they think that vTaskTestTemperatures is still running, they let the interrupt routine continue executing. In this case, the semaphore no longer protects the data properly.) Even if the interrupt routine interrupts some other task, this code can cause problems. If vTaskTestTemperatures has the semaphore when the interrupt occurs, then, when the interrupt routine tries to get the semaphore too, it will block (along with whatever task was running when interrupt occurred). For as long as the interrupt routine is blocked and that may be for a long time if vTaskTestTemperatures does not get the microprocessor back to allow it to release the semaphore all lower-priority interrupt routines and the task that was unfortunate enough to be interrupted will get no microprocessor time. Some RTOSs contain various functions that never block. For example, many have a function that returns the status of a semaphore. Since such a function does not block, interrupt routines can call it (assuming that this i as in compliance with rule 2, which it usually is).

Rule 2: No RTOS Calls without Fair Warning To understand rule 2, examine figure above, a naive view of how an interrupt routine should work under an RTOS. The graph shows how the microprocessors attention shifted from one part of the code to another over time. The interrupt routine interrupts the lower-priority task, and, among other things, calls the RTOS to write a message to a mailbox (legal under rule l, assuming that function cant block). When the interrupt routine exits, the RTOS arranges for the microprocessor to execute either the original task, or, if a higher-priority task was waiting on the mailbox, that higher priority task. Figure below shows what really happens, at least in the worst case. If the higher-priority task is blocked on the mailbox, then as soon as the interrupt routine writes to the mailbox, the RTOS

unblocks the higher-priority task. Then the RTOS (knowing nothing about the interrupt routine) notices that the task that it thinks is running is no highest-priority task that is ready to run. Therefore, instead of returning to the interrupt routine (which the RTOS thinks is part of the lower priority task), the RTOS switches to the higher-priority task. The interrupt routine doesnt get to finish until later. RTOSs use various methods for solving this problem, but all require your cooperation. Figure shows the first scheme. In it, the RTOS intercepts all the interrupts and then calls your interrupt routine. By doing this, the RTOS finds out when an interrupt routine has started. When the interrupt routine later writes to mailbox, the RTOS knows to return to the interrupt routine and not to switch tasks, no matter what task is unblocked by the write to the mailbox. When the interrupt routine is over, it returns, and the RTOS gets control again. The RTOS scheduler then figures out what task should now get the microprocessor. If your RTOS uses this method, then you will need to call some function within the RTOS that tells the RTOS where your interrupt routines are and which hardware interrupts correspond to which interrupt routines. Figure shows an alternative scheme, in which the RTOS provides a function that the interrupt routines call to let the RTOS know that an interrupt routine is running. After the call to that function, the RTOS knows that an interrupt routine is in progress, and when the interrupt routine writes to the mailbox the RTOS always returns to the interrupt routine, no matter what task is ready, as in the figure. When the interrupt routine is over, it jumps to or calls some other function in RTOS, which calls the scheduler to figure out what task should now get the microprocessor. Essentially, this procedure disables the scheduler for the duration of the interrupt routine.

What is C/OS-II?
C/OS-II is a portable, ROMable, scalable, preemptive, real-time deterministic multitasking kernel for microprocessors, microcontrollers and DSPs.

What does it do?

Offering unprecedented ease-of-use, C/OS-II is delivered with complete 100% ANSI C source code and in-depth documentation. C/OS-II runs on the largest number of processor architectures, with ports available for download from the Micrium Web site. C/OS-II manages up to 250 application tasks. C/OS-II includes: semaphores; event flags; mutual-exclusion semaphores that eliminate unbounded priority inversions; message mailboxes and queues; task, time and timer management; and fixed sized memory block management. C/OS-IIs footprint can be scaled (between 5 Kbytes to 24 Kbytes) to only contain the features required for a specific application. The execution time for most services provided by C/OS-II is both constant and deterministic; execution times do not depend on the number of tasks running in the application. A validation suite provides all documentation necessary to support the use of C/OS-II in safetycritical systems. Specifically, C/OS-II is currently implemented in a wide array of high level of safety-critical devices, including:

Those certified for Avionics DO-178B Medical FDA pre-market notification (510(k)) and pre-market approval (PMA) devices SIL3/SIL4 IEC for transportation and nuclear systems, 99% compliant with the Motor Industry Software Reliability Association (MISRA-C:1998) C Coding Standards

Applications
C/OS-II is used in a wide variety of industries:

Avionics used in the Mars Curiosity Rover! Medical Equipment/Devices Data Communications Equipment White Goods (Appliances) Mobile Phones, PDAs, MIDs Industrial Controls Consumer Electronics Automotive A wide range of other safety critical embedded applications

Features
The features of C/OS-II include:

Preemptive multitasking real-time kernel with optional round robin scheduling Delivered with complete, clean, consistent, 100% ANSI C source code with in-depth documentation. Mutual exclusion semaphores with built-in priority ceiling protocol to prevent priority inversions Timeouts on pend calls to prevent deadlocks Up to 254 application tasks (1 task per priority level), and unlimited number of kernel objects Highly scalable (6K to 24K bytes code space, 1K+ bytes data space) Very Low Interrupt Disable Time Third party certifiable

Multi-threaded applications
C/OS-II allows developers to produce multi-threaded applications, vital to the development of safety-critical systems. Thanks to improved integration with IAR Embedded Workbench for ARM, developers can access all the inherent non-reentrant features of C/C++ in a thread-safe manner. Application developers who write code for use in multi-threaded environments will find the support critical when protecting shared objects using system locks, file-stream locks, and thread-local storage (TLS) in multi-threaded environments.

Micrium and IAR collaborated in providing the first thread-safe support in C/OS-II for the IAR DLIB run-time library. Protection for such non-reentrant functions as strtok(), rand(), errno() and more are local to each thread. Global and static variables typically used by these functions are protected by the Micrium kernel.

Who should use ucosII

Developers who want to save time on their current and next embedded system project, and who want the cleanest, most popular, and robust RTOS on the market.

Debugging embedded systems

Embedded systems are designed to accomplish a very specific task or group of tasks. Although no single set of constraints will factor in all embedded systems, it is likely that the designer must balance constraints such as robustness, small size and weight, real-time requirements, long life cycle, low price, and low (or no) tolerance for malfunctions. According to Robert Cravotta, Technical Editor EDN, in his article Shedding light on embedded debugging, 9/4/2008 For each year of Embedded Systems Designs annual market survey of embedded-system developers, the single most requested area of improvement for design activities is debugging tools. The percentage of respondents making this request has remained steady at around 32% throughout the three years of the survey. There are many reasons why debugging is seen as the most problematic and costly issue of the development cycle including increasing complexity, the balance of often conflicting constraints, increased inaccessibility to silicon, lack of bug reproducibility and more pressure to meet shorter development schedule cycles. The trends in the industry that these reasons will continue to intensify and so new approaches to debugging are required. In this paper we put forward some suggestions that have been found to assist. The underlying principle is simple use all available tools, low level and high level, to isolate and identify the core issue. Our suggestions are: 1. Use both high and low level debugging tools 2. Have built-in unit testing in your code 3. Make sure that your code can also run on a desktop 4. Have integrated debugging architecture in your code 5. Use memory management tools 6. Use profilers and code coverage tools 7. Use and re-use proven and well-tested software components

MicroC/OS-II Company / developer Programmed in OS family Micrium

ANSI C Real-time operating systems

Working state Production/Stable Source model Source available Latest stable release Marketing target Supported platforms Kernel type Default user interface License Official website OS-III

Embedded devices ARM Cortex-M3, ARM Cortex-M4F, ARM ARM7TDMI, Atmel AVR Microkernel C/GUI Commercial, free for College and Universities micrium.com/page/products/rtos

MicroC/OS-II (commonly termed C/OS-II or uC/OS-II), is the acronym for MicroController Operating Systems Version 2. It is a priority-based pre-emptive real-time multitasking operating system kernel for microprocessors, written mainly in the C programming language. It is intended for use in embedded systems. Its features are:

It is a very small real-time kernel. Memory footprint is about 20KB for a fully functional kernel. Source code is written mostly in ANSI C.

Highly portable, ROMable, very scalable, preemptive real-time, deterministic, multitasking kernel. It can manage up to 64 tasks (56 user tasks available). It has connectivity with C/GUI and C/FS (GUI and File Systems for C/OS II). It is ported to more than 100 microprocessors and microcontrollers. It is simple to use and simple to implement but very effective compared to the price/performance ratio. It supports all type of processors from 8-bit to 64-bit.

MicroC/OS-II is the second generation of a kernel originally published (with source code) in a two-part 1992 article in Embedded Systems Programming magazine and the book C/OS The Real-Time Kernel by Jean J. Labrosse (ISBN 0-87930-444-8). The author intended at first to simply describe the internals of a portable operating system he had developed for his own use, but later developed the OS as a commercial product. C/OS-II is currently maintained by Micrium Inc. and can be licensed per product or per product line. Use of the operating system is free for educational non-commercial use. Additionally, Micrium provides other middleware software products such as C/CAN, C/FL, C/FS, C/GUI, C/Modbus, C/TCP-IP, C/USB and a large assortment of C/TCP-IP applications such as client software for DHCP, POP3, SNTP, FTP, TFTP, DNS, SMTP, and TTCP. Server software includes HTTP, FTP, and TFTP. PPP is also available. On March 24, 2009, Micrium released an enhanced product, C/OS-III, with licensed source code available for US$9,995 per end-product.[1] C/OS-III features unlimited number of tasks and priorities, and round robin scheduling.

Contents

1 Task states 2 Task Management (Services) 3 Task Feature 4 Task Creation and Management 5 Memory Management 6 Time Management 7 Inter-Task Communication 8 Writing Applications Under C/OS 9 Ports 10 See also 11 References 12 External links

Task states
C/OS-II is a multitasking operating system. Each task is an infinite loop and can be in any one of the following five states:

Dormant Ready Running Waiting Interrupt service routine

Task Management (Services)

Task Feature Task Creation Task Stack & Stack Checking Task Deletion Change a Tasks Priority Suspend and Resume a Task Get Information about a Task

Task Feature
C/OS-II can manage up to 64 tasks. The four highest priority tasks and the four lowest priority tasks are reserved for its own use. This leaves 56 tasks for applications. The lower the value of the priority, the higher the priority of the task. (Something on the lines of Rate Monotonic Scheduling). The task priority number also serves as the task identifier.

Task Creation and Management

There are two functions for creating a task: OSTaskCreate() & OSTaskCreateExt(). After the task is created, the task has to get a stack in which it will store its data. The stack must consist of contiguous memory locations. It is necessary to determine how much stack space a task actually uses. Deleting a task means the task will be returned to its dormant state and does not mean that the code for the task will be deleted. The calling task can delete itself. If another task tries to delete the current task, the resources are not freed and thus are lost. So the task has to delete itself after it uses its resources. Priority of the calling task or another task can be changed at run time. A task can suspend itself or another task, a suspended task can resume itself. A task can obtain information about itself or other tasks. This information can be used to know what the task is doing at a particular time.

Memory Management
Each memory partition consists of several fixed-sized memory blocks. A task obtains memory blocks from the memory partition. A task must create a memory partition before it can be used. Allocation and de-allocation of these fixed-sized memory blocks is done in constant time and is deterministic. Multiple memory partitions can exist, so a task can obtain memory blocks of different sizes. A specific memory block should be returned to its memory partition from which it came. The services of Memory management includes:

Initializing the Memory Manager. Creating a Memory Partition. Obtaining Status of a Memory Partition. Obtaining a Memory Block. Returning a Memory Block. Waiting for Memory Blocks from a Memory Partition.

Time Management
A clock tick is a periodic time source to keep track of time delays and time outs. Here, tick intervals varies from 10 ~ 100 ms. The faster the tick rate, the higher the overhead imposed on the system. Whenever a clock tick occurs C/OS-II increments a 32- bit counter, the counter starts at zero, and rolls over to 4,294,967,295 (2^32-1) ticks. A task can be delayed and a delayed task can also be resumed. It involves five services that includes: OSTimeDLY(), OSTimeDLYHMSM(), OSTimeDlyResume(), OSTimeGet(), OSTimeSet().

Inter-Task Communication
Inter-task or inter process communication in C/OS takes place using: Semaphores, Message mailbox, Message queues, Tasks and Interrupt service routines (ISR). They can interact with each other through an ECB (event control block).

Fixed-priority pre-emptive scheduling

Fixed-priority pre-emptive scheduling is a scheduling system commonly used in realtime systems. With fixed priority pre-emptive scheduling, the scheduler ensures that at any given time, the processor executes the highest priority task of all those tasks that are currently ready to execute.The pre-emptive scheduler has a clock interrupt task that can provide the scheduler with options to switch after the task has had a given period to executethe time slice. This scheduling system has the advantage of making sure no task hogs the processor for any time longer than the time slice. However, this scheduling scheme is vulnerable to process or thread lockout: since priority is given to higher-priority tasks, the lower-priority tasks could wait an indefinite amount of time. One common method of arbitrating this situation is aging, which gradually increments the priority of waiting processes and threads, ensuring that they will all eventually execute. Most Real-time operating systems (RTOSs) have pre-emptive schedulers. Also turning off time slicing effectively gives you the non-pre-emptive RTOS.Pre-emptive scheduling is often differentiated with cooperative scheduling, in which a task can run continuously from start to end without being preempted by other tasks. To have a task switch, the task must explicitly call the scheduler. Cooperative scheduling is used in a few RTOS such as Salvo or TinyOS.

Semaphore Binary Mutex

A Mutex controls access to a single shared resource. It provides operations to acquire() access to that resource and release() it when done. A Semaphore controls access to a shared pool of resources. It provides operations to Wait() until one of the resources in the pool becomes available, and Signal() when it is given back to the pool. When number of resources a Semaphore protects is greater than 1, it is called a Counting Semaphore. When it controls one resource, it is called a Boolean Semaphore. A boolean semaphore is equivalent to a mutex. Thus a Semaphore is a higher level abstraction than Mutex. A Mutex can be implemented using a Semaphore but not the other way around. Following are the differences i) Scope The scope of mutex is within a process address space which has created it and is used for synchronization of threads. Whereas semaphore can be used across process space and hence it can be used for interprocess synchronization. ii) Mutex is lightweight and faster than semaphore. Futex is even faster. iii) Mutex can be acquired by same thread successfully multiple times with condition that it should release it same number of times. Other thread trying to acquire will block. Whereas in case of semaphore if same process tries to acquire it again it blocks as it can be acquired only once.