Technical University of Mombasa

EEE 4520: EMBEDDED SYSTEMS

Lecturer: Francisco Omutsani
Email: omutanifrancisco@tum.ac.ke

LECTURE SESSIONS
Session Two: Embedded System Software Architecture.
2.0 Session Objectives
By the end of this session, you should be able to:
 Describe embedded software architecture
 Explain the Architecture & services provided by an Operating System
 Describe the categories of embedded Operating system
 Describe the application Software and Communication Software
 Describe the process of generating Executable Image

2.1 Software Architecture

The software components of an embedded system include all the programs necessary to give
functionality to the system hardware. These programs, frequently referred to as the system
firmware, are stored in some sort of nonvolatile memory. Firmware is not meant to be modifiable
by users, although some systems could provide means of performing upgrades.
System programs are organized around some form of operating system and application routines.
The operating systems can be simple and informal in small applications, but as the application
complexity grows, the operating system requires more structure and formality. In some of these
cases, designs are developed around Real-Time Operating Systems (RTOS).
The THREE major components identified in typical system software include:
1 Tasks
The application software in embedded systems is divided into a set of smaller programs called Tasks. Each
task handles a distinct action in the system and requires the use of specific System Resources. Tasks submit
service requests to the kernel in order to perform their designated actions.
In our microwave oven example the system operation can be decomposed into a set of tasks that include
reading the keypad to determine user selections, presenting information on the oven display, turning on the

TUM is ISO 9001:2015 Certified Omutsani Francisco

1
magnetron at a certain power level for a certain amount of time, just to mention a few. Service requests can
be placed via registers or interrupts.
2 Kernel.
The software component that handles the system resources in an embedded application is called the Kernel.
System resources are all those components needed to help the tasks accomplish its roles. These resources
include memory, I/O devices, the CPU itself, and other hardware components. The kernel receives service
requests from tasks, and schedules them according to the priorities dictated by the task manager. When
multiple tasks contend for a common resource, a portion of the kernel establishes the resource management
policy of the system. For those tasks that need to exchange information among them; the kernel provides a
framework that enables a reliable inter-task communication to exchange information and to coordinate
collaborative operation.
3 Services.
Tasks are served through Service Routines. A service routine is a piece of code that gives functionality to a
system resource. In some systems, they are referred to as device drivers. Depending on the system
architecture Services can be activated by
 polling
 Interrupt service routines (ISR),

2.2 Embedded Software Architectures

There are several different types of software architecture in common use.
5.1. Simple Control Loop
In this design, the software simply has a loop. The loop calls subroutines, each of which manages a part of
the hardware or software.

TUM is ISO 9001:2015 Certified Omutsani Francisco

2
5.2. Interrupt-controlled system
Some embedded systems are predominantly controlled by interrupts. This means that tasks performed by the
system are triggered by different kinds of events; an interrupt could be generated, for example, by a timer in
a predefined frequency, or by a serial port controller receiving a byte.
These kinds of systems are used if event handlers need low latency, and the event handlers are short and
simple. Usually, these kinds of systems run a simple task in a main loop also, but this task is not very
sensitive to unexpected delays.
Sometimes the interrupt handler will add longer tasks to a queue structure. Later, after the interrupt handler
has finished, these tasks are executed by the main loop. This method brings the system close to a
multitasking kernel with discrete processes.
5.3. Cooperative multitasking
A non-preemptive multitasking system is very similar to the simple control loop scheme, except that the
loop is hidden in an API. The programmer defines a series of tasks, and each task gets its own environment
to “run” in. When a task is idle, it calls an idle routine, usually called “pause”, “wait”, “yield”, “nop” (stands
for no operation), etc. The advantages and disadvantages are similar to that of the control loop, except that
adding new software is easier, by simply writing a new task, or adding to the queue.
5.4. Preemptive multitasking or multi-threading
In this type of system, a low-level piece of code switches between tasks or threads based on a timer
(connected to an interrupt). This is the level at which the system is generally considered to have an
"operating system" kernel. Depending on how much functionality is required, it introduces more or less of
the complexities of managing multiple tasks running conceptually in parallel.
As any code can potentially damage the data of another task (except in larger systems using an MMU)
programs must be carefully designed and tested, and access to shared data must be controlled by some
synchronization strategy, such as message queues, semaphores or a non-blocking synchronization scheme.
Because of these complexities, it is common for organizations to use a real-time operating system (RTOS),
allowing the application programmers to concentrate on device functionality rather than operating system
services, at least for large systems; smaller systems often cannot afford the overhead associated with
a generic real time system, due to limitations regarding memory size, performance, or battery life. The
choice that an RTOS is required brings in its own issues, however, as the selection must be done prior to
starting to the application development process. This timing forces developers to choose the embedded
operating system for their device based upon current requirements and so restricts future options to a large
extent.[10] The restriction of future options becomes more of an issue as product life decreases. Additionally
the level of complexity is continuously growing as devices are required to manage variables such as serial,
USB, TCP/IP, Bluetooth, Wireless LAN, trunk radio, multiple channels, data and voice, enhanced graphics,
multiple states, multiple threads, numerous wait states and so on. These trends are leading to the uptake
of embedded middleware in addition to a real-time operating system.

