Embedded Computer Systems

• Topics
– What are embedded systems, their applications, their
characteristics, hard/soft real-time systems
– How embedded software development differs from regular
software development
– How embedded operating systems differ from general purpose
operating systems
– Decomposition of embedded software into tasks and identification
of task parameters
– Schedulability and scheduling algorithms
• Clock-driven and priority-driven scheduling
– Analysis and verification
• Real-time logic and Time Petri Nets
– Practical aspects
• Priority inversion and resource constraints
 Embedded Computer Systems

• Text/recommended/reference books
– Q. Li with C. Yao, Real-Time Concepts fo Embedded Systems,
CMP Books, 2003
– J.W.S. Liu, Real-Time Systems, Prentice-Hall, 2000
– A.M.K. Cheng, Real-Time Systems: Scheduling, Analysis, and
Verification, Wiley, 2002
– H. Kopetz, Real-Time Systems: Design Principles for Distributed
Embedded Applications, Kluwer Academic Publishers, 1997
– B.P. Douglass, Real-Time Design Patterns: Robust Scalable
Architecture for Real-Time Systems, Addison-Wesley, 2003
– C.M. Krishna and K.G. Shin, Real-Time Systems, WCB/McGraw-
Hill, 1997
 Embedded Computer Systems
• Evaluation
– 3 tests: 70%
– Assignments: 30%
• Design/development/analysis of real-time systems
– Train control system or robot control system
– Real-time scheduling, communication, coordination issues
– Main focus of the lectures and tests will be on the theory of real-
time systems - Scheduling, timing analysis, handling potential
anomalies
– The assignments will provide opportunity to learn practical issues,
including details of some real-time operating systems
 Embedded Computer Systems
• An embedded computer system is a part of a larger electro-
mechanical system
– Also called pervasive or ubiquitous computers
– Applications
• Vehicle control systems
• Telephone switching systems and telephone devices
• Home automation systems
• Real-time embedded systems
– Must respond to external events in real-time
– Hard real-time systems
• E.g., missile defense system, aircraft control system
– Soft real-time systems
• E.g., video-on-demand system
– Classify
• Chess playing program: Not embedded system but has timing constraints
• Text formatting system: Not embedded, not real-time
• Aircraft control system: Hard real-time embedded system
• Mail sorting system: Soft real-time embedded system
• Voice-over-IP system: Soft real-time system
• We will focus on real-time embedded systems
 How to Achieve Real-Time Systems?

• Processing time
– Consider process-control systems, such as vehicle control systems,
traffic light control systems, and manufacturing systems
Actuators Sensors
Plant

Controller

Command (reference input)

State transition model
– State transition model
• States of the system → Sensed using sensors
– Control goal specifies the desired states
• Transitions → Model the effect of actuators
 How to Achieve Real-Time Systems?

• Processing time
– Consider process-control systems, such as vehicle control systems,
traffic light control systems, and manufacturing systems
– The control system must handle complex transitions
• Continuously enabled transitions, e.g., motion of a vehicle
– Transitions occur with passage of time unless the actuators settings are
changed
• Some transitions are caused by the environment
– The controller must enable controllable transitions in a timely way
to prevent failures
– Fast algorithms, fast processors → Are these sufficient?
• No

• Also need bounded and predictable

processing time
 How to Achieve Real-Time Systems?

• Communication time
– Consider multimedia communication or video-on-demand systems

Transmitter Receiver

– In addition to timely processing, the packets must be delivered on

time to achieve jitter-free and fully synchronized playback
• Jitter
– Difference between expected and actual arrival time of a packet
• Synchronized playback
– Synchronization of different media streams, e.g., audio and video
streams
 How to Achieve Real-Time Systems?

• Communication time
– Consider multimedia communication or video-on-demand systems
– Is high bandwidth sufficient for ensuring jitter-free and well
synchronized playback?
• No, unless dedicated communication links are used
• In general, we need protocols that guarantee
timely delivery of packets in spite of shared links
– Think of an ambulance or a fire-truck responding to an emergency
situation
• They have priority over regular vehicles
• And they can use shoulder lanes (form of “reservation”)
 How to Achieve Real-Time Systems?

• Storage access time

– Consider a distributed system that has to track multiple aircrafts

Remote
tracker Main tracking system

Storage
system

– Is it sufficient to have real-time processing and real-time

communication?
• No, comparison with previous data is needed to determine the
trajectory and speed of each aircraft
• Need real-time data storage and retrieval
• + temporally accurate data
– Depends on the speed at which the data changes
 Compounding Factors

• Failures
– Need to ensure that the system operates in real-time in spite of the
loss of some
• Nodes or links? Application
• Actuators or sensors? independent Application
dependent
• Multiple tasks running on one machine
Scheduling
– periodic?
• Same periods or different periods?
– + aperiodic?
• One task running on multiple machines
– Decomposition and parallel processing, e.g., radar processing
• General: Multiple tasks on multiple machines
– General schedulability analysis
 Compounding Factors

• Embedded systems
– Resource constraints
• Memory limitations → Assembly language programming?
• Power constraints
• Heat dissipation These limit the computing capability
• Weight constraints and complicate the software
• Hardware constraints
– Noise
Will be discussed in
– Hardware/software tradeoffs
more detail later
• Sampling period
 Examples of Real-Time Programs

• A) Simple system
– Set timer to interrupt periodically with period T
– Example:

y
– What should be the value of T?
• Large sample period → Oscillation
• Small sample period → Too much computation overhead
 Examples of Real-Time Programs

