Subject Name Embedded system Design Subject Code 10

Subject Name: Embedded system Design Subject Code: 10 EC 74 Prepared By: Aswini N , M N Praphul & Navya Vipin (TE) Department: ECE Date: 10/11/14 1/31/2022

UNIT 5&6 1/31/2022

� Real-Time Kernels and Operating Systems Introduction � Tasks and Things, Programs and Processes � The CPU is a resource � Threads – Lightweight and heavyweight � Sharing Resources � Foreground/Background Systems � The operating System. � The real time operating system (RTOS) � OS architecture � Tasks and Task control blocks 1/31/2022

Real time kernels and OS Evening filled with music, a gourmet meal, and perhaps some c ongenial philosophical discussions while dining. • • – it is important that everything be perfect. – each of the dishes that are being prepared to finish at the same t ime so that they are cooked to perfection and can all be presented at the table together. • plan the meal, we have to decide when we must start cooking t he meat, the fish, the vegetables, the rice or potatoes or noodles. •

we have scheduled everything properly, they will all finish together and culminate in a marvellous banquet; if not, we order out. • At some point, all of the different dishes are cooking together. • We have broken the main task‐ cook the meal‐ down into a number of smaller ones, subtasks, that can be done at the same time. • 1/31/2022

we continually check one dish and then the next to make s ure that everything is proceeding smoothly ‐ � add a little salt here, adjust the flame a bit there, add a little � � wine to that sauce, adjust the seasoning on this one, start that one. We can capture the meal preparation in a high‐level UML ac tivity diagram The common approach to designing an embedded applicat ion follows the same pattern. 1/31/2022

� Ø The application comprises a number of tasks that must be completed in order for the intended application to be completed. Ultimately, we mapped those pieces onto the hardware and software modules. Each of the software modules that comprise the embedd ed program is simply a collection of instructions ‐ � The firmware ‐That direct the system's CPU, the CPU, to carry out a prescribed job. – If the partitioning is done well, each of the smaller mod ules will naturally become one of the tasks that make up the application. � 1/31/2022

1/31/2022

Programs and Processes § § An embedded program, made up of a collection of firmware modules, is a static entity. It can do no useful work unless it is running or executing. When a firmware module is executing, it is called a process or task. When a process is created, it is allocated a number of resources by the operating system. 1/31/2022

§ § § These can include a process stack, memory address spac e, registers (through the CPU), a program counter, I/O ports, network connections, file descriptors, and so on These resources are generally not shared with other proc esses. During execution, the contents of the PC are continually changing as the process moves from instruction to instr uction within the program, reading, manipulating, and w riting data. 1/31/2022

• That data may be produced by the application, read from the system's memory, or entered into the system from some external source such as sensors, switch closures, or remote ap plications. • The currently executing instruction (identified by the value of the PC) and the prese nt values of the associated data in memory or in registers are collectively known as the process stat e. • The process state may contain the values of a large number of other pieces of infor mation as well. 1/31/2022

The CPU is a Resource � The traditional view of computing focuses on the pr ogram. � One says that the program, or more specifically a ta sk within the program, is running on the computer. � In an embedded application, we change the point o f view to that of the µp. � Viewed with respect to the µp ‐ more specifically, the CPU ‐ the CPU is being used to execute the firmware. � CPU is another resource that is available for use by the task to do its job 1/31/2022

Single Process 1/31/2022

Multiple Process 1/31/2022

Under such a scheme, in addition to the CPU, the processes are sharing other system resources as well such as timers, I/O facilities, and busses. • Despite the illusion that all of the tasks are running simultaneously, in reality, at any instant in time, only one process is actively executing. • That process is said to be in the run state. The other process(es) is/are in the r eady waiting state. 1/31/2022

CPU as a Resource • • • The main resource, the CPU, is given to one task for a short while and then to the other If each task shares the system's resources back and forth, each can get its job finished. If the CPU is passed between the tasks quickly enough, it will appears as if both tasks are using it at the same time. We will thus have a system that models parallel operations by time sharing a single processor. The execution time for the program will be extended, but the operation will give the appearance of simultaneous execution. • Such a scheme is called multitasking; the tasks are said to be running concurrently. • The concept can easily be extended to more than two tasks 1/31/2022