TUM is ISO 9001:2015 Certified Omutsani Francisco

3
5.5. Microkernels and Exokernels
A microkernel is a logical step up from a real-time OS. The usual arrangement is that the operating system
kernel allocates memory and switches the CPU to different threads of execution. User mode processes
implement major functions such as file systems, network interfaces, etc.
In general, microkernels succeed when the task switching and inter task communication is fast and fail when
they are slow.
Exokernels communicate efficiently by normal subroutine calls. The hardware and all the software in the
system are available to and extensible by application programmers.
5.6. Monolithic kernels
In this case, a relatively large kernel with sophisticated capabilities is adapted to suit an embedded
environment. This gives programmers an environment similar to a desktop operating system
like Linux or Microsoft Windows, and is therefore very productive for development; on the downside, it
requires considerably more hardware resources, is often more expensive, and, because of the complexity of
these kernels, can be less predictable and reliable. Common examples of embedded monolithic kernels
are embedded Linux and Windows CE.
Despite the increased cost in hardware, this type of embedded system is increasing in popularity, especially
on the more powerful embedded devices such as wireless routers and GPS navigation systems. Here are
some of the reasons:
 Ports to common embedded chip sets are available.
 They permit re-use of publicly available code for device drivers, web servers, firewalls, and other code.
 Development systems can start out with broad feature-sets, and then the distribution can be configured
to exclude unneeded functionality, and save the expense of the memory that it would consume.
 Many engineers believe that running application code in user mode is more reliable and easier to debug,
thus making the development process easier and the code more portable.
 Features requiring faster response than can be guaranteed can often be placed in hardware.
5.6. Exotic custom operating systems
A small fraction of embedded systems require safe, timely, reliable, or efficient behavior unobtainable with
any of the above architectures. In this case an organization builds a system to suit. In some cases, the system
may be partitioned into a "mechanism controller" using special techniques, and a "display controller" with a
conventional operating system. A communication system passes data between the two.
5.7. Additional Software components
In addition to the core operating system, many embedded systems have additional upper-layer software
components. These components consist of networking protocol stacks like CAN, TCP/IP, FTP, HTTP,
and HTTPS, and also included storage capabilities like FAT and flash memory management systems. If the
embedded device has audio and video capabilities, then the appropriate drivers and codecs will be present in
the system. In the case of the monolithic kernels, many of these software layers are included. In the RTOS
category, the availability of the additional software components depends upon the commercial offering.

TUM is ISO 9001:2015 Certified Omutsani Francisco

4
2.3 Operating System
This the piece of software which provides the function calls that enable the user to interact with
the system hardware. The O.S provides the following functions to the system:
 Process/ Task management
 Memory management
 I/O Device management as well as file managenet
 Provide User interfaces
 Provide services to applications

2.3.1 Categories of Operating system

Based on the capabilties O.S can be divided into the following categories
 Single-tasking Vs Multi-tasking O.S
 Single user Vs Multiple User O.S
 Command driven Vs GUI-based O.S
 Real time Vs non Real Time O.S
 Mobile /handheld Vs Non Mobile O.S

2.3.2 Services provide by an Operating System

Due to the special requirements of embedded system the operating system must adhere to the
following requirements
 Reliability
 Multi-tasking with time constraints
 Small footprint
 Support diskless systems
 Portability
 Scalability
 Support for standard API

2.3.3 Architecture of Embedded systems

To meet the special requirements of the embedded system, the embedded operating system need
to have mechanism of managing the task and to make the task communicate with one another

TUM is ISO 9001:2015 Certified Omutsani Francisco

5
  Task scheduling
 Context switching
 Mutual exclusion
 Intertask Communication
 Memory management
 Timer services
 Kernel
 Device manager
 Communication protocol software
 Libraries
 File system
2.4: Application Software
These are software developed above the operating system. Once you choose operating system ,
you need to obtain their corresponding development tools. These development tools provide
function calls to access the operating system services
For example, if you wish to create a task to read data from a serial port, you will have to make a
function call to create a new task with required priority, write the code to read the data and write
to specified memory location.
2.4.1 Some of the function calls provided by operating systems include:
 To create, suspend, and delete tasks
 To do task scheduling for meeting real time requirements
 To facilitate inter-task communication and synchronization between tasks

TUM is ISO 9001:2015 Certified Omutsani Francisco

6
  To initialize, increment and reset counters to keep track of time
 To allocate and free memory
 To access the I/O devices
 To access the communication protocol stack

2.5 Communication Software