• A) Simple system
– Set timer to interrupt periodically with period T
– How to choose T?
• Rise time R → Time taken by the plant to reach close to the final state
in response to a step change in the reference input
• Rule of thumb: 10 ≤ R/T ≤ 20
– I.e., 10 to 20 samples within the rise time
• Bandwidth ω ≅ 1/(2R) Hz
– ∴ Sampling rate, 1/T ∈ [20,40] × ω

• Nyquist Sampling Theorem

– Any time-continuous signal of bandwidth ω can be reproduced
faithfully from its sampled values iff 1/T ≥ 2 ω.
 Examples of Real-Time Programs

• B) Multirate system
– More than 1 degree of freedom
– For example, rotation speed, temperature, etc.
• Assume that a higher sampling rate is needed to control the rotation
speed as compared with controlling the temperature
• Use the highest sampling rate?
– Wastes processor time
(xf,yf)

(x0,y0)
– Move car from (x0,y0) to (xf,yf) along the specified road
• Need to control the speed and the direction
 Examples of Real-Time Programs

• B) Multirate system
(xf,yf)

(x0,y0)

– Move car from (x0,y0) to (xf,yf) along the specified road

• Need to control the speed and the direction
– Speed controller
• Adjust the speed to reach (xf,yf)
– Direction controller
• Adjust t he direction to stay on the road
• Reduce the speed to ensure correct response with the given sampling
period depending on the curvature of the road
– Sharper curvature ⇒ slower speed
 Examples of Real-Time Programs

• C) Hierarchical control system

Response
– Higher levels → Planning
Command

• For example, Flight Management Operator-system interface

System chooses flight path to arrive -

at the next waypoint at the assigned ATC State
estimat Sensors

time using as little fuel as possible or

-
– Constrained fixed-time, minimum- Flight
State
estimat
Navigatio
n
or
fuel problem Management

• Late flight → Arrive at the next - State

waypoint in the shortest time Flight
estimat
or

control Air data

– Time-optimal problem
Aircraft
 Examples of Real-Time Programs

• D) Multimedia applications
– Compression to satisfy bandwidth constraints
• Example of computing/bandwidth tradeoffs
• Common standard: MPEG Compression/Decompression
– Stream synchronization
• Audio/video must be closely synchronized
• “Lip synchronization”
 Hardware/Software Issues

• Real-time systems operate in the physical world

– This drives the timing constraints/requirements

Cat A looks at the monitor and is interested

Cat B looks at the monitor and doesn’t seem to

recognize any pictures

Which is the smarter cat?

Cat B is smarter
→ Higher visual processing ⇒ the cat sees lines on the monitor instead
of pictures
→ To please this cat, the timing requirements for the refresh rate will be
more demanding
 Hardware/Software Issues

• Real-time systems operate in the physical world

– This drives the timing constraints/requirements

A B
– Which situation requires more processing capability?
• B → “hardware” provides less margin for error
 Hardware/Software Issues

• Real-time systems operate in the physical world

– This drives the timing constraints/requirements
– Better sensors, better actuators, faster processors, more bandwidth
can simplify the software
• Unless the requirements become more ambitious, e.g.:
– Higher resolution
– More features
 Timing Constraints

• Release time
– Time when the job becomes available for execution
• Absolute deadline
– Time when the execution must be completed
• Relative deadline
– Maximum response time

Relative deadline
Time axis
Release time Deadline
 Timing Constraints

• Hard v/s soft deadlines

Value axis

Telephone switches
→ Eventually customer may hang up if
Hit a ball there is no dialtone
Time axis
Stock quote

“Better never than late”

A real-time system that has → E.g., decide to overtake a car on a
at least one hard deadline is two lane road
a HARD real-time system
→ otherwise, it is a
SOFT real-time system
?
 Timing Constraints
Hard Real-Time Systems Soft Real-Time Systems
• Have at least one hard • No hard deadlines
deadline
• Predictable peak load • Tolerate performance
performance degradation
• Active redundancy • Checkpoint/recovery

• Often safety-critical • Non safety-critical

• Guaranteed response • Best-effort response

systems systems
• No probabilistic • Especially during
arguments for peak failures
loads, etc.
 Other Characteristics of Real-Time Systems

• Fail-safe v/s fail-operational systems

– Fail-safe systems can quickly reach a safe state
• E.g., automobile control system
– Fail-operational systems must be designed to operate in spite of
failures
• E.g., air-craft control systems
• Event-triggered v/s time-triggered systems
– Event-triggered systems react to external stimuli
• E.g., responding to user commands
– Time-triggered systems react to passage of time
• E.g., needed for hard real-time communication systems
 Basics of Developing for Embedded Systems
(Chapter 2 of the Book by Li and Yao)
• Characteristics of embedded systems
• Cross-platform development methodology
• Code creation process
• Mapping executable images into target embedded systems
• Custom sections
• Detailed example

Characteristics of Embedded Systems

• Embedded processors
– Low power, low cost to high performance
– Application-specific processors
• For example
– DSP for cell phone
– 16-bit processors for PDA
– Parallel processors for missile defense system

• Hardware/software co-design
– Software can take advantage of special hardware features for better
performance
– Hardware can be simplified if some functionality can be pushed to
the software
• E.g., floating point operations

1
 Characteristics of Embedded Systems

• Cross-platform development
– Develop software of a host platform
• This will have sophisticated software development tools for
debugging and analysis
– Cross-compiler generates object code for the target platform
• E.g., Wind River DIAB compiler runs on MS Windows and generates
code for Motorola 68000, etc.
Target resident
Host system software

Host resident Serial

Target board
software
BDM/JTAG