CHANGING TASKS • C, • • • A task's context comprises the important information about the state of the task such as the values of any variables (held in the CPU's registers), the value of the P and so forth. Each time that a running task is stopped ‐ preempted or blocked ‐ and the CPU is given to another task that is ready, a switch to a new context is executed. A context switch first requires that the state of the currently active task be saved. If the task that is scheduled to get the CPU next had been running previously, its state is restored and it continues where it had left off. Otherwise, the new task starts from its initial state. As is evident, a context change entails a lot of work and can take a significant amo unt of time. 1/31/2022

Threads 1/31/2022

Sharing resources � single process, single thread, as the name impli es has only one process, and, in an embedded ap plication, that process runs forever. �– A multiprocess ‐ single thread supports multiple simultaneously executing processes; each process has only a single threa d of control �– A single process ‐ multiple threads design supports only one process; within the process, it has multiple threads of control. 1/31/2022

Memory Resource Management Most µp designs today are still based on the von Neumann architecture in which the program is stored in memory in the same manner as any other piece of information(data). � When a process is created by the operating system, it is given a portion of that physical memory in which to work. � The set of address delimiting that code and data memory, proprietary to each process, is called its address space. � � That address space will typically not be shared with any other peer processes. However, when multiple processes are concurrently executing in memory, an errant pointer or stack error can easily result in memory owned by other processes � 1/31/2022

Process level management � A process may create or spawn child processes. • When doing so, that parent process may choose to give a subset of its resources to each of the children. The children are separate processes, and each has its own data address space, data, status, and stack. � � � The code portion of the address space is shared. A process may create multiple threads. When doing so, that parent process shares most of its resources with each of the threads. � These are not separate processes but separate threads of execution within the same process. � 1/31/2022

Real Time Operating System � A real‐time OS is primarily an OS. In addition to the responsibilities already enumerated, this special class of OS ensures (among other things) that (rigid) time constraints can be met. � The RTOS is commonly found in embedded applications because, as noted, in certain such applications, if such requirements are not met, the performance of the application is inaccurate or compromised in some way. � Such systems are often interacting with the physical environment through sensors and various types of measurement devices. � RTOS ‐ based applications are frequently used in scientific experiments, control systems, or other applications where missed deadlines cannot be tolerated. � 1/31/2022

OS Architecture • • • Most contemporary OS are designed and implemented as a hierarchy of what are called virtual machines. Organized like the onion model discussed earlier, the only real machine that the various pieces of functionality within the OS see is the underlying physical µp; specifically the OS sees the CPU, the memory, and the concrete I/O devices. The hierarchy is designed such that each layer uses the functions/operations and services of lower layers. The primary advantage of such an approach is increased modularity. In some architectures, the high level layers have access to lower levels through system calls and hardware instructions. The existing calling interface between levels is retained while providing access to the physical hardware below. 1/31/2022

1/31/2022

• With such an approach, one could run entirely different OS as an applicat ion within the primary OS. • Such a virtual machine implementation can be difficult to effect in gener al. • There is not always a good match between the hardware on the real mac hine and that required by the emulated or virtual machine. • The real machine may have two I/O ports, one serial and one parallel, for example, and the emulated machine ay need three serial and two parallel ports. • Clearly, one cannot create more physical ports than exist in reality; there fore, the remaining necessary ports must be virtual. 1/31/2022

Tasks and Tasks control blocks �A traditional or RTOS orchestrates the behaviour of an application by executing each of the tasks th at comprise the design according to a specified sc hedule. � That schedule and its management in an RTOS can determine success or failure of the design. � Each task or process is represented by a task or process control block (TCB). 1/31/2022

TASK CONTROL BLOCK When a system is implemented using the task control block model, each TCB will contain all relevant information about the state of the task. � � To affect the context switch, necessary task state information is copied to the TCB. The TCB can then be inserted into the appropriate queue, and the status and state information for the new or resumed task can be entered into the system variables. � If the running task has been preempted, the TCB will be linked into ready queue waiting for the CPU to become available. � � Based on the scheduling algorithm, it may or may not be the next task to run. If the task has blocked, the TCB will be linked into the waiting queue for the required resource. � � When the resource becomes available, the task will move to the ready queue. 1/31/2022