OS for Embedded Systems

OS for Embedded Systems

Introduction to Embedded Systems
What is an Embedded OS? An "embedded system" is any computer system or computing device that performs a dedicated function or is designed for use with a specific embedded software application. Embedded systems may use a ROM-based operating system or they may use a disk- based system, like a PC. But an embedded system is not usable as a commercially viable substitute for general purpose computers or devices. Introduction to Embedded Systems

What makes a good Embedded OS?
Modular Scalable Configurable Small footprint CPU support Device drivers etc, etc, etc... Introduction to Embedded Systems

What is Real Time? “A real time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.” - Donald Gillies “Real time in operating systems: The ability of the operating system to provide a required level of service in a bounded response time.” - POSIX Standard Introduction to Embedded Systems

What makes a good RTOS? Multi-threaded and pre-emptible Thread priority has to exist because no deadline driven OS exists Must support predictable thread synchronization mechanisms A system of priority inheritance must exist Introduction to Embedded Systems

Why use an RTOS?* An RTOS enables a design team to create a complex system that responds to every event with the right action at the right time, every time. Provides mechanisms to precisely synchronize a large number of tasks Reliable An RTOS provides mechanisms to handle faults, bugs, and other unexpected events that inevitably affect any system of embedded software When the level of complexity of an embedded system is such that partitioning the software into smaller, independently executing modules significantly lowers the overall design complexity and leads to greater system reliability Time-to-market pressure balances cost of the RTOS * Mal Raddalgoda, QNX Software Systems, Ltd Introduction to Embedded Systems

Pre-emptive schedule General purpose operating systems are very democratic Every task or process has equal access to the CPU Scheduling decisions are based upon time sharing Tasks get to execute without interruption until their time slice is up Problem: If a less important task is running and a more important, deadline dependent task is pending, then the higher priority task must wait its turn RTOSes are different! Pre-emptive scheduling allows the higher priority task to take over the CPU from lower priority tasks Extends from application level code to drivers and interrupts Introduction to Embedded Systems

Predictability RTOSes must provide the designers with predictable performance data for system latencies Need to know best case and worst case scenarios for Task switching times Elapsed time from the completion of the last instruction of the prior task to the beginning of execution of the first task of the replacement process Measure of the overhead caused by the RTOS Interrupt handling Elapsed time from the arrival of the interrupt signal to the beginning of execution of the first instruction of the interrupt handler Worst case timing for a lower priority interrupt must take into account the time required to process all higher priority interrupts Introduction to Embedded Systems

Selecting an RTOS - economic factors
Generally, we view RTOSes as intellectual property Pay a royalty to RTOS vendor for each copy of the RTOS that you deliver in your application ( annuity ) Example: WinCE royalty ~$15 per copy volumes > 10000 Cost of tools Some RTOS vendors supply complete development and debug environments for their customers One-stop shopping Products are well-integrated and work together Board support packages (BSP) Integrating an RTOS with your hardware platform ( target system ) is a non-trivial exercise Requires expert knowledge of the O/S and hardware Is there an existing BSP for your hardware? Pay the O/S vendor to do it? ( $50K - $1M ) Introduction to Embedded Systems

Selecting an RTOS - CPU issues
Has an RTOS been written and fine-tuned to your CPU choice? Take advantage of specialized performance hardware on CPU? Example: May contain shadow registers for rapid task switching May contain special registers for storing task tables context switching. Key kernel functions written in assembly language for maximum performance Has performance of RTOS been fully characterized with your CPU? Does the RTOS support the peripheral register set on your microcontroller? Example: PowerPC 860 contains 200 registers for peripheral devices ( timers, ethernet ports, other O/S relevant I/O devices) require support Support for virtual and protected memory management? Introduction to Embedded Systems

Selecting an RTOS - Application support
How many simultaneous tasks can the RTOS support? How many interrupts can be supported? Does RTOS vendor provide support services for specialized applications? FAA and FDA certification of O/S for mission critical applications Protocol stacks for telecomm and datacomm ( TCP/IP ) Architecture of RTOS Flat memory model Applications and RTOS are built and linked as a single executable Entire address space of processor is available to O/S and all applications Generally fast, but very suceptible to crashes due to buggy code Errant pointers can overwrite critical kernel code Introduction to Embedded Systems

Selecting an RTOS - Application support-2
Microkernel architecture ( QNX ) Designed to support processors with on chip MMU’s Pentium, 386, 486, PowerPC, Keeps a small portion of the RTOS, microkernel, in non-protected memory All other O/S services and applications are handled as tasks in protected memory Managed through the MMU ( See next slide ) Since each task is now isolated in its own protected memory space, errant pointers cannot crash the O/S Can write exception handlers to deal with buggy software Software executables can be built as a separate application programs, simplifying software development May be slower due to overhead of transferring from protected mode to microkernel services Introduction to Embedded Systems

Task management with MMU
Logical address space Segmented MMU Physical address space Introduction to Embedded Systems

Microkernel RTOS A microkernel RTOS implements a small set of core services within the kernel itself Additional system services are provided through add-on processes. Every driver, protocol, I/O manager, file system, graphics systems and GUI run in there own memory-protected address space Task switch takes 1.95 uSEC on a 133 MHz Pentium CPU Source: QNX Introduction to Embedded Systems

