Chapter Four

Embedded systems Design issues

Introduction

Embedded systems consist of computer hardware and software; but unlike personal computers or
smartphones, they are designed for a specific function or a set of closely related functions. They
typically perform only one task, while a PC can perform various tasks programming, calculating,
drawing, gaming, etc.

A typical embedded system has the following structure:

Thus, embedded system design requires deep knowledge of both electronics engineering and
programming. Such projects require the following specialists:

1. Project managers have necessary skills to make a rough estimation of the project. They also
organize and supervise the work of the team on a particular project. For customers, PMs are the
main contact person in the development team.

2. A system analyst and a tech lead are responsible for collecting and analyzing the
requirements for the future system and thorough project estimation. The tech lead also designs
the architecture of the future solution.

3. Embedded developers are front-line layout engineers and software engineers responsible for
designing printed circuit boards and coding programs.

4. QA specialists are responsible for testing solutions under development.

To make embedded system development faster, it is better to work on memory management,

hardware and software simultaneously.
4.1. Memory Management

Memory management is crucial in embedded systems because resources are typically limited.
Proper management ensures the system runs efficiently, with minimal risk of crashes or failures
due to memory overflows or fragmentation.

Memory Types and Their Usage

 Program Memory (ROM, Flash):

o Stores the firmware (software code) that controls the system.
o Flash memory is often used because it is non-volatile and can be rewritten.
o Size and speed of the memory influence the overall system performance.
 Data Memory (RAM):
o Used for temporary data storage, including variables, buffers, and stack space.
o RAM is volatile, meaning its contents are lost when power is removed.
o Limited RAM in embedded systems requires efficient memory management to
avoid waste.
 Non-volatile Memory (EEPROM, Flash):
o EEPROM is used to store configuration settings or logs that need to persist
between reboots.
o Flash memory is often used to store large datasets or firmware images.
o Flash management strategies like wear leveling are essential for longevity.

Memory Allocation

 Static Allocation:
o Memory is allocated at compile time. It is predictable and does not require
dynamic allocation mechanisms.
o Used for global variables, constants, and static buffers.
o The main advantage is reduced complexity and better predictability in real-time
systems.
 Dynamic Allocation:
o Memory is allocated at runtime, which provides flexibility but introduces
challenges in real-time systems due to potential fragmentation.
o Heap Allocation: Allocating and deallocating memory dynamically during the
execution of a program.
o Stack Allocation: Local variables are allocated on the stack and freed when the
function exits.
o Memory leaks, fragmentation, and allocation delays must be carefully managed.

Memory Management Techniques

 Memory Protection:
o Protect critical areas (e.g., interrupt vector, firmware, configuration data) from
being overwritten or corrupted.
o Use of watchdog timers and exception handling can mitigate risks.
  Memory Pooling:
o Pre-allocate fixed-size blocks of memory for dynamic use, reducing the overhead
of runtime allocation and fragmentation.
o Can be used to handle real-time, critical tasks where predictable memory access is
needed.
 Garbage Collection (less common in embedded systems):
o Automatic memory management technique used to reclaim unused memory.
Typically used in high-level programming languages like Java but not common in
low-level embedded systems due to resource overhead.
 Wear-Leveling:
o Flash memory has a limited number of write/erase cycles, and wear leveling
ensures that writes are distributed across memory evenly to extend the lifetime of
the memory.

Real-Time Considerations for Memory Management

 Real-Time Memory Allocation:

o Predictable memory allocation and deallocation are critical for real-time systems
to meet deadlines.
o Memory fragmentation can lead to delays in memory allocation, which might
prevent the system from fulfilling time-critical tasks.
 Memory Constraints:
o Some embedded systems have very tight memory constraints (e.g.,
microcontrollers with just a few KB of RAM), necessitating careful and optimized
memory usage.
o Use of memory-efficient algorithms and data structures is essential to minimize
memory use.

4.2. Hardware Development

1. Requirements gathering and project development specification

the ideas of new products usually belong to customers, and the first task is to gather the
requirements for the future device:

 Functional requirements (what the system must do);

 Non-functional requirements: performance, scalability, security, size, weight, and other
important features.

