Definition of Embedded System

A general definition of embedded systems is: embedded systems are computing systems with tightly coupled hardware and software integration that are designed to perform a dedicated function. The word embedded reflects the fact that these systems are usually an integral part of a larger system, known as the embedding system. Multiple embedded systems can coexist in an embedding system.

RTOS
A Real-Time Operating System (RTOS) comprises of two components, viz., Real-Time and Operating System. An Operating system (OS) is nothing but a collection of system calls or functions which provides an interface between hardware and application programs. It manages the hardware resources of a computer and hosting applications that run on the computer. An OS typically provides multitasking, synchronization, Interrupt and Event Handling, Input/ Output, Inter-task Communication, Timers and Clocks and Memory Management. Core of the OS is the Kernel which is typically a small, highly optimised set of libraries. Real-time systems are those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced. RTOS is therefore an operating system that supports real-time applications by providing logically correct result within the deadline required. Basic Structure is similar to regular OS but, in addition, it provides mechanisms to allow real time scheduling of tasks. Though real-time operating systems may or may not increase the speed of execution, they can provide much more precise and predictable timing characteristics than general-purpose OS.

A hard real-time system is a real-time system that must meet its deadlines with a near-zero degree of flexibility. The deadlines must be met, or catastrophes occur. The cost of such catastrophe is extremely high and can involve human lives. The computation results obtained after the deadline have either a zero-level of usefulness or have a high rate of depreciation as time moves further from the missed deadline before the system produces a response. A soft real-time system is a real-time system that must meet its deadlines but with a degree of flexibility. The deadlines can contain varying levels of tolerance, average timing deadlines, and even statistical distribution of response times with different degrees of acceptability. In a soft real time system, a missed deadline does not result in system failure, but costs can rise in proportion to the delay, depending on the application.

DIFFERENCE: RTOS v/s General Purpose OS

Determinism - The key difference between general-computing operating systems and real-time operating systems is the deterministic " timing behavior in the real-time operating systems. "Deterministic" timing means that OS consume only known and expected amounts of time. RTOS have their worst case latency defined. Latency is not of a concern for General Purpose OS. Task Scheduling - General purpose operating systems are optimized to run a variety of applications and processes simultaneously, thereby ensuring that all tasks receive at least some processing time. As a consequence, low-priority tasks may have their priority boosted above other higher priority tasks, which the designer may not want. However, RTOS uses priority-based preemptive scheduling, which allows high-priority threads to meet their deadlines consistently. All system calls are deterministic, implying time bounded operation for all operations and ISRs. This is important for embedded systems where delay could cause a safety hazard. The scheduling in RTOS is time based. In case of General purpose OS, like Windows/Linux, scheduling is process based.

 Preemptive kernel - In RTOS, all kernel operations are preemptive Priority Inversion - RTOS have mechanisms to prevent priority inversion Usage - RTOS are typically used for embedded applications, while General Purpose OS are used for Desktop PCs or other generally purpose PCs.

Communication Types
Three types of communications often offered Message Queues Mailboxes Pipes RTOS guarantees that the functions provided for using these mechanisms are reentrant.

Queues
Support two operations Enqueue: used by a task to send data to another task Dequeue: Used by the other task to receive data. If the queue is empty the dequeuing task blocks until a message is ready. Usually messages are of some fixed length. More complicated operating systems may allow arbitrary length messages. Most RTOS require that the queue be initialized before use. It may be your responsibility to pre-allocate the memory that the queue will use. Identification of which queue you want to use varies between RTOS Writing to a full queue may cause the task to block or it may lose data or it may crash. Many RTOS provide a function that will not block a read from an empty queue but will return an error instead. Queue size may be inflexible. Many RTOS only allow you to write exactly the number of bytes taken up by a void pointer. To provide arbitrary size messages a pointer to the data can be enqueued Small amounts can be sent by casting to void pointer type.

Mailboxes
Mailboxes are similar to queues. Capacity of mailboxes is usually fixed after initialization

 Some RTOS allow only a single message in the mailbox. (Mailbox is either full or empty) Some RTOS allow prioritization of messages

Pipes

Pipes provide another communication mechanism like queues. Typically byte oriented (streams) Accepts arbitrary length messages. (but read() has no knowledge of where a write() started or left off)

The main components in the functional diagram are the hardware and the kernel of the RTOS running on top of it and servicing tasks and interrupts that comprise the real-time application. The OS has to provide,

o o o o o o

Task management (scheduling, dispatching, creation and termination of tasks etc.) Synchronization (for resource sharing) Interrupt handling (manipulate and monitor the interrupt descriptor table-IDT) to service hardware interrupts Memory management (virtual memory and dynamic memory allocation) Programmable clocks and timers, Inter-task communication (sockets, pipes, FIFO, shared memory etc.).

Multitasking
It is essential for an RTOS to clearly distinguish between schedulable and nonschedulable entities. Schedulable entities are typically characterized by a context (a control block) and can make explicit requests for resources (CPU, memory, I/O), further they are scheduled by a scheduler. The scheduler itself and such entities like interrupt handlers, and most system calls are nonschedulable by nature. Often they are characterized by the fact that they can execute continuously, periodically or in response to events. Further, their use of the CPU is implicit. Multi-tasking involves fast switching between tasks allowing multiple tasks to be in a state of execution yet only one task is executing at any instant. A RTOS must provide (at a minimum) a multi-tasking mechanism that is priority based and preemptive in nature.

Synchronization
Synchronization is necessary for real-time tasks to share mutually exclusive resources (devices, memory areas, buffers etc.), which is also needed for implementing task dependence. Traditional solutions using semaphores (and related constructs like monitors, critical regions) can result in unbounded priority inversion. Priority inversion is said to occur when a higher priority task is temporarily forced to wait for a lower priority task. Such inversion of priority can go unbounded when medium priority tasks preempt the lower priority task (due to lack of resource conflicts).

 Interrupt and Event Handling

For maximum productivity (and performance) it is important to allow application developers to, specify and write interrupt handlers (Interrupt Service Routines -ISRs) for Hardware Interrupts. A significant part of an embedded real-time system development is writing device drivers, therefore the RTOS should provide low level control of interrupts through interrupt handlers. Software interrupts like signals are also desirable.

Communication
Inter process communication (IPC) in RTOSs is primarily to exchange data on the same processor, however with an increasing number of real-time systems taking a more distributed (networked) form of operation some RTOSs allow process communication between processes resident on different processors. Popular forms of IPC include shared memory, message queues, pipes, FIFOs (file in file out) and sockets. Desirable properties of IPC mechanisms in the context of an RTOS include, provision for non-blocking communication, bounded operation (r/w) latency and asynchronous communication. All the RTOSs that provide an IPC mechanism provide the above properties.

Timers and Clocks

All the RTOSs provide good support for timers, time-triggered tasks and clocks. All of them allow access of clocks at nanosecond resolutions when supported by the hardware.

Memory Management

Most older RTOSs did not see the need for supporting virtual memory, due to the lack of an MMU (memory management unit) on the processor and, due to the non determinism introduced by it. However, most modern processors (with the exception of small embedded processors) come with a programmable MMU. Dynamic memory allocation allows programming flexibility but introduces the overhead of garbage collection. Therefore, calls to malloc can block due to unavailability of memory. Several of the RTOSs allow restricted use of dynamic memory allocation. Providing support for virtual memory is often a very difficult choice to make if the processor has an MMU because, not supporting VM would amount to a waste of the MMU, while supporting it would have the downside of non-determinism.