WindRiver Products VxWorks AE OS Consulting Professional Services
Doctor Design Systems Hardware Reference Boards Vision Click Probe Vision ICE Probe SUPPORT Software Development Tools Tornado Tools Prism Tools Hardware Software Int. Tools RealTime Software VxWorks OS VxWorks AE OS pSOS OS BSPs and Device Drivers Networks stacks & Protocols This slide would look good as five interlocking puzzle pieces. I bet somebody in corporate as one of these Animate with each square flying in. “purpose of this presentation is to focus on AE” Introduction to Embedded Systems

Why use an RTOS in the first place?
Application isolation Overrun protection Managing shared resources Memory management Predictability Reliability Introduction to Embedded Systems

Application Isolation
Why use a Real Time Operating System? Answer: application isolation Why Isolate? easier integration/debugging protection of critical applications decoupled design of apps Elements of Isolation Code/Data Corruption Exception Processing Heap Heap App 1 App 2 Q1 Q2 App Sem 1 Task 2 App App Task 1 Task 3 Code/Data Corruption:Applications cannot corrupt other applications or the underlying OS. Exception Processing: Can be isolated to the application’s separate space, leaving other parts of the system unaffected. Kernel Kernel Tasks Objects Introduction to Embedded Systems

Overrun Protection Why Protect Resources stack overruns heap overruns CPU lockouts Applications are configured with limits on their memory and CPU resources Overrunning will not damage other applications Heap App 1 Q1 App Task 2 App Task 1 Reasons for overruns: coding mistake, design mistake, requirements mistake. Question: How is CPU limitations set up and how is it implemented? Answer: Each PD can have a limit on task priority. No tasks can be spawned at a higher priority. Question: What happens if a user app exceeds stack limits? Answer: Probably exception thrown and PD is suspended. Introduction to Embedded Systems

Resource Reclamation Issues Addressed avoid writing application clean up code avoid resource reclamation errors when an app completes Resources released when an application completes Heap memory Stack memory Shared Code memory (hidden) Shared Data memory (hidden) Shared Data Heap App 1 Q1 App Task 2 App Task 1 Shared Code Kernel Kernel Tasks Objects Introduction to Embedded Systems

System Calls What is a system call? We define a system call as being a call from a user mode protection domain to a kernel function How do they work? Linkage is via a linkage table in each PD to entry point An exception is generated which allows the OS to promote the task to supervisor mode Shared Data User App #1 User App #2 Link Table Shared Code Kernel Introduction to Embedded Systems

Shared Library Protection Domain
But, How do We Share Code? fooLib.o int fooVal; void fooSet(int x) { fooVal = x; } Shared Library Protection Domain Application Domain 1 Application Domain 2 fooSet (4) Task A fooVal = 4 fooSet(99) Task B fooVal = 99 If you did have global variables in a shared library module, … MMU maps SL code segment at Read Only - bullet proof Provides a user defined public API (Entry Points) to allow application domains to share common code The shared library entry points can be configured statically or dynamically when modules are loaded Application domains can link against shared libraries by providing a link path to the shared libraries Shared libraries cannot link against one another and are automatically linked against the system shared library Shared libraries may not contain tasks Placing fooLib.o in a shared library requires less memory than having a separate copy in each PD Once the application PD has attached or linked with the shared library it can call the shared library's public functions directly Introduction to Embedded Systems

VxWorks AE Overlapped Memory Model
Unmapped SD PD Reserved Shared Data Unmapped Modules SL PD Shared Library Shared Data Unmapped Reserved Modules Modules Shared Library Unmapped Modules Application 2 Application 1 Heap Application 2 Heap Modules Unmapped Application 2 Heap Unmapped Application PD1 Application PD2 Application 1 Application 1 Application 2 Modules Modules Modules This diagram represents how physical memory allocation (in the center) can be mapped to virtual application contexts from the perspective of each application protection domain. In this diagram, the Physical Memory allocation maps to several virtual application contexts for Application 1 and Application 2. Note that the physical memory map the center represented the memory model under VxWorks 5.4. When a protection domain is created it allocates just enough physical memory to run while allocating 1 Gbyte of virtual memory by default (obviously most of this allocated virtual memory space is unmapped to the physical memory). The application context for each protection domain overlaps so that the kernel, the application modules and the application heaps all run within the same virtual address. In this example, you can see how Application 1 Modules occupy the same virtual memory as the Application 2 Modules. The Shared Library and Shared Data protection domains are the exception to this rule. Each shared library and shared data protection domain resides at the same logical address in each application protection domain. If an application protection domain does not attach to a particular shared library or shared data domain then this virtual area would remain reserved. Unmapped Application 1 Heap Unmapped Kernel Kernel Kernel Kernel Kernel Application 1 Physical Memory Application 2 Context Context Introduction to Embedded Systems

Complexity Forcing Standardization
Companies can’t afford (the time or the money) to choose and integrate a new supplier and a new software platform for every new project. Introduction to Embedded Systems

Products for Every Phase of Development
Embedded Development Cycle Hardware Bringup Driver & BSP Development RTOS Integration Application Development System Integration Manufacturing and QA WindLink Partner Products UGL, PersonalJWorks, and Zinc VxWorks, VxWorks AE, pSOSystem RTA Suite, WindView, and ESP SNiFF+ Services Tornado and pRISM+ DIAB and GNU Compilers visionICE & visionPROBE emulation, visionCLICK & SingleStep Debuggers Reference Designs and Evaluation Boards visionWare visionWare visionWare Introduction to Embedded Systems

