Embedded os
- 1. OPERATING SYSTEM( OS 023L1 )EMBEDDEDOPERATING SYSTEMSPresented By:GAGNO, Nelson Jr.MADAYAG, Maria LourdesMAYBANTING, JeffersonRAMOS, Adrian AlvinSAN DIEGO, EleonorPresented To:ENGR. ARIEL E. ISIDRO
- 2. What is anEmbedded Systems?
- 3. EMBEDDED SYSTEMSAn embedded system is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function.
- 4. REQUIREMENTS&CONSTRAINTSSmall to large systems, implying very different cost constraints, thus different needs for optimization and reuse
- 5. Relaxed to very strict requirements and combinations of different quality requirements
- 6. Short to long life timesREQUIREMENTS&CONSTRAINTSDifferent environmental conditions
- 8. Different models of computation ranging from discrete-event systems to those involving continuous time dynamicsExamples of Embedded Systems and Their Markets
- 9. Possible Organizationof an Embedded System
- 10. UNIQUE CHARACTERISTICS & DESIGN REQUIREMENTSREAL-TIME OPERATION In many embedded systems, the correctness of a computation depends, in part, on the time at which it is delivered. Often, real-time constraints are dictated by external I/O and control stability requirements.REACTIVE OPERATIONEmbedded software may execute in response to external events.
- 11. UNIQUE CHARACTERISTICS & DESIGN REQUIREMENTSCONFIGURABILITY An embedded system must lend itself to flexible configuration so that only the functionality needed for a specific application and hardware suite is provided.I/O DEVICE FLEXIBILITYThere is virtually no device that needs to be supported by all versions of the OS, and the range of I/O device is large.
- 12. UNIQUE CHARACTERISTICS & DESIGN REQUIREMENTSSTREAMLINED PROTECTION MECHANISMS Embedded systems are typically designed for a limited, well-defined functionality. Untested programs are rarely added to the software. After the software has been configured and tested, it can be assumed to be reliable. Thus, apart from security measures, embedded systems have limited protection mechanisms.DIRECT USE OF INTERRUPTS Three reasons why it is possible to let interrupts directly start or stop tasks.Embedded systems can be considered to be thoroughly tested.
- 13. Protection is not necessary
- 14. Efficient control over a variety of devices is requiredTWO GENERAL APPROACHESAdapting an Existing Commercial Operating SystemPurpose-Built Embedded Operating System
- 15. Adapting an Existing Commercial Operating SystemAn existing commercial OS can be used for an embedded system by adding real-time capability, streamlining operation, and adding necessary functionality.
- 16. Adapting an Existing Commercial Operating SystemAn advantage of this approach is that the embedded OS derived from a commercial general-purpose OS is based on a set of familiar interfaces, which facilitates portability. The disadvantage of using a general-purpose OS is that it is not optimized for real-time and embedded applications.
- 17. Purpose-Built Embedded Operating SystemA significant number of operating systems have been designed from the ground up for embedded applications. Two prominent examples of this latter approach are eCos and TinyOS.
- 18. CHARACTERISTICS OF ASPECIALZED EMBEDDED OSHas a fast and lightweight process or thread switch
- 19. Scheduled policy is real time and dispatcher module is part of scheduler instead of separate component
- 20. Has a small sizeCHARACTERISTICS OF ASPECIALZED EMBEDDED OSResponds to external interrupts quickly: typical requirement is response time of less than 10µs
- 21. Minimizes intervals during which interrupts are disabled
- 22. Provides fixed or variable sixed partitions for memory management as well as the ability to lock code and data in memoryCHARACTERISTICS OF ASPECIALZED EMBEDDED OSProvides sequential files that can accumulate data at a fast rate to deal with timing constraints, the kernel
- 23. Provides bounded execution time for most primitives
- 24. Maintains a real-time clockCHARACTERISTICS OF ASPECIALZED EMBEDDED OSProvides for special alarms and timeouts
- 25. Supports real-time queuing disciplines such as earliest deadline first and primitives for jamming a message into the front of a queue
- 26. Provides primitives to delay processing by a fixed amount of time and to suspend/resume executionEmbedded Configurable Operating Systems (eCos)
- 27. WHAT IS AN eCos? eCos stands for Embedded Configurable Operating System It is an open source, royalty-free, real-time OS intended for embedded applications. It is one of the most widely used embedded operating systems.
- 28. CONFIGURABILITYAn embedded system OS that is flexible enough to be used in a wide variety of embedded application and on a wide variety of embedded platforms must provide more functionality than will be needed for any particular application and platform.
- 29. CONFIGURABILITY The eCos configuration tool (which runs on Windows or Linux) is used to configure an eCos package to run on a target embedded system.
- 30. CONFIGURABILITY
- 32. eCos COMPONENTS A key design requirement for eCos is portability to different architectures and platforms with minimal effort.
- 34. HARDWAREABSTRACTION LAYER ( HAL )The HAL is software that presents a consistent API to the upper layers and maps upper-layer operations onto a specific hardware platform. Thus, the HAL is different for each hardware platform.
- 35. HARDWAREABSTRACTION LAYER ( HAL )Three modules:Architecture: Defines the processor family type. This module contains the code necessary for processor startup, interrupt delivery, context switching, and other functionality specific to the instruction set architecture of that processor family.
- 36. Variant: Supports the features of the specific processor in the family.
- 37. Platform: Extends the HAL support to tightly coupled peripherals. This module defines the platform or board that includes the selected processor architecture and variant. It includes code for startup, chip selection configuration, interrupt controllers, and timer devices.eCos KERNEL Four main objectives:Low interrupt latency: The time it takes to respond to an interrupt and begin executing an ISR.
- 38. Low task switching latency: The time it takes from when a thread becomes available to when actual execution begins.
- 39. Small memory footprint: Memory resources for both program and data are kept to a minimum by allowing all components to configure memory as needed.
- 40. Deterministic behavior: Throughout all aspect of execution, the kernels performance must be predictable and bounded to meet real-time application requirements.eCos KERNELThe eCos kernel provides the core functionality needed for developing multithreaded applications:The ability to create new threads in the system
- 41. Control over the various threads in the system
- 42. A choice of schedulers, determining which thread should currently be running
- 43. A range of synchronization primitives, allowing threads to interact and share data safely
- 44. Integration with the system’s support for interrupts and exceptionseCos I/O SYSTEMFramework for supporting device drivers. A variety of drivers are available for different platforms are supported through eCos configuration package.Drivers: serial devices, ethenet, flash memory & various I/O interconnect (such as PCI and USB)
- 45. eCos Principal ObjectiveEfficiency No unnecessary software layering or irrelevant functionality.Device driver provide separate function for:InputOutputBufferingDevice control
- 46. eCos SCHEDULERBitmaps SchedulerEfficient for small number of threads active.Each thread has different priority.Multilevel queue SchedulerAppropriate when number of threads is running.Multiple threads at each priority.Time slicing.
- 47. Terms to be remember…THREADClient of the driver or simply a “process”.PRIORITY LEVELUse by the scheduler to determine which thread ready to run.TIME SLICINGAllow each thread at a given time to execute a given amount of time.
- 48. Terms to be remember…PREEMPTIONIs a context switch halting execution of lower priority thread allowing higher priority thread to execute.SCHEDULERSelects appropriate thread for execution provide mechanisms for these executing threads to synchronize, and control the effect of interrupts on thread execution.
- 49. BITMAP SCHEDULERAllow the execution of threads at multiple priority levels; however, only single thread can exist at each priority level.
- 50. BITMAP SCHEDULER
- 51. MULTILEVEL QUEUE SCHEDULERAllow execution of multiple threads at each of it priority levels. Scheduler allows pre-emption and time slicing.
- 53. eCosTHREAD SYNCHORNIZATIONThread synchronization requires that a running thread gain a "lock" on an object before it can access it. The thread will wait in line for another thread that is using the method/data member to be done with it. This is very important to prevent the corruption of program data if multiple threads will be accessing the same data. If two threads try to change a variable or execute the same method at the same, this can cause serious and difficult to find problems. Thread synchronization helps prevent this.
- 54. eCosTHREAD SYNCHORNIZATIONClassics MechanismMutexesSemaphoresCondition variablesSynchronization/ Communication MechanismEvent flagsMailboxesSMP support (symmetric/ multiprocessing)Spinlocks
- 55. Mutual Exclusion Lock( MUTEXES ) A mutex is used to enforce mutually exclusive access to a resource, allowing only one thread at a time to gain access. The mutex has only two states: locked and unlocked.
- 56. Lock and UnlockedWhen a mutex is locked by one thread, any other thread attempting to lock the mutex is blocked.When the mutex is unlocked, then one of the threads blocked on this mutex is unblocked and allowed to lock the mutex and gain access to the resource.
- 57. SEMAPHORESA counting semaphore is an integer value used for signaling among threads. Counting semaphores are suited to enabling threads to wait until an event has occurred. Useful for resource management.
- 58. SEMAPHORES If this counter is zero, an attempt by a consumer thread to wait on the semaphore will block until some other thread or a DSR posts a new event to the semaphore. If the counter is greater than zero then an attempt to wait on the semaphore will consume one event; in other words, decrement the counter, and return immediately.
- 59. CONDITIONAL VARIABLES A condition variable is used to block a thread until a particular condition is true. Condition variables are used with mutexes to allow multiple thread to access shared data.
- 60. EVENT FLAGS An event flag is a 32-bit word used as a synchronization mechanism. Application code may associate a different event with each bit in a flag. A thread can wait for either a single event or a combination of events by checking one or multiple bits in the corresponding flag.
- 61. MAILBOXES It is also called message boxes, are an eCos synchronization mechanism that provides a means for two threads to exchange information. The eCos mailbox mechanism can be configured for blocking or nonblocking on both the send and receive side.
- 62. SPINLOCKS A spinlock is a flag that a thread can check before executing a particular piece of code. Basically, only 1 thread at a time can acquire a spinlock. Any other thread attempting to acquire the same lock will keep trying (spinning) until it can acquire a lock.
- 63. Tinyos
- 64. WHAT IS A TINYOS?TinyOS is a free and open source component-based operating system and platform targeting wireless sensor networks. TinyOS is an embedded operating system written in the nesC programming language as a set of cooperating tasks and processes.
- 65. WIRELESS SENSOR NETWORKS TINYOS was developed primarily for use with networks of small wireless sensor. A number of trends have enabled the development of extremely compact, low-power sensors. The well-known Moore’s law continuous to drive down the size of memory and processing logic elements. Smaller size in turn reduces power consumption. Low power and small size treads are also evident in wireless communication hardware, micro-electrical sensors (MEMS) and transducers.
- 66. NETWORK TOPOLOGY
- 67. TINYOS GOALSAllow high concurrency: In a typical wireless sensor network application, the devices are concurrency intensive. Several different flows of data must be kept moving simultaneously. While sensor data is input in a steady stream, processed results must be transmitted in a steady stream. In addition, external controls from remote sensors or base stations must be managed.
- 68. Operate with limited resources: The target platform for TinyOS will have limited memory and computational resources and run on batteries or solar power. A single platform may offer only kilobytes of program memory and hundreds of bytes of RAM. The software must make efficient use of the available processor and memory resources while enabling low-power communication.TINYOS GOALSAdapt to hardware evolution: Mote hardware is in constant evolution; applications and most system services must be portable across hardware generations. Thus, it should be possible to upgrade the hardware with little or no software change, if the functionality is the same.
- 69. Support a wide range of applications: Applications exhibit a wide range of requirements in terms of lifetime, communication, sensing, and so on. A modular, general-purpose embedded OS is desired so that a standardized approach leads to economies of scale in developing applications and support software.TINYOS GOALSSupport a diverse set of platforms: As with the preceding point, a general-purpose embedded OS is desirable.
- 70. Be robust: Once deployed, a sensor network must run unattended for months or years. Ideally, there should be redundancy both within a single system and across the network of sensors. However, both types of redundancy require additional resources. One software characteristic that can improve robustness is to use highly modular, standardized software components.TINYOS COMPONENTS An embedded software system built using TinyOS consists of a set of small modules called components, each of which performs a simple task or set of tasks and which interface with each other and with hardware in limited and well-defined ways. The only other software module is the scheduler. To meet the demanding software requirements of this application, a rigid, simplified software architecture is dictated, consisting of components. The TinyOS development community has implemented a number of open-source components that provide the basic functions needed for the WSN application.
- 71. TASK Within a component, tasks are atomic: Once a task has started, it runs to completion. It cannot be preempted by another task in the same component, and there is no timeslicing. However, a task can be preempted by an event. A task cannot block or spin wait.
- 72. COMMAND It is a nonblocking requests. A command is typically a request for the lower-level component to perform some service, such as initiating a sensor reading.
- 73. EVENTS In TinyOS may be tied either directly or indirectly to hardware events. The lowest level software components interface directly to hardware interrupts, which 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.
- 74. TINYOS RESOURCE INTERFACE The TINYOS scheduler operates across all components. Virtually all embedded systems using TINYOS will be uni-processor systems, so that only one task among all the tasks in all the components may execute at a time. The scheduler is a separate component. It is the only portion of TINYOS that must be present in any system.
- 75. ABSTRACTIONS FOR RESOURCESDedicatedA resource that a subsystem needs exclusive access at all times.VirtualizedThe virtualized abstraction may be used when the underlyingresource need not be protected by mutual exclusion.SharedThe shared resource abstraction provides access to a dedicatedresource through an arbiter component. The arbiter enforcesmutual conclusion allowing only the user at a time to haveaccess to a resource and enabling the client to lock theresource.
- 76. SHARED RESOURCE CONFIGURATIONResource: The client issues a request at this interface requesting access to the resource.
- 77. Resource Requested: This is similar to the Resource interface. In this case, the client is able to hold onto a resource until the client is notified that someone else needs the resource.SHARED RESOURCE CONFIGURATIONResource Configure: This interface allows a resource to be automatically configured just before a client is granted access to it.
- 78. Resource-specific interfaces: Once a client has access to a resource, it uses resource-specific interfaces to exchange data and control information with the resource.SHARED RESOURCE CONFIGURATION In addition to the dedicated resource, the shared resource configuration consists of two components. The Arbiter accepts requests for access and configuration from a client and enforce the lock on the underlying resource. The shared resource component mediates data exchange between the client and the underlying resource.
- 80. Thank you!!