Embedded os

Definition Embedded System is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function. In many cases, embedded systems are part of a larger system or product, as in the case of an antilock braking system in a car.

Requirements and Constraints Small to large systems, implying very different cost constraints, thus different needs for optimization and reuse Relaxed to very strict requirements and combinations of different quality requirements. Short to long life times Different environmental conditions. Different application characteristics resulting in static dynamic loads, slow to fast speed, compute versus interface intensive tasks and/or combinations Different models of computations ranging from discrete-event systems to those involving continuous time dynamics

MECHANICS Each correct answer is worth 3 points Only the first contestant who raises his/her hands has the right to answer the question Questions can be answered after the game master says “GO” A tie breaker question worth 1 point is required if more than one contestant has the highest point total The highest point total wins the game

Emmanuel John A. Pascual Maria Monereeza M. Floria – Our Lady of Fatima University Ma-an Andria R. Lacierda - WCC Francis Argel D. Gonzales - TIPQC Heherson Q. Suaiso - ACCESS GAME MASTER COntestants

What are the Applications of Embedded OS?

Applications Market Embedded Device Automotive Ignition systems Engine control Brake system Consumer electronics Cameras Toys/Games Telephones/Cell Phones/Pagers Industrial control Robotics Sensors

Applications Medical Infusion pumps Cardiac monitors Dialysis machines Office automation Fax machine Printer Scanners

SCORE TABLE EZA MAAN ARGEL SUAISO 3 0 0 0

What are the CHARACTERISTICS of Embedded OS?

Characteristics of E.Os Direct use of interrupts There are three (3) reasons why it is possible to let interrupts directly start or stop tasks. Embedded systems can be considered to be thoroughly tested. Protection is not necessary Efficient control over a variety of devices is required

Characteristics of E.Os I/O device flexibility There is virtually no device that needs to be supported by all versions of the OS, and the range of I/O device in large. Streamlined protection mechanisms Embedded systems are typically designed for a limited, well-defined functionality. 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.

What are the APPROACHES IN THE DEVELOPMENT OF Embedded OS?

Development Approaches Advantage Disadvantage Adapting an existing commercial OS The Embedded OS derived from a commercial general-purpose OS is based on a set of familiar interfaces. The OS is not optimized for real-time and embedded applications. Purpose-Built Embedded OS (Ecos and Tiny Os) Purposely designed for tasks requiring predictable operation over fast operations, necessitating different design decisions, particularly in the area of task scheduling. Must be designed from the ground up for embedded applications

ECOs Embedded Configurable Operating System is an open source, royalty-free, real-time OS. Intended for embedded applications. A system targeting at high performance small embedded systems. For such systems, an embedded form of Linux and other commercial Os would not provide the streamlined software required.

HOW DOES CONFIGURABILITY MEAN IN TERMS OF EOS?

Configurability An 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. Configuration tool Is used to configure the ECos package to run on the target embedded system. (running on windows or Linux).

Configurability Loading an ECos Configuration GNU make utility Application Source Code GNU Cross Compiler GNU Linker Executable file ECOs kernel libraries Target architecture libraries

ECOS Components A key design requirement for the ECOS is portability to different architectures and platforms with minimal effort. Main components are as follows: User application code Standard C library I/O system (device drivers) Kernels Hardware abstraction layer

ECOS Components User Application Code Standard C library I/O System (device drivers) Kernels Hardware abstraction layer

Hardware Abstraction Layer The HAL is software that presents a consisted API to the upper layers and maps upper-layer operations onto specific hardware platform. The HAL is implemented as three (3) separate modules. Architecture: defines the processor type. Variant: supports the features of the specific processor in the family. Platform: extends the HAL support to tightly coupled peripherals like interrupt controllers and time devices.

ECOS kernel Kernels were designed to satisfy four (4) main objectives Low interrupt latency: the time it takes to respond to an interrupt and begin execute an ISR Low task switching latency: the time it takes from when a thread becomes available to when actual execution begins. Small memory footprint memory resources for both program and data are kept to a minimum by allowing components to configure memory needed. Deterministic behavior: throughout all the aspect of execution. The kernel performance must be predictable and bounded to meet real-time application requirements.

ECOS kernel ECOS kernels also provide the core functionality needed for developing multi-threaded applications The ability to add/create new threads in the system Control over various threads in the system A choice of scheduler, determining which thread should currently be running A range of synchronization primitives, allowing thread interaction Integration with the system’s support for interrupts and exceptions

I/O System The ECOS I/O system is a framework for supporting device drivers. A variety of drivers for a variety of platform are provided in the ECOS configuration package. These include drivers for serial devices, Ethernet, flash memory interfaces, and various I/O interconnects such as PCI (peripheral component interface) and USB (universal serial bus).