Inside an RTOS Development Environment
Wind River Systems’ Tornado Introduction to Embedded Systems

Tornado II Architecture
Host: PC or UNIX Target VxWorks 5.4 Scalable Run-time Standard Tornado Tools WindView ScopePak, PerformancePak LOOK! WFCs CodeTEST Diab Compiler & RTA (PPC) Launcher GUI Target Server Simulation Environment VxSim Real-time Embedded Application File Systems Embedded Internet Graphics Networking Multi-processing Memory Protection POSIX Library wind Microkernel Debug Agent BSP Tornado Plug-ins: 3rd Party Tools SNiFF+ SingleStep (PPC) Tornado is a complete software development platform for real-time embedded applications. Available for both UNIX and Windows-based hosts, Tornado is comprised of three highly integrated components: Tornado Tools, a set of powerful cross-development tools and utilities; the VxWorks run-time system, a high performance scalable real-time operating system; and a full range of communications options for the target connection to the host. Tornado II’s open architecture and industry standards support make it easy for developers to design efficient multi-vendor systems and migrate to different processors with minimal effort. The Tornado WindPower Tools are available in addition to the core Tornado development tools. The WindPower Tools are the latest generation dynamic visualization tools providing powerful insight of the embedded system. They provide a major advance in productivity for developers of realtime embedded applications. Each of these tools are designed to address the increasing complexity of application development, and together they represent a quantum leap in accelerating the development cycle. Through WindView, the user can quickly and easily visualize the complex interaction between tasks, ISRs, and system objects in the application under development VxSim, a complete prototyping and simulation tool Tornado and VxWorks applications. VxSim enables application development, including network and multi-processor based designs, to begin before hardware becomes available. StethoScope, a real-time data visualization, profiling, and debugging tool that lets the user examine and analyze a Tornado or VxWorks application while it’s running CodeTEST for Tornado is an easy-to-use, cost-effective solution for tracing embedded programs, verifying test coverage, and dynamic memory allocation, as they run in the target system Introduction to Embedded Systems

Cross-Development Typical scenario: 1. Boot target. 4. Download object module. 2. Attach target server. 5. Test & Debug. 3. Edit & compile. 6. Return to 3 or 1 as necessary! Ethernet RS-232 Development Host VxWorks Target The above slide illustrates a common setup for cross-development. Other configurations are possible: - The target could be remote from the host. - The target might not have a serial connection; or might have only a serial connection, not an ethernet connection. - A ROM emulator such as NetROM, or an ICE, might be used as the communication link. In the configuration pictured above, the target would (during development) obtain its VxWorks image across the network connection when it boots. Code is edited, compiled, version-managed, etc., on the development host. Individual object modules may be downloaded from the development host to the target, and dynamically linked into the VxWorks image and other code already present on the target. Using Tornado tools such as the CrossWind debugger and WindSh shell, the developer may test and debug the downloaded modules. Diagnostic output might go across the serial connection. The communication of the tools with the target, as well as the downloading of code, is mediated by the Target Server on the host, and the WDB agent on the target. The backend communication between these two would usually make use of the ethernet, for speed; for system mode debugging, a serial backend would be used. Introduction to Embedded Systems

Developer’s Work Bench
Host Win, Linux, Solaris Target ARM, MIPS, Pentium, PPC Virtual BDM/JTAG Connections Serial Ethernet Run-Time Components Board Support Package VxWorks AE Networking Stacks Other Components Your Application Host-Based Tools Tornado Tools 3 Compilers Debuggers Code Browsers Project Manager OS Configuration Analysis Tools Simulators Hardware Debug Tools Target Ref Boards BDM/JTAG Debuggers This slide is used to point out that the environment that an embedded development team uses to successfully create and deploy a new system. The environment includes virtual targets such as VxSIM, simple serial connections, Ethernet as well as hardware assist tools. The key point is here that ONLY Wind River is in the unique position to deliver all aspects of the designers workbench, from the virtual target to the evaluation board, with Ethernet connections and the hardware tools to support the emulation needs. Only Wind River can provide complete, end-to-end software & hardware development solutions! Introduction to Embedded Systems

Target Server / WDB Agent
Development Host Target Target Server WindSh WTX Protocol VxWorks CrossWind WDB Protocol WDB (Ethernet, serial, netrom, custom) Browser Application For the Tornado tools to communicate with a target, a Target Server for that target must be started (after the target boots). Tools talk to the Target Server, not directly to the target. The Target Server manages the backend communication with the target. The tools and target server may run on different hosts. The Target Server and WDB agent together provide services to the Tornado tools: - Dynamic code downloading - Reading/Writing target memory or registers - Allocating target memory for tools - Setting/Clearing breakpoints - Spawning/Deleting/Suspending/Resuming/Stepping tasks - Calling functions - Collecting information on VxWorks system objects - Maintaining table of target symbols (function & variable names) - Virtual I/O channels The WTX and WDB protocols are described in detail in the Tornado API Guide. 3rd Party WTX = Wind River Tool eXchange WDB = Wind DeBug Introduction to Embedded Systems