This is the software that is integrated in the firmware in order to provide the embedded
system with network capabilities to communicate with other devices
Similarly the enetworked embedded system can be accessed over a network via LAN WAN
and CAN.
2.5.1 TCP/IP Protocol Suite
This protocol was developed during the initial research on the internet. This led to
the concept of packet switching . Packet switching involves data being transmitted
to be divided into small packet. Each packet is transmitted from the source to the
destination.A packet may take a different route but at the destination all the packets
are put together in sequence and given to the application software. Note that during
transmission some packets may be lost and some may not be received in sequence.
Hence TCP/IP protocols was designed to mitigate against the above problems.
Currently embedded systems are being provided with TCP/IP support to make
them network enabled, this systems include web camera, web TV etc
TCP/IP stack is also being embedded into systems running real time operating
system and handheld operatin system
TCP/IP protocol suite comprises of 5 lat=yers
 Physical layer
 Data link (Network ) layer
 Internet Protocol layer
 Transport layer (TCP and UDP layers)
 Application layer
2.6 process of generating executable image

TUM is ISO 9001:2015 Certified Omutsani Francisco

7
On a desktop computer the procedure for creating and executing the application
software is as follows
 Create the source file
 Create the executable file
 Give the command for execution
 The process is loaded into the RAM by the loader
 Loader transfer the control to the process and the process execution

Application development on desktop computer is called native development as the development

and execution are done on the same hardware platform.
However embedded system application cannot be developed directly on the embedded system
hardware due to its resource constraints, Initially the develpopment is done on the desktop
computer and then the software is transferred to the target embedded system hardware . this is
knowns as a cross platform development.
Hence the procedure for creating and executing an application in an embedded system differes
from that of general purpose systens in the following ways
 On the dsktop computers there is a distinction between the operating system and the
application software, whereas vin an embedded system evetthing is a single piece of code
 In an embeddded system there is only one applicationthat needs to be run continously
whereas on the desktop computer need to run multiple applications.
 In embedded system you need to decide carefully where the code with reside since the
CPU executes the instructions from that memory location , whwereas the desktop it does
matter the location of the code .
 Desktop has a virtual (Secondary) memory wher it can transfer the curent process in oder
to load the interrupting process for execution. Whweas the embedded system does not
have secondary storage.
In general the operating system , communication softeware and application software have to
be converted into a single executable image and transferred to the memory of the embedded
system

TUM is ISO 9001:2015 Certified Omutsani Francisco

8
2.12 Session Summary
Described embedded system architecture overview loop, explained the function of each
building blocks of an embedded system hardware, classified the types of embedded
systems processors and their architecture, described the memory used in embedded
system, described the I/O subsystem used on embedded system and finally discussed the
CPU performance and enhancement
2.13 Student Activity
1. Define the following terminology as applied to embedded system
a. Sensors and Actuators
b. Microcontroller and microprocessor
c. RISC and CISC technology
2. With block diagram describe the following architectures
a. Embedded system Architecture
b. Internal processor architecture
3. Describe any FOUR characteristics of an embedded system
4. With aid of a block diagram distinguish between Von Neumann and Harvard CPU
architecture
5. Discuss the I/O subsystem data transfer schemes.
6. Describe the key CPU performance and enhancement parameters
2.14 Further Readings/References
Core Textbooks
i. Tim Wilmshurt (2009) Designing Embedded Systems with PIC Microcontrollers, Principles
and Applications, Second Edition, Newnes, ISBN-13: 978-1856177504, ISBN-10: 1856177505
ii. Rafiquzzaman M. (2014) Fundamentals of Digital Logic and Microcontrollers, 6th Edition,
Wiley, ISBN: 978-1-118-85579-9
iii. Robert B. R., Bruce J. W., Bryan A. J. (2014) Microcontrollers: From Assembly Language to C
Using the PIC24 Family, 2nd Edition, Cengage Learning PTR. ISBN-13: 978-1305076556,

TUM is ISO 9001:2015 Certified Omutsani Francisco

9
 ISBN-10: 1305076559
Core Journals
i. Journal of Microprocessors and Microsystems: Embedded Hardware Design, ISSN: 0141-
9331
ii. Journal of Electrical Engineering and Electronic Technology, ISSN 2325-9833
iii. International journal of electrical, computer, and systems engineering ISSN: 2077-1231
(Online) /2227-2739 (Print)
Recommended Textbooks
i. Dogan Ibrahim (2014) PIC Microcontroller Projects in C, Second Edition: Basic to
Advanced, 2nd Edition, Newness, ISBN-10: 0080999247, ISBN-13: 978-0080999241
ii. Sabri Cetinkunt (2015) Mechatronics with Experiments, 2nd Edition, Wiley, ISBN: 978-1-
118-80246-5
iii. Ying Bai (2016) Practical Microcontroller Engineering with ARM- Technology, Wiley, ISBN:
978-1-119-05237-1
Recommended Journals
i. IEEE Transactions on Communications ISSN:0090-6778
ii. IEEE journal on Selected Areas in Communications ISSN:0733-8716
iii. Journal of Microcontroller Engineering & Applications, ISSN 2455- 197X

TUM is ISO 9001:2015 Certified Omutsani Francisco

10