OS for Embedded Systems

1. OS for Embedded Systems

2. 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

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

4. 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 1003.1 Introduction to Embedded Systems

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Selecting an RTOS - Application support-2 • Microkernel architecture ( QNX ) • Designed to support processors with on chip MMU’s • Pentium, 386, 486, PowerPC, 68030-68060 • 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

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

14. 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

15. Hardware Consulting Reference Boards Vision Click Probe Vision ICE Probe Professional Services Doctor Design Systems SUPPORT Software Development Tools RealTime Software Tornado Tools Prism Tools Hardware Software Int. Tools VxWorks OS VxWorks AE OS pSOS OS BSPs and Device Drivers Networks stacks & Protocols WindRiver Products Introduction to Embedded Systems

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

17. 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 Kernel Kernel Tasks Objects Introduction to Embedded Systems

18. 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 Introduction to Embedded Systems

19. 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

20. 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

21. Shared Library Protection Domain fooLib.o int fooVal; void fooSet(int x) { fooVal = x; } fooVal = 4 fooVal = 99 Task A Task B fooSet (4) fooSet(99) But, How do We Share Code? Application Domain 1 Application Domain 2 Introduction to Embedded Systems

22. VxWorks AE Overlapped Memory Model Unmapped SD PD Shared Data Reserved Unmapped Modules Shared Library Shared Data SL PD Reserved Unmapped 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 Unmapped Application 1 Heap Unmapped Kernel Kernel Kernel Kernel Kernel Application 1 Application 2 Physical Memory Context Context Introduction to Embedded Systems

23. 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

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

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

26. Host: PC or UNIX TargetVxWorks 5.4Scalable Run-time Standard Tornado Tools Launcher GUI Target Server Real-time Embedded Application Tornado Plug-ins: File Systems Embedded Internet WindView Graphics Networking ScopePak, PerformancePak Multi-processing Memory Protection LOOK! WFCs POSIX Library CodeTEST wind Microkernel 3rd Party Tools SNiFF+ Debug Agent BSP SingleStep (PPC) Diab Compiler & RTA (PPC) Simulation EnvironmentVxSim Tornado II Architecture Introduction to Embedded Systems

27. Ethernet RS-232 Development Host VxWorks Target 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! Introduction to Embedded Systems

28. Target ARM, MIPS, Pentium, PPC Host Win, Linux, Solaris • Run-Time Components • Board Support Package • VxWorks AE • Networking Stacks • Other Components • Your Application Connections Virtual • Host-Based Tools • Tornado Tools 3 • Compilers • Debuggers • Code Browsers • Project Manager • OS Configuration • Analysis Tools • Simulators Serial BDM/JTAG • Hardware Debug Tools • Target Ref Boards • BDM/JTAG Debuggers Ethernet Developer’s Work Bench Only Wind River can provide complete, end-to-end software & hardware development solutions! Introduction to Embedded Systems

29. CrossWind Target Server Target Server / WDB Agent Development Host Target WindSh WTX Protocol VxWorks WDB Protocol WDB (Ethernet, serial, netrom, custom) Browser Application 3rd Party WTX = Wind River Tool eXchange WDB = Wind DeBug Introduction to Embedded Systems

30. Memory Management Device Support Scheduling & System Clock Facilities I/O system Synchronization & Intertask Communication Mutual Exclusion File Systems . . . NetworkingSupport VxWorks RTOS Introduction to Embedded Systems

31. 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. Introduction to Embedded Systems

32. 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. Introduction to Embedded Systems

33. 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. Introduction to Embedded Systems

34. RAM fooLib.c tTaskA fooSet(4) static int x; void fooSet (int arg) { x = arg; } text data tTaskB fooSet(99) bss Performance Optimizations • All tasks execute in the same address space: • All tasks execute at highest CPU privilege level. Introduction to Embedded Systems

35. READY PENDED DELAYED EXEC. PENDED & SUSPENDED DELAYED & SUSPENDED SUSPENDED Task State Transition Diagram Introduction to Embedded Systems

36. 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. Notes: On this board, INT 6 is the system clock, INT 3 is the network interrupt. Introduction to Embedded Systems

37. 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. Introduction to Embedded Systems

38. 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. Introduction to Embedded Systems

39. 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. Introduction to Embedded Systems

40. 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. Introduction to Embedded Systems

41. 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. Introduction to Embedded Systems

42. 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. Introduction to Embedded Systems

43. tConsumer msgQReceive(...) tProducer Four Score and Four Score and seven msgQSend (…) seven Four Score and Four Score and seven seven Message Queues • FIFO buffers of bounded length messages. • Synchronization and mutual exclusion built in. • A task pends reading from empty queue, or writingto full queue. A time-out may be specified. Introduction to Embedded Systems

44. 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 */ } Introduction to Embedded Systems

45. 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. Introduction to Embedded Systems

46. 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. Introduction to Embedded Systems

47. 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). Introduction to Embedded Systems

48. 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. Introduction to Embedded Systems

49. Client Server Client Server Network File Access • VxWorks can act as client or server for remote file access: • 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 VxWorks Remote Host Introduction to Embedded Systems

50. 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