VxWorks RTOS Scheduling & System Clock Facilities Synchronization & Intertask Communication Mutual Exclusion I/O system File Systems Memory Management Networking Support Device Support . . . The VxWorks operating system consists of a small kernel (which controls the execution of tasks) and surrounding facilities provided for application use. Many surrounding facilities (and some parts of the kernel) may be scaled out of the VxWorks image if the application does not need them. Some facilities (e.g. networking) may be useful during development even if they are not needed in the final product; it is easy to remove such facilities from the shipping image. Introduction to Embedded Systems

Board Support Package Most of VxWorks is independent of the particular target board used. The board-specific code for initializing and managing a board’s hardware is called the BSP. The BSP provides VxWorks with standard hardware interface functions which allow it to run on a board. The primary BSP source file, sysLib.c, lives in the BSP directory target\config\bspName. This is also the directory in which VxWorks may be reconfigured and rebuilt. Each BSP directory contains a file target.txt describing the target board: what hardware devices are supported, jumper settings, and other board-specific hardware setup information. Also contained in the BSP directory are the files config.h BSP configuration file. bspName.h Non-configurable BSP constants. Makefile Makefile for building VxWorks and boot ROM images. romInit.s Assembly code; first code executed on power-on. sysALib.s Assembly code; first code executed in downloaded VxWorks images. vxWorks… VxWorks images. bootrom… Boot ROM images. The Makefile includes make definitions and rules from the target\h\make directory. See the Cross-Development chapter of the Tornado User’s Guide for more information on VxWorks makefiles & variables. The sysLib.c file includes other source files from the BSP directory, as well as from the generic driver directories under target\src\drv. Introduction to Embedded Systems

VxWorks VxWorks is a multitasking operating system optimized for real-time and embedded applications. Low interrupt and context switch latency. Low “system call” overhead. Scalable. Portable: well defined BSP. VxWorks consists of core kernel facilities and peripheral facilities which depend on the kernel. Loosely, kernel functions are those which can directly change the states of tasks. Consider printf( ). This is not a "kernel function." However, printf( ) calls the write( ) function (not a kernel function either), and the VxWorks I/O system routes this call to the appropriate driver write routine. The driver write routine may make kernel calls such as semTake( ), which could directly block the executing task. Thus printf( ) could cause tasks to change state, but not directly. Kernel calls in VxWorks are ordinary function calls executed in the context of the task which makes the call. They are not implemented with traps. Introduction to Embedded Systems

What is a VxWorks Task? A task is a context of execution. It has: a program counter (current location of execution). private copies of CPU registers. a stack for local variables, function arguments, and function call chain information. As VxWorks is a uniprocessor system, only one task is actually executing at any given time. When a task is not executing, its context is stored in its Task Control Block (TCB) and stack. The TCB is the data structure which the kernel uses to represent and control the task. Do not confuse a task with the code the task executes. It is quite possible to have more than one task executing the same (hopefully, reentrant) code. Moreover, code is first downloaded to the target, and later tasks are spawned to execute functions within the downloaded code modules. Code is static, while a task is an active virtual processor executing code. Introduction to Embedded Systems

Performance Optimizations
All tasks execute in the same address space: All tasks execute at highest CPU privilege level. static int x; void fooSet (int arg) { x = arg; } text data bss RAM fooLib.c tTaskA fooSet(4) tTaskB fooSet(99) A module such as fooLib.o loads into target memory as three segments: text The executable machine code of the module. data Initialized data of the module. bss Uninitialized data, zeroed when the module is loaded. The core VxWorks product does not implement virtual memory. VxWorks might be compared to a single process with multiple threads (tasks). tTaskA and tTaskB above each make calls to fooSet(). Each call modifies the same physical memory location for variable x in the bss of fooLib.o. The two tasks do not each have their own private copies of the data and bss segments, as they would if they were separate processes in a process model system. Advantages & disadvantages of a common address space: + Context switches are faster, since virtual memory does not have to be remapped. + Intertask communication is faster and easier. - A buggy or malicious task can corrupt other tasks or the OS. As all VxWorks tasks run in supervisor mode, “system calls” can be ordinary function calls executing in the context of the calling task, rather than protection-boundary crossing traps. This makes such kernel calls much faster. Introduction to Embedded Systems

Task State Transition Diagram
PENDED DELAYED SUSPENDED PENDED & DELAYED & READY EXEC. A task in the ready state is either executing, or waiting for the CPU. An executing task may move into the delayed state by calling taskDelay( ). The argument to the call is a number of system clock ticks; after that many ticks have passed, the task is moved back into the ready state (but might not execute immediately, if there is a higher priority ready task). The executing task may move to the pended state by making a kernel call that involves waiting for an event. For instance, semTake( ) may wait for a semaphore to become available; msgQReceive( ) may wait for a message to arrive across a message queue, and so on. When the event occurs (or a time-out specified in the call expires), the task returns immediately to the ready queue. A task may be suspended by the taskSuspend( ) call; the executing task is also suspended if it causes an exception, or hits a breakpoint. A task which was in the pended state becomes pended and suspended when taskSuspend( ) is called on it; when resumed with taskResume( ), it returns to the pended state. A similar statement applies to tasks in the delayed state. However, there is another possibility: while a task is pended and suspended, the event for which it was waiting may occur; in this case the task becomes merely suspended. As an example, a task pended and suspended in a semTake( ) call may become the owner of a mutex semaphore while still suspended. When resumed, this task moves into the ready state. Introduction to Embedded Systems