Customers with no technical background find it difficult to formulate requirements for their
products. They tend to pay more attention to marketing and functional features but lack an
understanding of the technical side and feasibility of the project. So, the key challenge here is to
interview the client thoroughly.
It’s also important not to promise more than we can do. If what the customer wants is barely
realistic, our job is to tell him or her the truth, explain why, and offer feasible alternatives. a
document that describes the purpose, functions, behavior, and other requirements will be
required.

2. Technical proposal

At this stage, a document will be written that describes the architecture of the future system
and the solutions that are going to implement. And the product requirements mainly focus:

 Technical characteristics: power consumption, memory capacity, MCU performance,

size, weight, etc.
 Operating environment: extreme temperatures, humidity, vibration stress, etc.
 The cost and quality of the components.
 The availability of the components (if the device is supposed to be mass-produced).
 Developers must find a balance between the cost of the future embedded system solution
and its performance.

3. hardware design and layout

The device under development must not only perform its key functions but also be safe and
reliable. During embedded hardware design, the following issues should take into account:

 The design of the board must fully comply with the PCB design rules so that the device
can serve as long as possible with no issues.
 Due attention must be paid to heat dissipation, especially when designing a powerful
device. It can be achieved with proper component placement, or by extending the copper
area, adding vias, using a cooling radiator, or by other means.
 The components we have never used before must be tested to make sure they function as
their data sheets indicate.
 Protecting PCBs (Printed Circuit Boards) from external threats like EOS (Electrical
Overstress), ESD (Electrostatic Discharge), electromagnetic interference (EMI), and
environmental hazards is essential for ensuring the reliability and longevity of
electronic devices
 If the embedded system is to be mass-produced, we must follow the Design for
Manufacturing (DFM) principles.

Data sheets may contain errors and inaccuracies. And since embedded product development is a
costly service, such problems must be revealed before spending money. Besides, if the job
requires a non-standard approach, it must make sure it’ll work for a given project. In such cases,
build a proof-of-concept prototype is needed first. Electronics prototyping allows us to prove
an idea, check the work of components, and reveal various issues at an early stage of embedded
development.
4. Testing

Tests PCBs under development at each phase of the process. Tests can show if the board functions
correctly and complies with the requirements. Tests are conducted both after and during
development so that we can reveal and eliminate all kinds of defects and issues before moving on
to mass production Often, it needs to create custom testing firmware that checks if the PCB works
as expected. When the product is ready for mass production, factory testing firmware will be
conducted.

What is Embedded Software?

Creating software is the other part of embedded system design. Unlike applications that run on
PCs or smartphones, embedded software is created for specific hardware, i.e., can only run on
the microcontrollers of special-purpose, non-computer devices. A program that controls a smart
watch, a digital camera, a millimeter, or a washing machine is embedded software.
Such programs are built into devices or machines to control them and/or perform a limited range
of functions. Often embedded software is installed in devices permanently. It is stored in non-
volatile memory ROM, EEPROM, or flash memory. Without it, the device won’t work and turn
into a piece of metal and plastic.
Most embedded programs (except for embedded apps) don’t have a graphical user interface
(GUI). They are designed to interact with other software through external interfaces rather than
with users through a GUI. If a program does have a GUI, it is typically used for configuring the
program and outputting limited data (for example, the information about the device’s state).

The purpose of embedded software is to control a device by transmitting data between the
hardware and higher-level programs.

Embedded software retrieves signal and data from the hardware. The program interprets them as
commands and data sequences, used for creating various objects, and transmits them to higher-
level software.
When embedded software receives commands and objects from higher-level software, it translates
them into signals and data arrays and transmits them to the hardware. An embedded system
solution can have up to four levels of embedded software:

Firmware

Firmware is a type of computer program that boots a piece of hardware and provides it with low-
level instructions. Operating systems and applications run on top of firmware. It is written in low-
level languages (typically in C/C++). To let the device read it and execute the instructions, the
program is then converted into machine code.

Embedded operating system

Embedded OSs are specialized software that controls system resources. With drivers and APIs,
an OS provides application-level software with access to the device’s hardware. Applications run
on top of embedded operating systems.

Middleware

Some embedded software designs can include middleware. It’s a software layer between the OS
and the application. Virtual machines are typical examples of middleware. A VM emulates a
platform and executes a computer-independent code, thus making it compatible with different
operating systems. For instance, programs written in Kotlin are converted to a Java code
(application level) that, in turn, is executed in a virtual machine (middleware level) running on an
operating system (OS level).