Ethernet

Characteristics of Embedded Systems

• Memory
– Code is stored in
• ROM  Read Only Memory
– Programmed at manufacturing time
• PROM  Field Programmable ROM
• EPROM  Erasable Programmable ROM
– Must be removed from its housing unit and reprogrammed using a
special hardware device
– Erased using UV light
• EEPROM  Electrically Erasable Programmable ROM
– Can be reprogrammed without any special device and without removing
the memory unit from its casing
– However, it can take a long time to reprogram the memory unit
• Flash memory  Faster than EEPROM

2
 Characteristics of Embedded Systems

• Memory
– Choice of memory is influenced by need for upgrading the
software once the devices are in operation (field use)
• PROM, EPROM are inexpensive but costly to reprogram
• EEPROM, flash memory can be upgraded dynamically
• Hard real-time embedded systems
– Precision/time trade-offs
• E.g., consider a missile defense system
– Sufficient reaction time
» Use one missile to shoot down an incoming missile (precise
trajectory)
– Insufficient reaction time
» Estimate and use multiple missiles to hit an incoming missile
(imprecise trajectory)

Cross-Platform Development Methodology

• Development tools offered by the host system

– Cross compiler
– Linker
– Source-level debugger
• Tools on the target embedded system
– Dynamic loader
– Link loader
– Monitor
– Debug agent
• Connections
– Download program images from the host system to the target
system
– Transmit debugger information between the host debugger and the
target debug agent

3
 Cross-Platform Development Methodology

• Program image
– System software
– RTOS
– Kernel
– Application code
• Chapter 2 of the book by Li and Yao focuses on the ELF
object file format
– ELF  Executable and Linking Format
– The linker and linker command file
– Mapping the executable image onto the target embedded system

Code Creation Process

Makefile C/C++ source + headers (.c/.cpp/.h/.hpp)
• Developer writes C/C++ source
Assembly source + headers (.s/.h)
header files + assembly files
• Developer creates “makefile” make utility Link command file (.lnk)

– Used by “make” utility to track

Preprocessor
file modifications and invoke
the compiler and assembler to
rebuild the object files Compiler

• Linker command file instructs Assembler

the linker on how to combine
the object files and where to Object files (.o)
place the binary code and data
in the target embedded system Library files

Linker and locator

Relocatable Shared object Executable image Link map

file (.o/.a) file (.o/.a) (.elf/.coff/.hex/.out) (.map)

4
 Code Creation Process

• Loader address v/s run address

– Loader
• Stored in ROM
• Function
– Copies initialized variables into RAM
– Transfers the program code into RAM
– Begins execution out of RAM
• Physical ROM storage address for the loader is the “load address”
– Run address
• Location where the program is at the time of execution

Mapping Executable Images into Target

Embedded Systems
• Output of compilers and assemblers
– Multiple object files
– There can be different sections in an object file
• Program code and constant data
• Uninitialized data
• Initialized data
• Symbol table
• String data for program symbols and section names
• Relocation information
• Linker merges the sections from different object files to
create a single executable image for the target embedded
system
– Uses the linker command file

5
 Mapping Executable Images into Target
Embedded Systems
• Linker command file
– Contains directives to control how the linker combines the sections
and allocates the segments into the target system
– MEMORY directive
• Used to describe the target system’s memory map
CPU – List of different types of memory (e.g., RAM, ROM, Flash) available on
the target + the corresponding address ranges
0x00000h
Address bus ROM
0x0001F h
0x00040 h
Data bus Flash
0x0103F h
0x10000 h
RAM Flash ROM RAM
0x1FFFF h
MEMORY {
ROM: origin = 0x00000 h, length = 0x00020 h /* 32 bytes */
FLASH: origin = 0x00040 h, length = 0x01000 h /* 4,096 bytes */
RAM: origin = 0x10000 h, length = 0x10000 h /* 65,536 bytes */
}

Mapping Executable Images into Target

Embedded Systems
• Linker command file
– Contains directives to control how the linker combines the sections
and allocates the segments into the target system
– SECTION directive
• Used to specify
– (a) Which input sections are to be combined into which output section
– (b) Which output sections are to be grouped and allocated in contiguous
memory
– (c) Where to place each section
• Example
SECTION {
output-section-name: | contents | > area-name

GROUP {
[ALIGN (expression) ]
section-definition

} > area-name
}

6
 Mapping Executable Images into Target
Embedded Systems
“loader” section “loader” section .text section
• Detailed example code/data code/data code
(file1.o)