Preemptive Priority Scheduling
At any time, the highest priority task ready to run, runs! A higher priority task which is made ready preempts the executing task. Interrupts preempt any task. VxWorks uses preemptive priority-based scheduling. Each task has a priority from 0 (highest) to 255 (lowest). The CPU is given to the highest priority task which is in the ready state. An even higher priority task which becomes ready to run preempts the currently executing task immediately. Equal priority tasks do not preempt each other. Exceptions: The executing task may lock out preemption, or interrupts, during critical work. Time slicing may be enabled among equal priority tasks. Consequences: A high priority task should finish its immediate work as quickly as possible, then block waiting for the next time it becomes ready to run. If there is not enough CPU time to handle all the high priority tasks (and interrupt service routines), the lower priority tasks may starve. For more discussion, see the VxWorks Programmer’s Guide, section 2.3. Notes: On this board, INT 6 is the system clock, INT 3 is the network interrupt. Introduction to Embedded Systems

Context Switches When one task stops executing and another task starts, a context switch has occurred. Context switches occur: If a higher priority task becomes ready to run made ready by executing task. made ready in an interrupt, or times out on a blocking call. If the executing task makes a blocking kernel call (moving into a pended, delayed, or suspended state). What happens: CPU registers for outgoing task stored in its TCB. CPU registers for incoming task retrieved from its TCB. (Recall that TCB stands for Task Control Block, a data structure which the kernel uses to represent a task. This structure is declared as WIND_TCB in target/h/taskLib.h. For the most part, user applications do not access the structure directly.) Besides just the CPU registers and task stack, tasks can have additional context. For instance, the global variable errno (used for error reporting) is treated as part of the task context; it is saved and restored in the TCB on context switches, just like a register. Some tasks may define additional task variables which are saved and restored as they switch out of and into context. Task specific breakpoints are inserted into and removed from memory on context switches. Finally, task switch hooks may be used to swap additional context information on reschedules, such as virtual memory contexts when the VxVMI product is used. For information on errno, see section of the VxWorks Programmer’s Guide, and errnoLib in the Reference Manual. For information on task variables, see section in the Programmer’s Guide and taskVarLib in the Reference Manual. See the taskHookLib entry of the Reference Manual for information on task create, switch, and delete hooks. Introduction to Embedded Systems

Interrupt Service Routines
An ISR is a piece of code which is connected to a particular hardware interrupt. When the hardware interrupt occurs, the ISR runs. ISR’s have an effective priority higher than any task. Whether and how ISRs can preempt each other is board dependent. An ISR has no permanent context; it is NOT a task. An ISR may call only a limited set of VxWorks functions. Basic rule of thumb: If a routine could block, an ISR cannot call it. For a list of the VxWorks routines which may be called from ISRs, see table 2-23 in the VxWorks Programmer's Guide. On many processors, ISRs share a stack separate from any task stack. This interrupt stack must be large enough for the worst-case nesting of interrupts. On some processors, however, ISRs execute on the stack of whatever task was running when the interrupt occurred. In this case, additional space for servicing interrupts is needed on all task stacks. See the appendix of the VxWorks Programmer's Guide for your architecture, for a discussion of architecture-specific interrupt handling issues. Interrupt Service Routines may be connected with the intConnect() call. As a means of mutual exclusion involving ISRs, interrupts may be locked out using the intLock() call, and reenabled with intUnlock(). (Of course, if you must lock out interrupts, do so for the minimal amount of time necessary!) For more information about ISRs, see The VxWorks Programmer’s Guide, section 2.5. The VxWorks Programmer's Guide appendix for your architecture. The VxWorks Reference Manual entries for intArchLib and intLib, and sysLib. BSP source code (for the ambitious). Introduction to Embedded Systems

Semaphores Semaphores are VxWorks kernel objects which allow blocking and unblocking of tasks, to coordinate tasks’ actions with those of other tasks and with external events. VxWorks provides three varieties of semaphores: Binary (synchronization) semaphores. Counting semaphores. Mutex (mutual exclusion) semaphores. Each type of semaphore is intended primarily for a particular kind of programming problem. See the VxWorks Programmer’s Guide, section 2.4, for information on semaphores (and other intertask communication facilities). Also see the VxWorks Reference Manual entries for: semLib general semaphore library. semBLib binary semaphores. semCLib counting semaphores. semMLib mutex semaphores. semPxLib POSIX b semaphores. semSmLib shared memory semaphores (VxMP optional product). After creating a semaphore of a particular type, the primary calls used for all semaphores are STATUS semTake (SEM_ID semId, int timeout) and STATUS semGive (SEM_ID semId) There are some differences in how these calls are used and how they act for the different types of semaphores. Introduction to Embedded Systems