Embedded application
Just like typical apps for computers, this type of software performs the functions of the embedded
system and directly interacts with users. It processes data, interacts with other devices, and
performs high-level functions. Embedded applications are written in high-level languages such as
C++, Python, and Java.

An embedded system can incorporate firmware only or more levels of embedded software.
Additionally, a solution may require desktop or smartphone applications to function properly. Our
team can create all these types of programs for your solution, so give us a call to discuss the project
in detail.

Sometimes, embedded applications, embedded OSs, and middleware are referred to as firmware,
while the term embedded software is extended to include firmware and embedded software
development tools. There is no uniform terminology for these concepts.

Embedded Software Development Tools

Developers use the following tools to create embedded software:

 Integrated Development Environments (IDE) are toolsets that contain various

programming instruments such as editors, compilers, debuggers, and more
 Compilers and cross-compilers translate the code written in a high-level language into a
low-level machine code.
 Debuggers help developers find and eliminate bugs.
 Linkers can combine different pieces of code and modules into a single executable
program. Modern compilers have built-in linkers.
 Simulators and emulators provide simulated environments close to real-life conditions
for testing programs.
 System configuration and code generation tools automatically generate code for
configuring the hardware components of a device. They minimize manual coding and,
therefore, error rates.
 Code suggestion tools are AI-based instruments that analyze the code written by a
programmer and autocomplete it with contextually relevant snippets. They considerably
speed up embedded system software development.

Disassemblers are used to reveal errors made by compilers. Sometimes, it is easier to eliminate
errors at the assembler level.

Challenges of Embedded Software Development

1. Hardware platform selection
Of course, more powerful MCUs with larger memory capacity. But if it’s not an option and we
have to use a less powerful alternative, we need to analyze the project thoroughly to be sure we
can implement all the features and optimize the code for this particular hardware.

Since embedded software systems interact with hardware (microcontrollers, sensors, buzzers, etc.),
developers need to study the equipment before they start coding. The problem is that certain
models may lack the necessary documentation or the data sheets may contain mistakes,
inaccuracies, and outdated information.

A module that could simultaneously receive GPS coordinates and transmit data using GSM. The
data sheet claimed the module was capable of both, but the device didn’t function properly during
tests. The team contacted the manufacturer, and the company admitted that the module couldn’t
perform both functions simultaneously. To switch between GSM and GPS modes, it needed to be
rebooted. This fact was not mentioned in the data sheet.

This situation is not uncommon for cheap components. Contacting the developer of the hardware
usually helps. Sometimes, the developer doesn’t respond, and the team has to analyze the hardware
by itself. But these are usually simple components designed by small companies, so studying them
is not too difficult.

The manufacturers of expensive hardware typically provide full information in their data sheets
but using them makes the final product more expensive.

2. Selecting a programming language and operating system

The choice of programming language is determined by hardware and the type of software we want
to create. For example, programs for Android-based devices are created in Java, while software
for single board computers is written in C or C++. C is suitable for low-level programming, i.e.,
for programs that interact directly with the hardware. C++, Python, Java, Rust, and other languages
are suitable for high-level programming.

A programmer experienced in C++ can use the Qt framework to create both embedded software
and application-level programs. Although there are safer alternatives to C/C++ (e.g., Rust).
Devices that perform simple actions can function with the so-called bare-metal firmware that
doesn’t require an operating system. However, electronics with complicated functions do need an
OS.

Here developers have many options: Embedded Linux, Android, Windows IoT, RTEMS, and
more. The choice is determined by several factors:

 project goal;
 available hardware resources; and
 development cost.

Powerful hardware can hold resource-demanding operating systems. For instance, writing
software for Ubuntu won’t take much time but will require powerful and expensive hardware as
Ubuntu has many services, drivers, and packages. Weaker hardware makes developers spend more
time optimizing and customizing the code, so embedded software programming grows more
expensive.

creating software using free operating systems is easier and cheaper.

3. Software architecture design

