embeddedsystems-module4

8/3/2019 EmbeddedSystems-Module4

1/6

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 multi-

tasking 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.


2/6

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 iscalled 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: ReferModule 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
https://docs1.google.com/document/edit?id=1V2CP4aQ5-yF4IiFhNywtqvOZJA7BgWmcGdma2MB5Kb0&hl=en_GB&authkey=CLf9mZkK#bookmark=id.kjlm6ghegc6jhttps://docs1.google.com/document/edit?id=1V2CP4aQ5-yF4IiFhNywtqvOZJA7BgWmcGdma2MB5Kb0&hl=en_GB&authkey=CLf9mZkK#bookmark=id.kjlm6ghegc6jhttps://docs1.google.com/document/edit?id=1V2CP4aQ5-yF4IiFhNywtqvOZJA7BgWmcGdma2MB5Kb0&hl=en_GB&authkey=CLf9mZkK#bookmark=id.kjlm6ghegc6j


3/6

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


4/6

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 multi-

processor 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.


5/6

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 hardware-

independent 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 functionslike 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


6/6

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 thetime 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.

embeddedsystems-module4

Documents