Binary Semaphores Binary semaphores allow tasks to wait for an event without taking up CPU time polling. The event might be an interrupt, or the action of another task. Usage: Create the binary semaphore using semBCreate() A task which wishes to wait for the event calls semBTake() to block until the event occurs (or a specified time-out expires). Whichever ISR or task detects or creates the event calls semBGive() to allow a waiting task to proceed. If semGive(semId) is called when there are tasks waiting for the semaphore, only the first task on the semaphore's pend queue is unblocked (made ready). The semaphore is left unavailable. If semGive(semId) is called and no task is waiting for the semaphore, then the semaphore is made available. If it was already available, this is a no-op. If semFlush(semId) is called, all tasks waiting for the semaphore are made ready to run. The semaphore's state is unchanged. If a task calls semTake (semId, timeout), then if semId is available, semTake() returns OK immediately. The task does not block. The semaphore is atomically made unavailable. if semId is unavailable, the task pends until either Some other task or ISR calls semFlush (semId), unblocking all tasks waiting for this semaphore, or calls semGive (semId) when the task has worked its way to the front of the semaphore's pend queue. In either case, the task is moved into the ready state, and its semTake() call returns OK. The semaphore remains unavailable. The number of system clock ticks specified in timeout expire. In this case the task is made ready and its semTake() call will return ERROR. For more information, see the Reference Manual entry for semBLib, and the discussion of binary semaphores in section of the Programmer’s Guide. Introduction to Embedded Systems

Mutex Semaphores Mutex semaphores are used when multiple tasks share a resource (data structure, file, hardware). When used correctly, mutex semaphores prevent multiple tasks from accessing the resource at the same time, and so corrupting it. Usage: Create mutex for the resource with semMCreate(). A task wanting to use the resource first calls semMTake() to block until the resource is available (or time-out expires). When done with the resource, a task calls semMGive() to allow other tasks to use the resource. While binary or counting semaphores may be used for mutual exclusion, mutex semaphores are designed to deal with three common problems which arise in mutual exclusion: Mutual exclusion semaphores may be taken in a nested fashion. A task which owns a mutex may take it again without blocking. The task must give back the mutex as many times as it has taken it before losing ownership. If a task tA owns a delete-safe mutex semaphore, and another task tB tries to delete tA, then tB will block until tA gives up ownership of the mutex. Thus the mutex owner is safe from deletion while operating on the shared resource. Inversion-safe mutexes prevent the so-called priority inversion problem. A task which owns such a mutex is temporarily boosted to the priority of the highest priority task waiting for the mutex. It falls back to its regular priority when it no longer owns an inversion-safe mutex. This prevents a high priority task from being blocked for an indeterminate amount of time waiting for a mutex owned by a low priority task which cannot execute because it has been preempted by an intermediate priority task! See the Reference Manual entry for semMLib, and the discussion of mutual exclusion semaphores in section of the Programmer’s Guide. Introduction to Embedded Systems

Counting Semaphores Binary semaphores keep track of whether or not an event has occurred, but not how many times the event has occurred (since the last time the event was serviced). Counting semaphores keep a count of how many times the event has occurred, but not been serviced. May be used to ensure that the event is serviced as many times as it occurs. May also be used to maintain an atomic count of multiple equivalent available resources. If a counting semaphore is given while no task is waiting for it, its count is incremented. On the other hand, if there is at least one task waiting for the semaphore when it is given, then the task at the head of the semaphore's pend queue is made ready to run, and the semaphore's count remains zero. If a task takes a counting semaphore whose count is greater than zero, the task's semTake() call returns OK without blocking, and the semaphore's count is decremented. If the count is zero when the semaphore is taken, then the semTake() call blocks. See the Reference Manual entry for semCLib, and the discussion of counting semaphores in section of the Programmer’s Guide. Introduction to Embedded Systems

Message Queues FIFO buffers of bounded length messages. Synchronization and mutual exclusion built in. A task pends reading from empty queue, or writing to full queue. A time-out may be specified. Four Score and seven tProducer msgQSend (…) tConsumer msgQReceive(...) The above picture shows a single writer and a single reader of the message queue. Multiple reader and writer tasks are allowed. When creating the message queue, one specifies whether tasks waiting to read from an empty queue, or write to a full queue, wait in FIFO or priority order. Interrupt service routines may do a NO_WAIT (time-out = 0) write to a message queue, but may not read from a message queue. So-called urgent messages may be sent; these are written to the head of the queue rather than to the tail. Data is copied from user buffers to internal message queue buffers (or vice versa) on each msgQSend() or msgQReceive() call. If your application needs to pass large messages you might consider sending pointers to the messages rather than the messages themselves. This method improves performance, but requires care as to who owns the message buffer. One technique is to use a second message queue to return ownership of the buffer to the sender (or to a common buffer pool). VxWorks pipes are similar to message queues, but are accessed via the standard I/O system routines open(), close(), read(), write(), and ioctl(). Section of the Programmer's Guide describes the use of message queues. See also msgQLib in the Reference Manual. Introduction to Embedded Systems

Watchdogs Watchdogs allow a routine to run after a specified delay, as part of the system clock tick ISR. Used for high-reliability periodic polling, and deadline-miss detection. Periodic Execution wwd = wdCreate(); wdStart (wd, period, myWdISR, arg); ... void myWdISR (int param) { wdStart (wd, period, myWdISR, param); doIt (param); } Deadline-miss Recovery wd = wdCreate(); FOREVER { wdStart (wd, deadline, panicWd, arg); doWork(); } ... void panicWd (int param) { /* Handle deadline miss */ } VxWorks watchdogs are a software interface to the system clock. They are not separate hardware timers. The second argument to wdStart (period or deadline) is expressed in system clock ticks. In the deadline-miss recovery example, we want the doWork() function to complete execution at least once every deadline clock ticks. If it does, the watchdog is restarted, and so does not go off (only the most recent wdStart() call on a watchdog has effect). On the other hand, if ever more than deadline clock ticks pass between two calls to wdStart(), the watchdog ISR routine panicWd() runs. See the discussion of watchdog timers in section 2.6 of the VxWorks Programmer’s Guide, and the Reference manual entry for wdLib. High speed polling should be done with a separate timer such as the auxiliary clock, to avoid operating system overhead associated with the system clock. Introduction to Embedded Systems

