References: 1. [Raj Kamal] Embedded Systems - Architecture, Programming and Design (2007, Tata McGraw-Hill) 2.

[Peter Marwedel] Embedded System Design (2006, Springer) Real-time Programming issues 3. [David Simon] An Embedded Software Primer (1999, Pearson Education Asia) 4. [Daniel W. Lewis] Fundamentals of Embedded Software where C and assembly meet (2002, Pearson Education Asia) 5. Wikipedia Note: Use these notes only as additional study material. Always refer to the text book for other topics.

Real-Time Operating Systems (RTOS)

Most often, an embedded system is designed to perform scheduling of multiple functions while controlling multiple devices. An embedded system program is therefore designed as a multitasking system program. In a multi-tasking operating system (OS), each process (task) has a distinct memory allocation (memory address space) of its own. A task has one or more functions or procedures for a specific job. A task may share the memory (data) with other tasks using the facilities provided by the OS. A processor may process multiple tasks separately or concurrently. The OS software includes scheduling features for the processes (tasks, ISRs and Device Drivers). An OS or an RTOS has a kernel. The kernels important function is to schedule the transition of a task from a ready state to a running state. (A process has mainly three states, namely, Ready, Running or Blocked (Wait) ). It also schedules the transition of a task from Blocked state to the Running state. The kernel may block a task to let a higher priority task be in running state. (This is called preemptive scheduling.) The kernel coordinates the use of the processor for the multiple tasks that are in ready state at any instant, such that only one among them is in the running state. This is true for a single-processor system. (In a multi-processor system [Some authors refer to this somewhat wrongly as a multi-processing system.] , more than one task may be in the running state.) The kernel also controls the inter process (task) communication (messaging) and sharing of variables, queues, pipes and various other communication channels. In an embedded system, the RTOS has to be scalable. Scaleable OS is one in which memory is optimized by having only the most essential features present in the final system software.

RTOS offers programmers more control over process priorities. An applications process priority level may exceed that of a system proces. RTOS minimizes critical sections of system code, so that the applications interruption is nearly critical. The variability in the amount of time an OS takes to accept and complete an applications task is called jitter. A hard real-time OS has less jitter than a soft real-time OS. The design goal of real-time systems is not high throughput, but a guarantee of a hard or soft performance category. An RTOS is valued more for how quickly or how predictably it can respond (to events) than the amount of work it can perform in a given period of time (throughput). An RTOS that can usually or generally meet a deadline is a soft real-time OS. If it can meet a deadline deterministically, it is a hard real-time OS. RTOS is more frequently dedicated to a narrow set applications.

Key Features of RTOS

1. Minimal interrupt latency. 2. Minimal thread-switching (context-switching)

Interrupt Latency
The time between the generation of an interrupt by a device and the servicing of the device which generated the interrupt.

Note: Refer Module 3 for details.

RTOS Design Philosophies

1. Event-driven Switches tasks when an event o higher priority needs service, called preemptive priority or priority scheduling. 2. Time-sharing Switches tasks on a regular clock interrupt and on events called round-robin.

Scheduling Algorithms
Cooperative Scheduling Preemptive Scheduling a. Round-Robin

b. Fixed Priority Preemptive Scheduling; an implementation of Preemptive Timeslicing. c. Fixed Priority Scheduling with Deferred Preemption. d. Fixed Priority Non-Preemptive e. Critical Section Preemptive Scheduling f. Static Time Scheduling

Earliest Deadline First Advanced scheduling using Stochastic (Timed Extended Predicate Transition Net (tEPr/ T net) and MTG (Multi-Thread Graph).

Two essential services of RTOS are inter-process communication and scheduling in addition to other OS services.

Operating System Services

The OS goals are perfection and correctness to achieve the following: Facilitating easy sharing of resources as per schedule and allocation. Resources here mean processor(s), memory, I/O, devices, virtual devices, system timer, software timers, keyboard, displays, printer and other similar resources. Facilitating easy implementation of the application software. Optimally scheduling the processes on one processor (or more CPUs on a multiprocessor system) by providing an appropriate context switching mechanism. Providing management functions for the processes (tasks or threads), memory, and I/Os and for other functions

Testing, Simulation and Debugging Techniques &Tools

There are two types of systems during the embedded software development: the Host System and the Target System each with its own processor and hardware architecture. The Host System is generally a desktop (PC), laptop or workstation. This is the system used for software development. The Target System is the actual hardware that will eventually the embedded system under development. The source code has two parts: hardware-independent code and hardware-dependent code. Device and Ports (interfacing logic circuitry and controlling software) have fixed addresses (unmodified by the locator) on the hardware. We can debug the target system by three methods: 1. Using Simulation 2. Using an Emulator (e.g. (EEP)ROM Emulators) 3. Using a Target Monitor

Testing performed on the Host

Testing and Debugging are performed at each stage of development as well as at the final stage when all modules are put together to build the complete system. Test Data - All possible combinations of test data are identified.

The host is also used for running the Simulator. Simulator simulates the target systems behaviour on the host itself. Initial Tests - Each module or segment is tested on the host itself during initial stages. The host is used to test the hardware-independent code. Exception Condition Tests - Used for testing the robustness of the system. What happens in case of unexpected inputs or data conditions? Interrupt Service Routines (ISRs) Test - Both hardware-dependent and hardwareindependent parts are tested on the host. Timer Tests - Hardware-dependent code for timing functions, setting clock-ticks, loading the count, getting the count and delay routines. ASSERT Macro Tests - Insert the code that checks whether a condition/ value of a parameter holds good (true) or or not (false). The ASSERT macro is usually run only in debug mode (not in release mode [production mode]). If any assertion fails, the program execution stops at that point. Use the ASSERT macro in all possible critical places in the application program. Instructions for testing are given from a file or as keyboard input. Outputs are displayed on the hosts screen or saved in files.

Simulation Simulation uses knowledge about the target system, target processor and the target architecture. At first, the source code is compiled using a cross-compiler and the generated object code is placed in the hosts RAM. The behaviour of the target processors registers and other functional units are then simulated. Simulator uses the linker and locator to create the executable binary image from the cross-compiled object files in RAM in such a way that the executable image functions like the actual code that would have run on the target system. Simulator simulates hardware units like the emulator, peripherals, network interface and input-output devices on a host. Simulator remains independent of the target system. Results expected are obtained from the RAM on the host system. Simulator helps in the development of a system before the final target system is ready with only a PC as the tool for development. Simulators are readily available for different processors and processing devices employing embedded systems.

Testing performed on the Target

The target is used to test hardware-dependent code. The target is also used to run the Monitor.

Some of these tools are proprietary. For example, Wind River Systems, Inc. (vendor of industry

leading real-time/ embedded OSes Wind River VxWorks, Wind River Linux and Wind River Mobile Linux) has Stethoscope Stethoscope is used for dynamically tracking changes in a program variable (parameter). Tracescope is a tool for tracing the changes in the modules and tasks as a function of time on the X-axis. It lets us find the RTOS scheduler behaviour during task switching and notes the time for various RTOS actions. So you could say that this is a debugging tool with visualization capability. It is usually provided as part of an IDE (Integrated Development Environment) along with other source code engineering tools such as program editor, compiler, assembler, linker, locator, emulator, EEPROM burner etc. Remember that traditional debugging is not possible with embedded systems as the software runs on the target processor, hidden away in some larger system.