SECTION {
.text: .text section .text section “my_section”
{my_section code .text code
*(.text) (file1.o)
} .text
(file2.o)
 my_section
(file2.o)

Combine the input section

.data section .data section .data section
named my_section and the
data .data data
default .text sections into the (file1.o)
final output .text section .data
(file2.o)
.bss section .bss section .bss section
data .bss data
(file1.o)
.bss
(file2.o)

Mapping Executable Images into Target

Embedded Systems
“loader” section
• Detailed example code/data
(file1.o)

SECTION {
.text: .text section
Combine the input section
{my_section .text 0x00000h
named my_section and the (file1.o)
*(.text) default .text sections into the ROM
} .text 0x0001F h
final output .text section (file2.o) 0x00040 h
my_section Flash
(file2.o) 0x0103F h
Loader section is 0x10000 h
loader : > FLASH placed into Flash
RAM
.data section 0x1FFFF h
memory .data
(file1.o)
GROUP ALIGN(4) Sections .text, .data, .data
{ .text, .bss are grouped (file2.o)
.data : { } together and allocated .bss section
.bss : { } in contiguous physical .bss
(file1.o)
} > RAM RAM memory aligned
} .bss
on the 4-byte boundary (file2.o)

7
 Custom Section
• Why define custom sections and map these into different
target memory areas?
– Module upgradeability
• For example, upgradeable loader:
– Initial version  Transfer image from ROM to RAM
– Updated version  Transfer image from the host over the serial connection
to RAM
• Use a custom loader section
– Put loader code and data section in a custom loader section
– Place this entire section in the flash memory for easy upgradeability
– Memory size limitation
• Impossible to fit all the code + data into one type of memory
• Divide the program into multiple sections and have some sections
allocated to one type of memory (e.g., SDRAM  fast memory) and other
sections into another type of memory (e.g., DRAM  slow memory)
– Data protection
• Keep constants into ROM to avoid accidental modification
– Treat as a special data section which is allocated into ROM

Detailed Example
• Application
• Memory • _loader: 10 KB, Read only
– 256 bytes of ROM • _wflash: 2 KB, Read only (flash programmer)
– 16 KB of flash memory • .rodata: 128 bytes, Read only (constants)
– 128 KB of SDRAM • .sbss: 10 KB, Read/write (uninitialized data)
– 2 MB of DRAM • .sdata: 2 KB, Read/write (initialized data)
• .bss: 128 KB, Read/write (uninitialized data)
• .data: 512 KB, Read/write (initialized data)
• _monitor: 54 KB, Read only (monitor code)
• Allocation • .text: 512 KB, Read only (other program code)
MEMORY { ROM: origin = 0x000000 h, length = 0x000100 h
FLASH: origin = 0x000110 h, length = 0x004000h
RAM0: origin = 0x005000 h, length = 0x020000 h
RAM1: origin = 0x025000 h, length = 0x200000h
}
SECTION { ..rodata : > ROM // Because read only
_loader : > FLASH // Execute at start up; use flash to enable updates
_wflash : > FLASH // Need flash memory programmer to do the update;
// this can also be updated
_monitor : > RAM0 // Should be responsive to user commands, use faster SDRAM
.sbss (ALIGN 4) : > RAM0
.sdata (ALIGN 4) : > RAM0 Use left over portion of SDRAM fully
.text : > RAM1
.bss (ALIGN 4) : > RAM1 Use RAM1 which is the only portion that can
.data (ALIGN 4) : > RAM1 accommodate these large section
}

8
 Embedded System Initialization
(Chapter 3 of the Book by Li and Yao)
• Chapter 2  How to construct an executable image with
multiple program sections according to the target system
memory layout
• Now  How to execute the final image on the target
– Image transfer from the host to the target system
– Target system loader
– Embedded system booting process
– Initialization procedures
– BDM and JTAG interfaces

Target System Tools and Image Transfer

• Possible methods of loading the image

– Program the entire image into the EEPROM or flash memory
– Use a serial (e.g., RS-232) bus or network connection
• Needs a data transfer utility on the host + a loader, monitor, or debug
agent on the target
– Use a JTAG or BDM interface

1
 Target System Board
• Possible method for the final product
– Burn entire executable image into ROM or flash memory
• Only ROM  Set the ROM chip into its socket on the target board
• ROM and flash memory  Need to set jumpers
– Jumpers  Part of the target board’s wiring that controls which memory chip the
processor uses to start executing its first set of instructions upon reboot
– E.g., image is stored in flash memory
» Jumpers are set to use the flash memory
» Processor fetches the first instruction from the starting address where the
flash is mapped
Boot Image
BDM/JTAG
Loader
Boot RAM
Monitor
ROM

Microprocessor
Jumpers
Flash
Pins

Target System Board

• Method for the development Process

– Production method is not practical during the development stage
because of constant changes
– Instead, download the image directly into the target system’s RAM
over a serial bus or network connection
– Or, download the image through a JTAG or BDM interface

2
 Embedded Loader

• Development phase
– Write a loader program to work with a data transfer utility on the
host side to download the image from the host
• Loader has a small memory footprint
– Typically programmed into a ROM chip
– Basic loaders use the serial connection to download the image
– More sophisticated loaders download images over the network using
TFTP (Trivial FTP) or FTP
– Loader transfers control to the downloaded image after the transfer
completes
– ROM also contains the boot image
• Boot image  Code that executes on system power up
– Initializes the target hardware (memory, RAM) into a known state
– Prepares the system to execute the loader which runs after the boot
image completes the necessary initialization work

Embedded Monitor

• An embedded monitor is an alternative to the boot image +

loader approach
– The monitor is provided by the target system manufacturer for its
evaluation boards
– Enables developers to examine and debug the target system at run
time
– Executed on power up
– Performs system initialization
• Initialize the required peripheral devices
– Serial interface
– System timer chip for memory refresh
• Initialize the interrupt controller and install default interrupt handlers

3
 Embedded Monitor

• Monitor enables the developer to

– Download the image
– Read from or write to system memory locations
– Read and write system registers
– Set and clear different types of breakpoints
– Single-step instructions
– Reset the system
• Monitor can be accessed while the downloaded image
executes by using special keystrokes (e.g., CTRL + D)
– Takes control from the application tasks
– Enables interactive debugging activities

Target Debug Agent

• A target debug agent is similar to a monitor with one added

feature
– It gives the host debugger enough information to provide visual
source-level debug capability
– Host debugger is offered by the host tools vendor
– Sometimes the RTOS vendor offers a host-based debugger because
the debug agent is an integral part of the RTOS

4
 Target Boot Scenarios

• System startup (bootstrap) code resides in ROM, flash, or

other non-volatile memory devices
• Example
– Embedded loader is in flash memory
– Target image contains various program sections
– Reset vector is stored in a small ROM mapped to location 0x0 h
• Upon power up, the processor fetches and executes code from a
predefined and hardwired location
• Code contained at this memory location is the reset vector
• To keep the reset vector small, it is usually a jump instruction to the
real initialization code
– ROM contains initial values, including the reset vector, initial stack
pointer, and usable RAM address

Power/Reset Target Boot Scenarios

Processor
Fetch & Execute 0x00000 h
ROM 0x0001F h
Execute the Reset Vector is at 0x00000 h
Reset Vector 0x00040 h
FLASH
0x0103F h
Execute 0x10000 h
Loader Code comes
from FLASH RAM
Initialize 0x103FF h
Hardware
• Reset vector is a jump instruction to
memory location 0x00040 h containing the

Image in Download Image startup initialization code

ROM/FLASH? No from Host • Put system into a known state
into RAM
• Reset registers, stack pointer
Yes • Disable system interrupts
Copy Image from ROM/FLASH Execute the • Initialize RAM/on-board cach
to RAM. Reset Vector
Initialize code during copy • Initialize system devices needed by
the loader
• Transfer application image (RTOS,
Execute the kernel, application code) to the target
new image system

5
 Executing from ROM Using RAM for Data
• Limited memory resources  Execute
image directly out of ROM (can be flash, CPU
etc.) IP

• Boot sequence 1 SP
– (1) CPU’s IP (Instruction Pointer) is hardwired ROM RAM
to execute the first instruction in memory (the Reset
reset vector) Vector
– (2) The reset vector jumps to the first 2
instruction of the .text section of the boot
.text
image Boot Copies 3
• The code initializes the memory Image .data .data
– (3) The .data section of the boot image is .bss Reserves .bss
copied into RAM because it is both readable 4
and writeable stack
5 6
– (4) Stack space is reserved in RAM for the .bss
section of the boot image because it is both
readable and writeable
The CPU continues to
• There is nothing to transfer because the content
for the .bss section is empty execute the code in the
– (5) Stack space is reserved in RAM
.text section until it is
– (6) The CPU’s SP (Stack Pointer) register is set
to point to the beginning of the newly created completed or until the
stack system is shut down

Executing from RAM After Image Transfer from ROM

• Boot loader transfers an application
image from ROM to RAM for CPU
execution IP
– The large application image is stored 1 SP
in ROM in a compressed form to Re-init SP
reduce the storage space required ROM RAM
• The loader must decompress this Reset Reusable
image before it can initialize the Vector memory
sections of that image 2 space
• First 6 steps are identical to the .text
previous scenario Boot Copies 3
Image .data .data 12
– (7) The compressed application
image is copied from ROM to RAM .bss Reserves 4 .bss
– (8), (9), and (10) Initialization steps
6
stack
that are part of the decompression Initial 5
procedure are completed Copies
Compressed .text .text 11
– (11) Loader transfers control to the Boot Image Copies
8 Final
image .data .data
Boot
– (12) Memory area used by the loader .bss
9 .bss Image
Reserves
is recycled 7 10
• SP is reinjitialized to point to this
area so it can be used as the stack for
the new program
Work area used for decompressed image

6
 Executing from RAM After Image Transfer from Host
• Target debug agent transfers an application
CPU
image from the host system into RAM for
IP
execution
– Useful for later development phases when the SP
1
majority of the device drivers have been fully ROM
implemented and debugged Reset RAM
• The system can handle interrupts and Vector
exceptions correctly 2
• The debug agent communicates with the Debug .text Copies 3
host debugger to transfer the target image Agent .data Reserves .data
.bss 4 .bss
• The debug agent can also function as a 6
standalone monitor 5 stack
Executable image 10
• The first 6 steps are same as before .text Copies
.text
– (7) The application image is downloaded Copies
13
.data 11 .data
from the host system Final
.bss Reserves
Executable
– (8) The image integrity is verified .bss
– (9) The image is decompressed if necessary 12 Image

– (10) – (12) The debug agent loads the image .text

section into their resp. addresses in RAM Initial
.data Executable
– (13) The debug agent transfers control to the Image
.bss
downloaded image 8 9
7
• The debug agent stays in memory to help with
Download
interactive, visual, source-level debugging

Target Software Initialization Sequence

Application


• BSP contains a full spectrum

Other Embedded Components
of drivers for the system and Modules
hardware components and
Software

Protocol Stacks (e.g., TCP/IP)

devices
Real-Time Operating System
• Initialization consists of (RTOS)
– Hardware initialization Board Support
– RTOS initialization Package (BSP)

– Application initialization BDM/JTAG

Boot RAM
ROM
Hardware

Microprocessor

Flash
Jumpers

Pins

7
 Hardware Initialization

• (1) Start execution at the reset vector

• (2) Put t he processor into a known state by setting
appropriate registers
– Get the processor type
– Get/set the CPU’s clock speed
• (3) Disable interrupts and caches
• (4) Initialize memory controllers, memory chips, and cache
units
– Get the start address for the memory
– Get the size of the memory
– Perform preliminary memory test, if required

Hardware Initialization

• (5) Copy and decompress (if necessary) the sections of the

code that need to run
– Also, copy and decompress its data into RAM
• (6) Other hardware components are initialized
– Set up exception handlers
– Initialize interrupt handlers
– Initialize bus interfaces, e.g., VME, PCI, USB
– Initialize board peripherals, e.g., serial, LAN, SCSI
• At the end of this process, all of the target system hardware
is initialized and a set of function calls are provided that
can be used by upper layers of software (e.g., RTOS) to
communicate with the hardware components of the target
system

8
 RTOS Initialization

• (1) Initialize the RTOS

• (2) Initialize different RTOS objects and services, e.g.:
– Task objects
– Semaphore objects
– Message-queue objects
– Timer services
– Interrupt services
– Memory management services
• (3) Create necessary stack for RTOS
• (4) Initialize additional RTOS extensions, e.g.:
– TCP/IP stack
– File system
• Start the RTOS and its initial tasks

Application Software Initialization

• Declare and implement all necessary objects, services, data

structures, variables, etc.
• For example, create tasks that are executed once the kernel
scheduler runs

9
 On-Chip Debugging

• Need built-in microprocessor debugging

– Called on-chip debugging (OCD)
• BDM and JTAG are two types of OCD solutions that allow
direct access and control over the microprocessor and
system resources without needing software debug agents
on the target or expensive in-circuit emulators
• An embedded processor with OCD capability provides an
external interface which can be used to download code,
read or write processor registers, modify system memory,
and command the processor to execute one instruction and
halt (needed for single-step debugging)
• OCD Solves the chicken-and-egg problem
– If the monitor is the tool for debugging a running program, what
debugs the monitor while it is being developed?

On-Chip Debugging
• JTAG
– Joint Test Action Group
– Founded by electronics manufacturers to develop aa new and cost-
effective solution for OCD
• Result is the IEEE 1149.1 standard
• BDM
– Background Debug Mode
– Introduced by Motorola and is found on its processor chips
• In both cases, a host debugger provides the interface
between the embedded software developer and the target
processor and its resources
– Registers
– System memory dump
– Currently executing instruction

10
 Introduction to Real-Time Operating Systems
(Chapter 4 of the Book by Li and Yao)
• Brief history of operating systems
• Definition of an RTOS
• Description of the scheduler
• Key characteristics of an RTOS

Brief History of Operating Systems

• Early days of computing

– Software applications included low-level machine code to initialize
and interact with the system’s hardware directly
• Still the way for some embedded systems with relatively simple
hardware and software
– Problem  Non-portable applications
• Small changes in the hardware can trigger the need to recode much of
the application itself
– Difficult and costly to maintain these systems

• Operating systems evolved and facilitated the abstraction

of the underlying hardware from the application code
– Also helped shift the design of software applications from large,
monolithic systems to more modular, interconnected systems that
could run on top of the OS environment

1
 Brief History of Operating Systems
• Many versions of operating systems have evolved
– General purpose OS (GPOS)
• Unix
– Multi-user access to expensive, limited-availability computing systems
– Ported to all types of machines, from microcomputers to supercomputers
• Microsoft Windows
– Emphasizes the PC environment
– User interacts with PC via a GUI
– Smaller and more compact real-time OS
– VxWorks

• Similarities between a typical RTOS and GPOS

– Some level of multitasking
– Software and hardware resource management
– Provision of underlying OS services to applications
– Abstracting the hardware from the software application

Brief History of Operating Systems

• Differences between a typical RTOS and GPOS
– Better reliability in embedded application context
– Ability to scale up or down to meet application needs
– Faster performance
– Reduced memory requirements
– Scheduling policies tailored for real-time embedded systems
– Support for diskless embedded systems by allowing executables to
boot and run from ROM or RAM
– Better portability to different hardware platforms
• Current GPOSs
– Mainly on PCs, workstations, mainframes
– Embedded devices that have ample memory and very soft real-time
requirements
– Not suitable for embedded devices with limited
memory and high performance requirements

2
 Defining an RTOS
• An RTOS is a program that schedules execution in a timely
manner, manages system resources, and provides a consistent
foundation for developing application code
– Scalable in order to meet different sets of requirements for different
applications, from a stopwatch to aircraft navigation
• In some applications, an RTOS consists of only a kernel
– Core supervisory software that provides minimal logic, scheduling, and
resource management algorithms
– Every RTOS has a kernel
• RTOS for larger systems can include the kernel, a file system,
networking protocol stacks, etc.
• Most RTOS kernels contain the following components
– Scheduler  Follows a set of algorithms that determines which task
executes when
– Objects  Examples include tasks, semaphores, and message queues
– Services  Operations that t he kernel performs, e.g., timing,
interrupt handling, and resource management

Scheduler

• Provides the algorithms needed to determine which task

executes when
– Schedulable entities
• Any kernel object that can compete for execution time on the system
– Task  Independent thread of execution
– Process  Provides better memory protection features than tasks at the
expense of performance and memory overhead
• Examples of non-schedulable entities
– Message queues and semaphores
– Multitasking
• Ability of the OS to handle multiple activities within specified
deadlines
• As the number of tasks to schedule increases, so do CPU performance
requirements
– Because of the increasing number of context switches

3
 Scheduler
• Provides the algorithms needed to determine which task
executes when
– Context switch
• Context of a task  State of the CPU registers required each time it is
scheduled to run
• To switch from task A to task B, the scheduler needs to
– Save tasks A’s context in its TCB (Task Control Block)
– Load task B’s context from its TCB
– Transfer control to task B
• Context switch time
– Time it takes for the scheduler to switch from one task to another
– Dispatcher
• Part of the scheduler that performs context switching and changes t he
flow of execution
– Scheduling algorithms
• Clock-driven and priority-driven algorithms
• Some RTOSs allow developers to create and define their own
scheduling algorithms

Key Characteristics of an RTOS

• Reliability
– Determined by the combination of all system elements, including
the hardware, BSP, RTOS, and application
• 5 nines (99.999%) availability
–  5 minutes downtime per year
– Carrier-class server
• 6 nines (99.9999%) availability
–  31 seconds downtime per year
– Carrier switch equipment

• Predictability
– Meeting time requirements is essential to ensuring proper
operation
– RTOS needs to be deterministic
• OS calls must complete within known timeframes

4
 Key Characteristics of an RTOS

• Performance
– Must be fast enough to meet timing requirements
• Compactness
– Embedded system requirements can limit system memory
• This, in turn, limits the size of the application and OS
• Scalability
– Must be able to scale up or down to meet the needs of a wide
variety of embedded applications
• Should enable adding or removing modular components, e.g., file
system and protocol stack

5
 Modularizing an Application for Concurrency
(Chapter 14 of the Book by Li and Yao)
• Overview of the decomposition process
– Designing real-time embedded applications needs identification of
several elements
• (1) System requirements
• (2) Inputs and outputs
• (3) Real-time deadlines
• (4) Events and event response times
• (5) Event arrival patterns and frequencies
• (6) Required objects and other components
• (7) Tasks that need to be concurrent
• (8) System schedulability
• (9) Useful or needed synchronization protocols for inter-task
communication
• Guidelines and recommendations for identifying
concurrency

Overview of the Decomposition Process

• Designing real-time embedded applications needs

identification of several elements
• Depending on the design methodology and modeling tools,
the list of steps can vary
• However, regardless of the methodology, eventually the
design team must consider how to decompose the
application into concurrent tasks
• At the completion of the application decomposition
process, schedulability analysis must be performed to
determine whether the system is schedulable
– A real-time system is considered schedulable if every task in the
system can meet its deadline

1
 An Outside-In Approach to Decomposing Applications
• First capture detailed requirements in a document, e.g. a
Software Requirements Specification (SRS) document
• Outside-in decomposition method
– Identify inputs and outputs of a system and express them in a single high-
level context diagram
– Example of a high-level context diagram for a mobile handheld device

• The mobile handheld unit Antenna

provides interfaces for the
following I/O LCD LCD
RF Output Output
• Antenna, speaker, volume RF Input
control, keypad, microphone, Microphone
and LCD Input
• Inputs Speaker Microphone
• RF input, volume input,
keypad input, and Volume Keypad
microphone input Input Input
•Outputs
• RF output, speaker output, Volume
Keypad
and LCD output Control

Initial Decomposition
Example: Mobile
Antenna
handheld unit
RF Input RF Output

LCD
Receive Send Output LCD
Input Output

Print to
LCD

Output Sample
Speaker
Signal Signal
Process
Inputs Microphone
Microphone
Input
Volume Keypad
Input Input
Volume
Keypad
Control

2
 Initial Decomposition
• The initial tasks are along the
Antenna
edges of the application RF RF
Input Output
–  They probably must interact with Receive Send
LCD
Output LCD
the outside world Input Output
Print to
• This is why this decomposition LCD
Output Sample
process is called the “outside-in” Speaker Signal Signal
Process
method Inputs Microphone
Microphone
Volume
• A design team can continue this way Input Keypad
Input
Input
to decompose the overall application Volume
Control
Keypad
into tasks
• These tasks are not the only ones
required, but the process provides
a good starting point
– Additional tasks may be identified
– Existing tasks may be combined as
more details are considered

Units of Concurrency

• Task, process, or any schedulable thread of execution that

can compete for the CPU’s processing time is a “unit of
concurrency”
• ISRs should also be considered because they follow a
preemptive policy and are units of execution competing for
CPU processing time
• Pseudo versus true concurrent execution
– Concurrent tasks running on a single processor
• Pseudo concurrent execution
– Concurrent tasks running on multiple processors
• True concurrent execution
• The underlying RTOS in this case is typically distributed
– Various components, or copies of RTOS components, can execute on
different processors

3
Guidelines and Recommendations for Identifying
Concurrency
• Guideline 1: Identify device dependencies
– Guideline 1a: Identify active I/O devices
– Guideline 1b: Identify passive I/O devices
• Guideline 2: Identify event dependencies
• Guideline 3: Identify time dependencies
– Guideline 3a: Identify critical and urgent activities
– Guideline 3b: Identify different periodic execution rates
– Guideline 3c: Identify temporal cohesion
• Guideline 4: Identify computationally bound activities
• Guideline 5: Identify functional cohesion
• Guideline 6: Identify tasks that serve specific purposes
• Guideline 7: Identify sequential cohesion

Guideline 1: Identify Device Dependencies

• All real-time systems interface with the physical world

through some devices, such as sensors, actuators,
keyboards, or displays
• Outside-in approach focuses on looking at the I/O devices
in a system and assigning a task to each device
– Basic concept: Unsynchronized devices need separate handling
– For simple device interactions, processing within an ISR may
suffice
– For additional device processing, a separate task or set of tasks
may be assigned

4
 Active I/O Devices
Active I/O Devices
Produce Interrupts

Input Devices Output Devices

Synchronous Asynchronous Synchronous Asynchronous

• Active I/O devices generate interrupts to communicate with an

application
– Synchronous active devices
• Generate interrupts in a periodic fashion or in sync with other active devices
– Asynchronous active devices
• Generate interrupts apriodically, or asynchronously, w.r.t. other devices

Passive I/O Devices

Passive I/O Devices
Do Not Produce Interrupts

Input Devices Output Devices

• Passive I/O devices do not generate interrupts

•  the application must initiate communication with a passive
I/O device
– This can be done in a periodic or aperiodic fashion
– Periodic method is called “polling the device”
– Low polling frequency  Missed data or signal
– High polling frequency  Extra performance overhead

5
 Guideline 1a: Identify Active Devices

• Typical tasks that can result from identifying an active I/O

device
– Asynchronous active device I/O task
– Synchronous active device I/O task
– Resource control device I/O task
• Assigned for controlling the access to a shared I/O device or group of
devices
– Event dispatch device I/O task
• Assigned for dispatching events to other tasks from one or more I/O
devices

Guideline 1a: Identify Active Devices -

Recommendations
• (1) Assign separate tasks for separate active asynchronous I/O
devices
– Each device has its own rate and uses interrupts
• (2) Combine tasks for I/O devices that generate infrequent
interrupts having long deadlines
• (3) Assign separate tasks to devices that have different input and
output rates
– Generally, a task that handles a device with a high I/O frequency should
have a higher task priority than a task that handles a device with a lower
frequency
• (4) Assign higher priorities to tasks associated with interrupt
generating devices
– Periodic interrupts
• Interrupt period dictates how long a task must handle processing
• If the period is very short, tasks associated with these devices need to be set at
high priorities

6
 Guideline 1a: Identify Active Devices -
Recommendations
• (4) Assign higher priorities to tasks associated with interrupt
generating devices
– Aperiodic interrupts
• Generally these types of tasks need high priorities to ensure that all
interrupt requests can be handled, including those that occur within short
time interrupts
• (5) Assign a resource control task for controlling access to I/O
devices
– This task receives I/O requests from different tasks and sends the I/O
requests in a controlled and sequential manner to the I/O device
– One resource task can handle multiple requests that might need to be
dispatched to one or more I/O devices
• (6) Assign an event dispatch task for I/O device requests that
need to be handed off to multiple tasks
– The event dispatch task receives all requests from I/O devices and
dispatches them to the appropriate task

Guideline 1b: Identify Passive Devices

• Typical tasks for a passive I/O device

– Aperiodic passive device I/O task
• Assigned to passive I/O devices and issues requests to these devices
on an as-needed basis
– Periodic passive device I/O task
• Assigned to passive I/O devices and polls these devices in a periodic
fashion
– Resource control device I/O task
• Assigned for controlling the access to a shared hardware device or a
group of devices
– Event dispatch device I/O task
• Assigned for dispatching events to other tasks from one or more I/O
devices

7
 Guideline 1b: Identify Passive Devices -
Recommendations
• (1) Assign a single task to interface with passive I/O devices
when communication with such devices is aperiodic and when
deadlines are not urgent
• (2) Assign separate polling tasks to send periodic requests to
passive I/O devices
– Assign a separate task to each passive I/O device that needs to be polled at
different rates
• (3) Trigger polling requests via timer events
– Do not use a timer delay within a loop that is equal to the period of the
sampling rate
• Timing will not be accurate (due to interrupts and preemptions)
– Instead, use a timer to trigger an event after every cycle

Guideline 1b: Identify Passive Devices -

Recommendations
• (4) Assign a high relative priority to polling tasks with relatively
short periodic
– If the polling period is very short, less time is available to process
incoming data before t he next cycle
–  Assign higher priorities to tasks with faster polling loops
– Need to be careful since heavy polling increases the overhead

8
 Other Guidelines

• Guideline 2: Identify Event Dependencies

– Events in a real-time application can propagate across multiple
tasks
• E.g., error conditions or fault detection
• Such events are propagated outward to an I/O device or an internal
recovery action is taken
– Create a task or a group of tasks to properly handle the event as it
is propagated through the application
• Guideline 3: Identify Time Dependencies
– Need to specify all timing deadlines for the application
– Separate tasks can be designed to handle each deadline
• Task priorities can be assigned based on the criticality or urgency of
each deadline

Other Guidelines

• Guideline 3a: Identify Critical and Urgent Activities

– Critical Tasks  Tasks whose failures can be disastrous
• Deadline can be short or long
– Urgent tasks  Tasks with relatively short deadlines
• Task may or may not be critical
– Urgent and critical tasks are assigned higher relative priorities
• Guideline 3b: Identify Different Periodic Execution Rates
– Periodic activities can be grouped into tasks with similar rates
• Guideline 3c: Identify Temporal Cohesion
– Temporal cohesion  Activities that are always done at the same
time, even though they may be functionally unrelated
• E.g., system initialization tasks
– These activities can be grouped into one task to reduce system
overhead

9
 Other Guidelines

• Guideline 4: Identify Computationally Bound Activities

– Computationally bound activities  Tasks that require a lot of
CPU time relative to other tasks
• Typically have long deadlines
– Can be assigned lower relative priorities to prevent CPU
monopolization and enable more critical tasks to run
• Guideline 5: Identify Functional Cohesion
– Functional cohesion  Tasks that perform closely related activities
• E.g., pass a lot of data between each other
– Group these into a single task to reduce synchronization and
communication overhead

Other Guidelines
• Guideline 6: Identify Tasks that Serve Specific Purposes
– For example, consider a safety task
• Detect problems
• Set alarms
• Notify users
• Take recovery actions
– May need special reliability, security, performance, etc., mechanisms
or assessment techniques for these tasks
• Guideline 7: Identify Sequential Cohesion
– Sequential cohesion  Activities that must be performed in a specific
order
• E.g., Train departure sequence  Sound bell, close door, accelerate, cruise
– Group these activities into one task to further emphasize the
requirement for sequential operation

• Last step: Perform Schedulability Analysis

10