VxWorks I/O System Provides a consistent, familiar interface to various I/O devices and file systems. Open a file/device by name with open(). Use the integer file descriptor returned from open() in later calls to read(), write(), and ioctl(). File descriptors may be shared among multiple tasks. When all tasks are done with a file descriptor, have one task call close() so that the file descriptor may be reused. Global or task-specific redirection of standard input, standard output, and standard error is possible. The VxWorks I/O system is discussed in detail in chapter 3 of the VxWorks Programmer’s Guide. Included is information valuable to driver writers who wish to fit their drivers into the I/O system. The Reference Manual pages for particular drivers and file systems should also be consulted, for instance for the ioctl() functions supported by the driver. Introduction to Embedded Systems

Additional I/O Support
VxWorks supports the Standard C buffered I/0 library (ansiStdio, header file stdio.h): fopen(), fclose(), fread(), fwrite(), getc(), putc(), etc. Built on top of VxWorks Basic I/O system. Since the basic I/O system calls reach driver level very quickly (no protection boundary crossing overhead), buffered I/O may be less important. VxWorks implements printf() in a separate library fioLib as an unbuffered call. This allows formatted output without support for buffering. C++ Iostreams library provided. See the VxWorks Reference Manual pages for the ansiStdio library for information on buffered I/O using the Standard C buffered I/O library. The Iostreams library is discussed briefly in the C++ development chapter of the VxWorks Programmer’s Guide. Generic ANSI C and C++ documentation are also of use. Introduction to Embedded Systems

Local File Systems VxWorks provides an implementation of the DOS file system, dosFsLib. Compatible with MS-DOS up to release 6.2. File system may be used with local block devices such as SCSI, ATA, or floppy disk drives; or RAM disks. To access the raw block device via the I/O system, rawFsLib may be used. The module tapeFsLib may be used to access a SCSI sequential device (tape drive). Local File Systems are the subject of chapter 4 of the VxWorks Programmer’s Guide. Additional information is available in the Reference Manual pages for the particular file system (dosFsLib, rawFsLib, rt11FsLib, tapeFsLib). A block device is capable of random-access transfers of multi-byte data blocks; in practice, a block device is usually a disk, or a logical partition on a disk. Block devices are discussed in the I/O system chapter of the Programmer’s Guide. Also see the Reference Manual entries for scsiLib, ataDrv, and nec765Fd. SCSI stands for the Small Computer System Interface, a processor-independent standard for system-level interfacing between a computer and intelligent devices including hard disks, floppy disks, CD-ROM, printers, scanners and many more. ATA stands for Advanced Technology Attachment, ANSI group X3T10's official name for the disk drive interface standard commonly known as Integrated Drive Electronics (IDE). (Definitions curtesy of the Free On-Line Dictionary Of Computing.) Introduction to Embedded Systems

VxWorks Network Support
Network interfaces: Ethernet PPP/SLIP/CSLIP Shared Memory Network (VME backplane) Custom Network Programming API’s: 4.3 BSD sockets. zbuf (Zero-copy TCP/UDP) sockets. Sun RPC. Network programming, and configuration of VxWorks network facilities, is discussed in chapter 5 of the VxWorks Programmer’s Guide. Network programming in VxWorks is very similar to network programming on other platforms, so standard references are useful. Steven’s UNIX Network Programming and TCP/IP Illustrated are particularly recommended. Information on writing network interface drivers for VxWorks is available with the Tornado BSP Developer’s Kit for VxWorks. SENS, the Scalable Enhanced Network Stack, an upgrade of VxWorks network support based on 4.4 BSD, includes support for DNS, the RIP v.1 and v.2 routing protocols, DHCP, and a new network interface layer driver architecture. SENS will be available the first quarter of 1998. Introduction to Embedded Systems

Network File Access VxWorks can act as client or server for remote file access: Client Server Client: VxWorks target accesses files on remote host via NFS, FTP or RSH. NFS nfsDrv FTP or RSH netDrv, ftpLib Server: Remote host accesses files local to VxWorks target via NFS or FTP. NFS nfsdLib, mountLib FTP ftpdLib VxWorks Remote Host Client Server NFS is the Network File System originally developed by Sun Microsystems. FTP is the File Transfer Protocol, a standard TCP/IP method for file transfer. RSH is the (UNIX) Remote SHell service for remote command execution (which can be used for file transfer, among other things). See the information on Remote File Access in section of the VxWorks Programmer’s Guide. Other application-level services provided by VxWorks: Remote Login allows rlogin or telnet connection to a VxWorks 5.2 style target-based shell; also allows rlogin from a target based shell to another networked host. Remote Command Execution provides an RSH (remote shell) client for VxWorks. A command specified by the client is executed in a shell created on a remote host which provides the RSH service (a standard UNIX service). Information on the VxWorks target shell, including information on remote login, is available in Chapter 9 of the Programmer’s Guide. VxWorks Remote Host Introduction to Embedded Systems

