1 / 49

Chapter 13 Embedded Operating Systems

Operating Systems: Internals and Design Principles. Chapter 13 Embedded Operating Systems. Seventh Edition By William Stallings. Operating Systems: Internals and Design Principles.

roxy
Download Presentation

Chapter 13 Embedded Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating Systems:Internals and Design Principles Chapter 13Embedded Operating Systems Seventh EditionBy William Stallings

  2. Operating Systems:Internals and Design Principles In brief, the conventional arguments that bird brains are too small or do not have particular structures needed for intelligence are based on ignorance of brains in general and bird brains in particular. It is unwarranted to argue that the small brains and small bodies of birds render them less capable of behaving with intelligent awareness than animals with large brains and large bodies. — THE HUMAN NATURE OF BIRDS, Theodore Barber

  3. Embedded System • Refers to the use of electronics and software within a product that is designed to perform a dedicated function • in many cases, embedded systems are part of a larger system or product • antilock braking system in a car would be an example

  4. Examples of Embedded Devices

  5. Real Time Constraints • Embedded systems are tightly coupled to their environment • This imposes real-time constraints by the need to interact with the environment • required speeds of motion • required precision of measurement • required time durations

  6. Embedded System Organization

  7. Design Differences

  8. Characteristics of Embedded OS real-time operation reactive operation configurability I/O device flexibility streamlined protection mechanisms direct use of interrupts

  9. Developing an Embedded OS

  10. Adapting an Existing OS • An existing commercial OS can be used for an embedded system by adding: • real time capability • streamlining operation • adding necessary functionality

  11. Purpose-Built Embedded OS • Typical characteristics include: • fast and lightweight process or thread switch • scheduling policy is real time and dispatcher module is part of scheduler • small size • responds to external interrupts quickly • minimizes intervals during which interrupts are disabled • provides fixed or variable-sized partitions for memory management • provides special sequential files that can accumulate data at a fast rate

  12. Timing Constraints

  13. Embedded Configurable Operating System (eCos) Open source, Royalty-free Real-time OS Intended for embedded applications Targeted at high-performance small embedded systems Implemented on a wide variety of processor platforms One of the most widely used embedded operating systems

  14. eCos Configuration Tool Level Top

  15. eCos Configuration Tool Details Kernel

  16. Loading an eCos Configuration

  17. eCos Layered Structure

  18. Presents consistent API to upper layers and maps upper-layer operations onto a specific hardware platform • Different for each hardware platform Hardware Abstraction Layer (HAL)

  19. HAL Modules • The HAL is implemented as three separate modules

  20. eCos Kernel Design The eCos kernel was designed to satisfy four main objectives:

  21. eCos Kernel Functionality • The eCos kernel provides the core functionality needed for developing multi-threaded applications: • the ability to create new threads in the system, either during startup or when the system is already running • control over the various threads in the system • a choice of schedulers, determining which thread should currently be running • a range of synchronization primitives, allowing threads to interact and share data safely • integration with the system’s support for interrupts and exceptions

  22. Utilizing Kernel Functions • Some functionality that is typically included in the kernel of an OS is not included in the eCos kernel: • memory allocation is handled by a separate package • each device driver is a separate package • various packages are combined and configured to meet the requirements of the application • for some embedded platforms the eCos kernel is not used at all

  23. eCos I/O System Framework for supporting device drivers A variety of drivers are available through the configuration package Principal objective is efficiency with no unnecessary software layering or extraneous functionality Device drivers provide the necessary functions for input, output, buffering, and device control

  24. Interrupt Model • The kernel provides a three-level interrupt model:

  25. Table 13.2Device Driver Interface to the eCos Kernel: Concurrency

  26. Table 13.3Device Driver Interface to the eCos Kernel: Interrupts

  27. eCos Scheduler The eCos kernel can be configured to provide one of two scheduling designs:

  28. Bitmap Scheduler Priority Levels

  29. Multilevel Queue Scheduler Priorities

  30. eCos Thread Synchronization The eCos kernel can be configured to include one or more of six different thread synchronization mechanisms Classic mechanisms: Synchronization/communication mechanisms SMP support(symmetric multiprocessing)

  31. Mutex • Mutual exclusion lock • Used to enforce mutually exclusive access to a resource • Has two states: locked and unlocked • Can be configured to support either a priority inheritance protocol or a priority ceiling protocol • Differs from a binary semaphore in two respects: • the thread that locks the mutex must be the one to unlock it • a mutex provides protection against priority inversion

  32. UsingMutexes • In eCos, condition variables are typically used in conjunction with mutexes to • implement long-term waits for some condition to become true

  33. Mutexes and Condition Variables

  34. Event Flags, Mailboxes, Spinlocks

  35. TinyOS Streamlines to a very minimal OS for embedded systems Core OS requires 400 bytes of code and data memory combined Not a real-time OS There is no kernel There are no processes OS doesn’t have a memory allocation system Interrupt and exception handling is dependent on the peripheral It is completely nonblocking, so there are few explicit synchronization primitives Has become a popular approach to implementing wireless sensor network software

  36. Wireless Sensor Network Topology

  37. TinyOS Goals • With the tiny distributed sensor application in mind, the following goals were set for TinyOS: • allow high concurrency • operate with limited resources • adapt to hardware evolution • support a wide range of applications • support a diverse set of platforms • be robust

  38. TinyOS Components Embedded software systems built with TinyOS consist of a set of modules (called components), each of which performs a simple task and which interface with each other and with hardware in limited and well-defined ways The only other software module is the scheduler Because there is no kernel there is no actual OS The application area of interest is the wireless sensor network (WSN)

  39. The shaded box in the diagram indicates • the component, which is treated as an object that can only be accessed by defined interfaces, indicated by white boxes • A component may be hardware or software • Each component • can link to only two other components, one below it in the hierarchy and one • above it TimerM Component

  40. Components -- Tasks • A software component implements one or more tasks • Each task in a component is similar to a thread in an ordinary OS • Within a component tasks are atomic • once a task has started it runs to completion

  41. Components -- Commands • A command is a nonblocking request • a task that issues a command does not block or spin wait for a reply from the lower-level component • Is typically a request for the lower-level component to perform some service • The effect on the component that receives the command is specific to the command given and the task required to satisfy the command • A command cannot preempt the currently running task • A command does not cause a preemption in the called component and does not cause blocking in the calling component

  42. Components -- Events • Events in TinyOS may be tied either directly or indirectly to hardware events • Lowest-level software components interface directly to hardware interrupts • may be external interrupts, timer events, or counter events • An event handler in a lowest-level component may handle the interrupt itself or may propagate event messages up through the component hierarchy • A command can post a task that will signal an event in the future • in this case there is no tie of any kind to a hardware event

  43. TimerC Configuration • The uppercase C stands for Component • The uppercase M stands for Module • The TimerC component, providing the Timer interface, is a configuration that links its implementation to Clock and LED providers

  44. TinyOS Scheduler • Operates across all components • Only one task executes at a time • The scheduler is a separate component • it is the one portion of TinyOS that must be present in any system • Default scheduler is a simple FIFO queue • Scheduler is power aware • puts processor to sleep when there is no task in the queue

  45. Simplified View of the Surge Application

  46. Configuration for Surge

  47. TinyOS Resource Interface TinyOS provides a simple but powerful set of conventions for dealing with resources

  48. Shared Resource Configuration

  49. Summary • Embedded system refers to the use of electronics and software within a product • An existing commercial OS can be used for an embedded system by adding real-time capability, streamlining operation, and adding necessary functionality • Embedded Configurable Operating System (eCos) is an open source, royalty free, real-time OS intended for embedded applications • A key design requirement for eCos is portability to different architectures and platforms with minimal effort • eCos kernel was designed to satisfy four main objectives: low interrupt latency, low task switching latency, small memory footprint, and deterministic behavior • can be configured to provide the bitmap scheduler and multilevel queue scheduler designs • The eCos I/O system is a framework for supporting device drivers • TinyOS was developed primarily for use with networks of small wireless sensors • TinyOS scheduler operates across all components

More Related