Before writing the code, developers think through the architecture (structure) of the future solution.
The architecture includes software elements, the relations among them, and their properties.
Since we deal with different hardware platforms and are limited in resources, we can’t use a single
architecture template for all projects. Embedded system design requires optimal solutions, so a
universal architecture won’t work here. We have to pick from a number of architecture templates
and customize them for each particular project.
Often embedded products under development are only a part of a bigger system. A project may
also require developing application-level software that will interact with the device somehow. In
theory, the team can design embedded software first and move on to other tasks after that. But to
make the process faster, our embedded team creates a document that describes external interfaces
and protocols for interacting with the programs so that the other teams can start their work as soon
as possible. It’s a common practice that speeds up the process.
Sometimes, we create a mock service that emulates the work of the embedded program and
generates synthetic data for the application-level software under development.

4. Coding

When everything is settled, the remaining is coding. The key difference between embedded
software and application software development is that embedded programs don’t have complicated
logic. The true challenge is to make the software interact with the hardware and control it correctly.
 Lack of information
Application software developers have lots of frameworks with ready-made solutions and tons of
information on the web. But embedded software developers create code for non-standard, heavily
customized equipment. They need to understand how this particular hardware works, so they spend
a lot of time studying data sheets and/or testing the hardware manually.
 Data security
Many embedded devices have access to the Internet. If they transmit sensitive data, the
communication must be secure. Here we have a range of standard encryption methods. For
instance, right now the Integra team is working on a medical device that transmits biometrics via
the Internet. This kind of data must be protected. However, encryption raises the hardware
requirements.
 Memory and performance shortage
Embedded devices are getting smaller, while the performance requirements for them are
increasing. Although memory shortage isn’t as critical today as it used to be, it is still a problem
for embedded software development.
Power limitation is another typical problem for battery-powered devices. The work of its software
must be programmed in such a way as to minimize electricity consumption. To do so, developers
can reduce the number of instructions for the processor core. Another way is to put the processor
core to sleep mode until an outside event (such as timer interruption) occurs.

 Stability
Although software can’t “break” like hardware components do, it can still crash. Most of such
problems are caused by incorrect memory access.
Here is a typical example. Process 1 calculates a variable and puts the value into a memory cell.
This value is required by Process 2. Since the two processes run in parallel, Process 2 may access
the memory cell before Process 1 calculates the value, which causes a crash.
When coding, developers must foresee such situations and give processes proper instructions for
instance, instruct Process 2 to make sure Process 1 has calculated the value before using it.
 New requirements
Sometimes this phase becomes challenging because the customer decides to extend the
functionality of the device or wants to change the requirements for the project. The hardware
platform chosen at the preparation phase may not be sufficient for the new features, and the team
may even be forced to start over.
 Optimization
Software optimization plays a huge role in embedded system design as we are always limited in
resources. Programmers can make software fast but memory-intensive or vice-versa memory-
friendly but slow. Modern compilers offer many types of optimizations so that developers can find
a balance between these extremes.

5. Testing and debugging

A typical application can be tested on a computer, but embedded software is designed for devices
and equipment. So, developers need a fully featured test station or even field trials. QA specialists
have to be very resourceful. For example, when working on the aircraft towing system, the team
had to test the distance-measuring module somehow. QA specialist designed and created a special
stand with a 3D printer. The module was fixed on the stand, while the stand was attached to the
hood of a car with a magnet.

Sometimes we need to develop software for a device that we don’t have – for example, if it’s too
heavy to transport or when we design a PCB for a larger system. This makes testing even more
difficult.

In that case, the customer can install TeamViewer or a similar solution on a computer and connect
the PC to a camera and the device under test. This way the team can connect to the PC to give
commands to the device and see what’s happening through the camera.

Applications are usually standalone products, while embedded programs always interact with
hardware. When an error occurs, it’s difficult to tell whether the problem was caused by hardware
or software especially during field trials when the testers are limited in diagnostic tools. The only
way to see if the software is working properly is to upload logs to a connected laptop in real time.

As for hardware, QA specialists use oscilloscopes, voltmeters, multi meters, and other tools to
check if the PCB and its components are working properly. The team designed a device consisting
of a single-board computer and two PCBs. The SBC was supposed to send a heartbeat package to
one of the boards to confirm it’s still working. If the PCB did not receive the package, it was
supposed to reboot the computer automatically, which the board did all the time during tests.

The team checked the bus with a logic analyzer and confirmed the SBC sent the correct signal,
which proved the problem was caused by the firmware of the PCB that didn’t process the package
correctly. If the device fails due to an equipment defect, the it can be fixed it “manually” instead
of manufacturing a new PCB, which would raise the development cost.