Software creation process
Objective: build an executable image of the source software given the constraints of an embedded system May or may not have operating system services Various code storage methods Mask ROM, EPROM, FLASH, Disk, distributed, On-chip Must account for variations in: Size of memory Boot-up procedures ROM-based or RAM-based execution Location of peripheral devices Memory mapped or I/O mapped Integrate the code modules ( files ) written by different team members Building code images from many different files MAKEFILES are a major source of burning resources Introduction to Embedded Systems

Non-volatile storage The vast majority of embedded systems do not have disk storage Code is typically held in non-volatile, solid-state memory EPROM: Electrically Programmable Read Only Memory EEPROM: Electrically Erasable Read Only Memory FLASH: Modern variant of EEPROM MASK ROM: Code is designed in at fabrication For cost-sensitive, high-volume applications ( N64 ) Code may be held in local disk memory Similar to PC’s Code may be remotely transferred from server or remote host Telecommunication systems Embedded controllers within computer systems Internet appliances Let’s look at this technology: Introduction to Embedded Systems

Other Than VxWorks? Wind River Systems pSOS QNX Software Systems QNX Green Hills Software Integrity Mentor Graphics VRTX Palm Computing PalmOS Symbian SymbianOS Embedded NT/XP “Real-time” control Windows CE (CE.NET) Internet devices Pocket PC 2002 Handheld PC’s and PDA’s Introduction to Embedded Systems

Commercial Embedded Linux
AMIRIX Embedded Linux derived from Debian Coollogic Coollinux combines Linux and Java for Internet apps Coventive Xlinux kernel can be as small as 143KB Esfia RedBlue Linux 400K, designed for wireless apps KYZO Pizza Box Linux SAMBA based file, print, CD server Lineo Embedix supports real time and high availability apps LynuxWorks BlueCat general purpose embedded solution MontaVista Linux Neoware NeoLinux Red Hat derived for information appliances PalmPalm Tynux Internet appliance and multimedia Red Hat Embedded Linux general purpose embedded solution RedSonic Red-Ice Linux runs from DiskonChip or CompactFlash RidgeRun DSP Linux for multimedia, wireless, RT on DSP TimeSys Linux GPL low latency enhanced kernel Tuxia TASTE distro targets Internet appliances Vital Systems vLinux for ARM based embedded apps Introduction to Embedded Systems

Open Source Embedded Linux
Embedded Debian Project convert Debian to an embedded OS ETLinux for PC104 SBC’s uCLinux for microprocessors that don’t have MM uLinux (muLinux) distro fits on a single floppy Introduction to Embedded Systems

Commercial Linux RTOS FSMLabs - Open RT Linux Lineo - Embedix Realtime LynuxWorks - BlueCat RT MontaVista Software - Real Time Extensions REDSonic - REDICE Linux TimeSys - Linux/Real-Time Introduction to Embedded Systems

Open Source Linux RTOS ART Linux - real time extension based on RTLinux KURT - event schedules with 10us resolution Linux-SRT - for soft real time apps like multimedia Qlinux - provides Quality of Service guarantees RTAI - “hard” Real Time Application Interface Introduction to Embedded Systems

RTLinux A “hard real-time” mini operating system runs Linux as it’s lowest priority execution thread Linux thread completely preemptible Real time threads and interrupt handlers never delayed by non-realtime operations Supports user level programming MiniRTL implementation fits on a floppy Introduction to Embedded Systems

What’s so special about Linux?
Multiple choices vs. sole source Source code freely available Robust and reliable Modular, configurable, scalable Superb support for networking and Internet No runtime licenses Large pool of skilled developers Introduction to Embedded Systems

What’s so special about Linux?
Introduction to Embedded Systems

What’s special about Open Source?

Flies in the Ointment Lack of hardware device drivers Competing and/or lacking standards No formalized qualification testing No single source for marketing GPL license issues Startup vendors with shaky futures Introduction to Embedded Systems

Projected Target CPU’s

Any Development Tools Available?
QT/Embedded Other GUI/Windowing toolkits Arcom Control Systems GNUPro Tools Vendor specific Standard Linux toolset Introduction to Embedded Systems

C or C++ for Development?
In general C is a better choice Advanced OOP features can cause code bloat C++ compilers can generate many routines for a single function Virtual methods and polymorphism slow program launch times significantly Size really does matter Introduction to Embedded Systems

What’s It Being Used For?
Control and Monitoring Applications Industrial Controllers TV Set Top Boxes (TiVO) Handheld PDA’s Automobile Computers Telecomm and Networking Hardware Myriad and sundry other uses... Introduction to Embedded Systems

Target Applications Introduction to Embedded Systems

The Embedded OS Market 2001 Introduction to Embedded Systems

The Embedded OS Market 2002 Introduction to Embedded Systems

Growth of Embedded Linux

For Further Info Web Sites
LinuxDevices.com Embedded Linux Consortium All Linux Devices Embedded Linux StarGate Introduction to Embedded Systems

For Further Info Web Sites/Magazines
Dr. Dobbs Embedded Systems Embedded Linux Journal Embedded Systems Programming Introduction to Embedded Systems

OS for Embedded Systems

Similar presentations

Presentation on theme: "OS for Embedded Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

OS for Embedded Systems

Similar presentations

Presentation on theme: "OS for Embedded Systems"— Presentation transcript:

Similar presentations

About project

Feedback