Chapter 13 Embedded Operating Systems

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