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