I/O System Device drivers and other higher-layer software may be implemented directly on the HAL if this is appropriate. If specialized kernel type functions are needed, then the device driver is implemented using kernel APIs. The kernel provides a three-level interrupt model. Interrupt service routines (ISR): invoked response to a hardware interrupt. Hardware interrupts are delivered with minimal intervention to an ISR. Deferred service routines (DSR): invoked in response to a request by an ISR. DSR will run when it is safe to do so without interfering with the scheduler. Threads: the client to the driver. Threads are able to make all API (Application Programming Interface) calls and in particular are allowed to wait on mutexes and conditional variables.

WHAT ARE STANDARD C LIBRARIES?

Standard C Libraries A complete standard C run-time is provided. Also included is a complete math run time library for high-level mathematic functions, including a complete IEEE-754 floating-point library for those platforms without hardware floating points.

ECOS Scheduler Bitmap Scheduler a bitmap scheduler supports multiple priority levels but only 1 thread can exist at each priority level at a given time . Description: because there is only 1 thread, at most, at each priority level, the scheduler does not have to make a decision as to which thread at a given priority level should be dispatched next.

ECOS Scheduler Multi-queue scheduler The multi-queue scheduler is appropriate if the number of threads is dynamic or if the desirable to have multiple threads at the same priority level. The multilevel scheduler is also needed if time slicing is needed.

WHAT IS ECOS THREAD Synchronization?

ECOs Thread Synchronization Mutexes the mutex (mutual exclusion lock) is used to enforce mutually exclusive access to a resource. Allowing only 1 thread at a time to gain access. Has 2 states: locked and unlocked. When a mutex is locked by 1 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 on the resource.

ECOs Thread Synchronization Semaphores counting semaphores are suited to enabling threads to wait until an event has occurred. The event may be generated by a producer thread. Or by a DSR in response to a hardware interrupt. Description If counter is ZERO, an attempt by a consumer thread to wait on the semaphore will block until some other thread or a DSR post a new event to the semaphore If counter is greater than ZERO then an attempt to wait on the semaphore will consume one event.

ECOs Thread Synchronization Conditional Codes a conditional 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. They can be used to implement monitors of the type in ECOs. Event Flags is a 32-bit word used as a synchronization mechanism. Application code may associate a different event with each bit on the flag. A thread can wait for either a single event or a combination of events by checking 1 or multiple bits in a corresponding flag.

ECOs Thread Synchronization Mailboxes also called message boxes are an ECOs synchronization mechanism that provides a means for 2 threads to exchange information. Can be configured for blocking/non-blocking on both the send and receive side. 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.

Tiebreaker Question: 1 point WHAT IS ECOS TINY OS?

TinyOS The ECOS system provides a more streamlined approach for an embedded OS than one based on a commercial general-purpose OS. Such as an embedded version of the LINUX, thus ECOS and similar system are better suited for small embedded system with tight requirement on memory, processing -time, real-time response, power consumption, and so on. TINYOS takes the process of streamlining in much a further point, resulting in a very minimal OS for embedded systems.

SCORE TABLE CONGRATULATIONS TIPQC! EZA MAAN ARGEL SUAISO 9 9 10 9

Wireless Sensor Networks TINYOS was developed primarily for use with networks of small wireless sensor. A number of treads 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.

Tiny OS Goals Allow high concurrency in a typical wireless sensor network application, the devices are concurrency intensive. Several different flow of data must be kept moving simultaneously. Operate with limited resources the target platform for Tiny OS will have limited memory and computational resources and run on batteries or solar power.

Tiny OS Goals Adapt to hardware evolution should be possible to upgrade the hardware with little or no software change, if the functionality is the same. Support a wide range of applications applications exhibit a wide range of requirements in terms of lifetimes, communication, sensing and so on.

Tiny OS Goals Support a diverse set of platforms as with preceding point, a general-purpose embedded OS is desirable. 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.

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 is limited and well-defined ways. The other software module is the scheduler. And because the TINYOS doesn’t utilize kernels, there is no actual OS. But we can take the following view. The application area of interest is the wireless sensor network (WSN).

TINYOS Components The meet the demanding software requirement of this application, rigid, simplified software architecture is dedicated, 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.

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

TINYOS resource Interface Provides a simple but powerful set of conventions for dealing with resources. Three (3) abstractions for resources are used in TINYOS. Dedicated: a resource that a subsystem needs exclusive access at all times Virtualized: the virtualized abstraction may be used when the underlying resource need not be protected by mutual exclusion. Shared: the shared resource abstraction provides access to a dedicated resource through an arbiter component. The arbiter enforces mutual conclusion allowing only the user at a time to have access to a resource and enabling the client to lock the resource.

TINYOS resource Interface The shared resource configuration provides the following interfaces to a client: Resource: the client issues a request at this interface requesting access to the resource. 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.

TINYOS resource Interface Resources Configure: this interface allows a resource to be automatically configured just before a client is granted access to it. Resource-Specific interfaces: once a client has access to resource, it uses resource-specific interfaces to exchange data and control information with the resource.

Embedded os

Recommended

More Related Content

What's hot (20)

Similar to Embedded os (20)

Recently uploaded (20)

Embedded os