Computer Science and Engineering Bertolotti

Hu

Embedded Software Development Embedded

Software
T h e O p en - S ou rce A p p ro a ch

Embedded Software Development

“… provides a consistent description covering many aspects of embedded systems
development and explains their interrelationships, which is a very important comple-
ment to other in-depth literature. … As such, this book fills a gap ... and will prove

Development
valuable to students and professionals who need a single, coherent source of
information.”
—Kristian Sandström, ABB Corporate Research, Västerås, Sweden
Embedded Software Development: The Open-Source Approach delivers a practi-
cal introduction to embedded software development, with a focus on open-source
components. This programmer-centric book is written in a way that enables even novice
practitioners to grasp the development process as a whole.

Incorporating real code fragments and explicit, real-world open-source operating

The Open-Source Approach
system references (in particular, FreeRTOS) throughout, the text:

• Defines the role and purpose of embedded systems, describing their internal
structure and interfacing with software development tools
• Examines the inner workings of the GNU compiler collection (GCC)-based
software development system or, in other words, toolchain
• Presents software execution models that can be adopted profitably to
model and express concurrency
• Addresses the basic nomenclature, models, and concepts related to task-based
scheduling algorithms
• Shows how an open-source protocol stack can be integrated in an embedded
system and interfaced with other software components
• Analyzes the main components of the FreeRTOS Application Programming Interface
(API), detailing the implementation of key operating system concepts
• Discusses advanced topics such as formal verification, model checking, runtime
checks, memory corruption, security, and dependability

Embedded Software Development: The Open-Source Approach capitalizes on the

authors’ extensive research on real-time operating systems and communications used
in embedded applications, often carried out in strict cooperation with industry. Thus, the
book serves as a springboard for further research.

Ivan Cibrario Bertolotti

K20656
ISBN 978-1-4665-9392-3
90000

9 781466 593923 Tingting Hu

Embedded
Software
Development
The Open-Source Approach
 Embedded Systems
Series Editor
Richard Zurawski
ISA Corporation, San Francisco, California, USA

Embedded Software Development: The Open-Source Approach,

Ivan Cibrario Bertolotti and Tingting Hu
Event-Based Control and Signal Processing, edited by Marek Miskowicz
Real-Time Embedded Systems: Open-Source Operating Systems Perspective,
Ivan Cibrario Bertolotti and Gabriele Manduchi
Time-Triggered Communication, edited by Roman Obermaisser
Communication Architectures for Systems-on-Chip, edited by José L. Ayala
Embedded
Software
Development
The Open-Source Approach
Ivan Cibrario Bertolotti
National Research Council of Italy
Tu r i n , I t a l y

Tingting Hu
National Research Council of Italy
P o l i t e c n i c o d i To r i n o
Tu r i n , I t a l y

Boca Raton London New York

CRC Press is an imprint of the

Taylor & Francis Group, an informa business
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
© 2016 by Taylor & Francis Group, LLC
CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Version Date: 20151027

International Standard Book Number-13: 978-1-4665-9393-0 (eBook - PDF)

This book contains information obtained from authentic and highly regarded sources. Reasonable
efforts have been made to publish reliable data and information, but the author and publisher cannot
assume responsibility for the validity of all materials or the consequences of their use. The authors and
publishers have attempted to trace the copyright holders of all material reproduced in this publication
and apologize to copyright holders if permission to publish in this form has not been obtained. If any
copyright material has not been acknowledged please write and let us know so we may rectify in any
future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced,
transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or
hereafter invented, including photocopying, microfilming, and recording, or in any information stor-
age or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copy-
right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222
Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro-
vides licenses and registration for a variety of users. For organizations that have been granted a photo-
copy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are
used only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
 Ché nessun quaggiù lasciamo,
né timore, né desir
(For we leave no one behind us,
nor dreads, nor desires)
— Ivan

(This book is dedicated to my grandfather Chen Guanglu,

my grandmother Song Fengzhi)
— Tingting
Contents

Foreword .................................................................................................................xiii

Preface....................................................................................................................xvii

The Authors ............................................................................................................xix

List of Figures .........................................................................................................xxi

List of Tables.......................................................................................................... xxv

Chapter 1 Introduction .......................................................................................... 1

PART I Basics of Embedded Software Development

Chapter 2 Embedded Applications and Their Requirements................................ 9
2.1 Role and Purpose of Embedded Systems ................................... 9
2.2 Microcontrollers and Their Internal Structure.......................... 13
2.2.1 Flash Memory .............................................................. 15
2.2.2 Static Random Access Memory (SRAM).................... 17
2.2.3 External Memory ......................................................... 19
2.2.4 On-Chip Interconnection Architecture ........................ 23
2.3 General-Purpose Processors versus Microcontrollers .............. 29
2.4 Embedded Software Development Process .............................. 32
2.5 Summary................................................................................... 37

Chapter 3 GCC-Based Software Development Tools ........................................ 39

3.1 Overview................................................................................... 40
3.2 Compiler Driver Workflow ....................................................... 42
3.3 C Preprocessor Workflow ......................................................... 44
3.4 The Linker ................................................................................ 48
3.4.1 Symbol Resolution and Relocation.............................. 49
3.4.2 Input and Output Sequences ........................................ 51
3.4.3 Memory Layout ........................................................... 55
3.4.4 Linker Script Symbols ................................................. 58
3.4.5 Section and Memory Mapping..................................... 59

vii
viii Contents

3.5 The C Runtime Library............................................................. 62

3.6 Configuring and Building Open-Source Software.................... 65
3.7 Build Process Management: GNU Make ................................. 69
3.7.1 Explicit Rules............................................................... 70
3.7.2 Variables....................................................................... 72
3.7.3 Pattern Rules ................................................................ 74
3.7.4 Directives and Functions.............................................. 77
3.8 Summary................................................................................... 78

Chapter 4 Execution Models for Embedded Systems......................................... 81

4.1 The Cyclic Executive................................................................ 81
4.2 Major and Minor Cycles........................................................... 83
4.3 Task Splitting and Secondary Schedules .................................. 87
4.4 Task-Based Scheduling............................................................. 91
4.5 Task State Diagram................................................................... 95
4.6 Race Conditions in Task-Based Scheduling ............................. 98
4.7 Summary................................................................................. 102

Chapter 5 Concurrent Programming Techniques.............................................. 105

5.1 Task Management ................................................................... 105
5.2 Time and Delays ..................................................................... 111
5.3 Semaphores............................................................................. 114
5.4 Message Passing ..................................................................... 125
5.5 Summary................................................................................. 136

Chapter 6 Scheduling Algorithms and Analysis............................................... 137

6.1 Scheduling Algorithms for Real-Time Execution .................. 137
6.2 Scheduling Analysis ............................................................... 144
6.3 Summary................................................................................. 162

Chapter 7 Configuration and Usage of Open-Source Protocol Stacks ............. 163

7.1 Introduction to the LW IP Protocol Stack ................................ 163
7.2 Operating System Adaptation Layer ...................................... 167
7.3 Configuration Options ............................................................ 169
7.4 Netconn Interface.................................................................... 175
7.5 Network Buffer Management ................................................. 181
7.6 POSIX Networking Interface.................................................. 187
7.7 Summary................................................................................. 197

Chapter 8 Device Driver Development ............................................................. 199

8.1 General Structure of a Device Driver ..................................... 199
8.2 Interrupt Handling .................................................................. 201
8.2.1 Interrupt Handling at the Device Level...................... 203
Contents ix

8.2.2 Interrupt Handling at the Interrupt Controller Level . 204

8.2.3 Interrupt Handling at the CPU Level ......................... 206
8.2.4 Some Remarks ........................................................... 211
8.3 Device Driver Interfaces ......................................................... 211
8.4 Synchronization Issues ........................................................... 214
8.5 Example: Ethernet Device Driver ........................................... 218
8.5.1 Ethernet Block Architecture ...................................... 218
8.5.2 Initialization ............................................................... 221
8.5.3 Interrupt Handler........................................................ 230
8.5.4 Receive Process.......................................................... 232
8.5.5 Transmit Process ........................................................ 237
8.6 Summary................................................................................. 238

Chapter 9 Portable Software ............................................................................. 241

9.1 Portability in Embedded Software Development ................... 241
9.2 Portability Issues in C-Language Development ..................... 247
9.3 Application Programming Interfaces...................................... 255
9.4 GCC Extensions to the C Language ...................................... 258
9.4.1 Object Attributes ........................................................ 259
9.4.2 Assembly Language Inserts ....................................... 268
9.5 Summary................................................................................. 274

Chapter 10 The F REE RTOS Porting Layer........................................................ 275

10.1 General Information................................................................ 275
10.2 Basic Data Types .................................................................... 280
10.3 Time Representation and Architectural Details...................... 281
10.4 Context Switch........................................................................ 282
10.5 Interrupt Handling and Critical Regions................................. 288
10.6 Task Stack Initialization.......................................................... 290
10.7 Tick Timer .............................................................................. 294
10.8 Architecture-Dependent Scheduler Startup ............................ 296
10.9 Summary................................................................................. 297

Chapter 11 Performance and Footprint at the Toolchain Level .......................... 299

11.1 Overview of the GCC Workflow and Optimizations ............. 300
11.1.1 Language-Dependent Workflow ................................ 301
11.1.2 Language-Independent Workflow.............................. 303
11.1.3 Target-Dependent Workflow ...................................... 314
11.2 Optimization-Related Compiler Options................................ 316
11.3 Architecture-Dependent Compiler Options............................ 320
11.4 Source-Level Optimization: A Case Study............................. 323
11.4.1 Summary of the Algorithm ........................................ 324
11.4.2 Base Source Code ...................................................... 327
x Contents

11.4.3 Optimizations............................................................. 331

11.5 Summary................................................................................. 342

Chapter 12 Example: A M ODBUS TCP Device.................................................. 343

12.1 Toolchain and Operating System............................................ 343
12.2 General Firmware Structure ................................................... 345
12.3 M ODBUS Slave Protocol Stack............................................... 348
12.3.1 TCP/IP Protocol Stack Interface................................ 349
12.3.2 Operating System Adaptation Layer.......................... 352
12.3.3 M ODBUS TCP Layer ................................................. 356
12.3.4 M ODBUS Application Layer and Event Loop ........... 358
12.4 USB-Based Filesystem ........................................................... 360
12.4.1 FAT Filesystem........................................................... 360
12.4.2 USB Protocol Stack and Driver ................................. 364
12.5 Application Code .................................................................... 367
12.6 Performance and Footprint ..................................................... 368
12.6.1 Memory Footprint...................................................... 369
12.6.2 System Performance .................................................. 371
12.7 Summary................................................................................. 373

PART II Advanced Topics

Chapter 13 Model Checking of Distributed and Concurrent Systems................ 377

13.1 Introduction............................................................................. 377
13.2 The S PIN Model Checker ....................................................... 379
13.3 The P ROMELA Modeling Language....................................... 380
13.3.1 Processes .................................................................... 381
13.3.2 Data Types ................................................................. 383
13.3.3 Expressions ................................................................ 386
13.3.4 Control Statements..................................................... 388
13.3.5 Atomicity ................................................................... 393
13.3.6 Channels..................................................................... 396
13.4 Property Specification............................................................. 400
13.5 Performance Hints .................................................................. 401
13.6 Summary................................................................................. 404

Chapter 14 Model Checking: An Example ......................................................... 407

14.1 Introduction............................................................................. 407
14.2 Distributed Master Election Protocol ..................................... 408
14.3 Formal P ROMELA Protocol Model......................................... 412
14.3.1 Simplified Time Model .............................................. 412
14.3.2 Broadcast Channel Model.......................................... 415
14.3.3 Masters Model ........................................................... 417
Contents xi

14.4 Formal Verification Results .................................................... 419

14.5 Summary................................................................................. 425

Chapter 15 Memory Protection Techniques........................................................ 427

15.1 Memory Management Units (MMUs).................................... 427
15.2 Memory Protection Units (MPUs).......................................... 432
15.3 MPUs versus MMUs .............................................................. 438
15.4 Memory Checksumming ........................................................ 439
15.5 CRC Calculation..................................................................... 444
15.6 Data Structure Marking .......................................................... 455
15.7 Stack Management and Overflow Detection .......................... 460
15.8 Summary................................................................................. 465

Chapter 16 Security and Dependability Aspects ................................................ 467

16.1 Introduction to S PLINT ...........................................................468
16.2 Basic Checks........................................................................... 470
16.3 Memory Management............................................................. 478
16.4 Buffer Overflows .................................................................... 492
16.5 Function Interface Annotations .............................................. 499
16.6 Summary................................................................................. 506

References ............................................................................................................. 507

Index...................................................................................................................... 515
Foreword
Embedded software touches many aspects in our daily life by defining the behavior
of the things that surround us, may it be a phone, a thermostat, or a car. Over time,
these things have been made more capable by a combination of advances in hardware
and software. The features and capabilities of these things are further augmented by
connecting to other things or to external software services in the cloud, e.g., by a
training watch connecting wirelessly to a heartrate monitor that provides additional
sensor data and to a cloud service providing additional analysis and presentation
capabilities. This path of evolution can be seen in most domains, including industrial
embedded systems, and has over time added new layers of knowledge that are needed
for development of embedded systems.
Embedded systems cover a large group of different systems. For instance, a phone
is a battery-powered device with relatively high processing power and ample options
for wireless connectivity, while a thermostat is likely to have scarce resources and
limited connectivity options. A car on the other hand represents another type of em-
bedded system, comprising a complex distributed embedded system that operates in
harsh environments. Although the requirements and constraints on these systems are
quite different, there are still strong commonalities among most types of embedded
systems, considering the software layers that sit closest to the hardware, typically
running on embedded or real-time operating systems that offer similar services.
Every new generation of a software-based system typically is more elaborate and
operates in a more complex and dynamic environment than the previous one. Over
the last four decades many things have changed with respect to software based sys-
tems in general; starting in the 1980s with the early desktop PC, like the IBM XT that
I used at the university, which was similar to industrial and embedded systems with
respect to operating system support and development environments. In the 1990s,
real-time and embedded operating systems services remained mostly the same, while
the evolution of general purpose operating systems witnessed many changes includ-
ing graphical user interfaces. During the first decade of the new millennium we saw
the introduction of smart phones, server virtualization, and data centers, and cur-
rently we see the emergence of large scale open-source software platforms for cloud
computing and the Internet of Things (IoT).
Some embedded systems such as consumer electronics have been an integral part
of these latest developments while industrial system adoption is slower and more
careful. Although, the system context today is much more complex than thirty-five
years ago and many software layers have been added, the foundation, the software
that sits close to the hardware, is still much the same with the same requirements for
timeliness and predictability.
As the software stack in embedded systems increases and as the functionality
reaches beyond the embedded device through connectivity and collaboration with

xiii
xiv Foreword

surrounding systems, the burden on the engineer potentially increases in order to

master the entire scope of development. To some degree this can be addressed by
using more powerful software platforms, better tools, and so on that alleviate the de-
veloper from handling some details. But unlike general purpose computing systems
many of the embedded devices still have strict constraints with respect to memory
and computational resources. For industrial embedded systems additional constraints
related to safety, reliability, and availability apply. There are also aspects such as
constraints on power consumption to enhance battery life or to facilitate fanless op-
eration needed for high availability in some harsh or hard to reach environments.
Therefore, detailed control of the lower levels of the software stack is still necessary
for the development of many embedded systems.
The fast-paced development of consumer and general purpose technologies makes
it difficult to directly adopt these technologies for industrial embedded systems. A
common denominator for industrial systems within many different domains is that
they are expected to be operational for a very long time. An example is the world’s
first electrical and microchip enabled industrial robot that was developed at the re-
search department of Allmänna Svenska Elektriska Aktiebolaget (ASEA, which later
became ABB) in the early 1970s. Today, some 40 years later, some of these robots
are still in operation within Swedish industry. Moreover, even if individual equip-
ment sometimes operate unchanged, the software platform of the specific product
family often evolves over a long time, outliving several generations of hardware.
This puts requirements on software portability and availability of tooling, third party
support, drivers, etc. Hence, technology must be selected for stability over a long
time.
An interesting aspect of the conflict between long-lived systems and fast-paced
technology is what role open-source can play. Can open-source help in the provi-
sioning of long-term software technologies? Certainly Linux⃝ R
and the GCC com-
piler are examples of open-source platforms and tools heavily used for embedded
systems and that have had long-term support and development. Perhaps some of the
emerging open-source projects will play the same role for embedded systems in the
era of IoT technologies.
From a setback in early 2000, following the dot-com crash, there was interest
in embedded systems from new generations of young people through maker culture
and easily accessible open-source operating systems like Linux and FreeRTOSTM ,
and hardware projects like Raspberry PiTM , and ArduinoTM . Capturing this interest
is a great opportunity for continued evolution of embedded systems not only in the
consumer segment but also for industrial systems.
This book provides a comprehensive description covering many aspects of em-
bedded systems development and explains their interrelationships, which is a very
important complement to other in-depth literature on specific subjects such as oper-
ating systems. Today there are communities that provide a lot of very specific and
detailed information related to embedded systems e.g., on setting up a specific pack-
age for an operating system.
Foreword xv

What is lacking is continuous and coherent descriptions holding all fragments to-
gether presenting a holistic view on the fundamentals of the embedded system, the
involved components, how they operate in general, and how they interact and depend
on each other. As such, this book fills a gap in the literature and will prove valuable
to students and professionals who need a single coherent source of information.

Kristian Sandström
ABB Corporate Research
Västerås, Sweden

Raspberry PiTM is a trademark of the Raspberry Pi Foundation.

ArduinoTM is the trademark of Arduino LLC.
Linux⃝R
is the registered trademark of Linus Torvalds in the U.S. and other countries.
FreeRTOSTM is the trademark of Real Time Engineers Ltd.
Preface
This book is the outcome of the authors’ research experience in the field of real-
time operating systems and communications applied to control systems and other
classes of embedded applications, often carried out in strict cooperation with indus-
try. Through the years, we have been positively influenced by many other people
with whom we came in contact.
They are too numerous to mention individually, but we are nonetheless indebted
to them for their contribution to our professional growth. A special thank you goes to
our industrial partners, who are constantly in touch with most of the topics presented
in this book. Their questions, suggestions, and remarks that we collected along the
way were helpful in making the book clearer and easier to read.
We would also like to express our appreciation to our coworkers for all their sup-
port and patience during the long months while we were busy with the preparation
of the manuscript.
Last, but not least, we are grateful to Richard Zurawski, who gave us the oppor-
tunity to write this book, and Kristian Sandström for his insightful foreword. We are
also indebted to CRC Press publishing, editorial, and marketing staff, Nora Konopka,
John Gandour, Kyra Lindholm, Laurie Oknowsky, Karen Simon, Michele Smith, and
Florence Kizza in particular. Without their help, the book would have probably never
seen the light.

xvii
The Authors
Ivan Cibrario Bertolotti earned the Laurea degree (summa cum laude) in com-
puter science from the University of Torino, Turin, Italy, in 1996. Since then, he has
been a researcher with the National Research Council of Italy (CNR). Currently, he
is with the Institute of Electronics, Computer, and Telecommunication Engineering
(IEIIT) of CNR, Turin, Italy.
His research interests include real-time operating system design and implementa-
tion, industrial communication systems and protocols, and formal methods for vul-
nerability and dependability analysis of distributed systems. His contributions in this
area comprise both theoretical work and practical applications, carried out in coop-
eration with leading Italian and international companies.
Dr. Cibrario Bertolotti taught several courses on real-time operating systems at
Politecnico di Torino, Turin, Italy, from 2003 until 2013, as well as a PhD degree
course at the University of Padova in 2009. He regularly serves as a technical referee
for the main international conferences and journals on industrial informatics, factory
automation, and communication. He has been an IEEE member since 2006.

Tingting Hu earned a master’s degree in computer engineering and a PhD de-

gree in control and computer engineering, both from Politecnico di Torino, Turin,
Italy. Since 2010, she has been a research fellow with the National Research Coun-
cil of Italy (CNR). Currently, she is with the Institute of Electronics, Computer, and
Telecommunication Engineering (IEIIT) of CNR, Turin, Italy.
Her main research interests are the design and implementation of real-time oper-
ating systems and communication protocols, focusing on deterministic and flexible
execution and communication for distributed real-time embedded systems. A sig-
nificant amount of her research activities are carried out in strict collaboration with
industry.
Dr. Hu is actively involved in several regional and national industrial research
projects in the context of the Italian “Factory of the Future” framework program.
Moreover, in 2014 she taught a postgraduate-level course about real-time operat-
ing systems and open-source software for embedded applications aimed at company
technical managers. She has been an IEEE member since 2011 and serves as techni-
cal referee for several primary conferences in her research area.

xix
List of Figures

2.1 Internal structure of a microcontroller (simplified). ..................................... 14

2.2 Allocation of program objects in different memory banks........................... 16
2.3 Bus- and bridge-based on-chip interconnection. .......................................... 24
2.4 Crossbar-based on-chip interconnection....................................................... 27
2.5 Summary of the embedded software development process.......................... 32
2.6 Possible ways of connecting the development system with the
target board. .................................................................................................. 35

3.1 Overview of the toolchain workflow............................................................. 40

3.2 Overview of the compiler driver workflow. .................................................. 42
3.3 Simplified C preprocessor workflow............................................................. 45
3.4 Linker’s handling of object files and libraries in the input sequence. .......... 53
3.5 Object files versus libraries........................................................................... 55
3.6 Initialized variables setup, VMA and LMA. ................................................ 57
3.7 Handling of the NEWLIB impure pointer on single-core systems. ............... 64
3.8 NEWLIB synchronization points. .................................................................. 65
3.9 Summary of the toolchain components installation process......................... 66

4.1 A prototypical cyclic executive..................................................................... 82

4.2 Major and minor cycles in a cyclic executive............................................... 84
4.3 The cyclic executive schedule for the task set of Table 4.1. ......................... 86
4.4 A possible task split for the task set of Table 4.2. ........................................ 88
4.5 Schedule of the task set of Table 4.3, without secondary schedules. ........... 90
4.6 Schedule of the task set of Table 4.3, using a secondary schedule............... 91
4.7 Main task control block components............................................................ 93
4.8 Task state diagram in the F REE RTOS operating system. ............................ 95
4.9 Rate Monotonic scheduling of the task set specified in Table 4.4................ 99
4.10 Shortcoming of lock-based synchronization when a task halts. ................. 102

5.1 Relative versus absolute delays. ................................................................. 113

5.2 Abstract structure of a semaphore and behavior of its primitives. ............. 115
5.3 Task state diagram states and transitions involved in semaphore
operations.................................................................................................... 116
5.4 Usage of a semaphore and its primitives for mutual exclusion. ................. 117
5.5 Usage of a semaphore and its primitives for condition synchronization. ... 119
5.6 Indirect naming scheme in message passing. ............................................. 126
5.7 Message queue synchronization model. ..................................................... 128
5.8 Synchronous and remote invocation transfers. ........................................... 129

xxi
xxii List of Figures

6.1 Notation for real-time scheduling algorithms and analysis. ....................... 141
6.2 U-based schedulability tests for Rate Monotonic....................................... 145
6.3 Scheduling diagram for the task set of Table 6.2........................................ 147
6.4 Scheduling diagram for the task set of Table 6.3........................................ 148
6.5 Unbounded priority inversion. .................................................................... 154
6.6 Priority inheritance protocol. ...................................................................... 158

7.1 Interfaces and tasks of the LW IP protocol stack. ........................................ 164

7.2 Nonportable modules of LW IP. .................................................................. 165
7.3 Internal LW IP synchronization and communication paths. ........................ 166
7.4 Internal structure of an LW IP netbuf. ...................................................... 181
7.5 Internal structure of a RAM and POOL LW IP pbuf..................................... 186

8.1 General structure of a device driver. ........................................................... 200

8.2 Interrupt handling path. .............................................................................. 202
8.3 Chain of events and actions along the interrupt handling path................... 203
8.4 Operating modes on ARM7........................................................................ 207
8.5 Current program status register (CPSR) on ARM7. ................................... 208
8.6 Exception and interrupt vector tables. ........................................................ 210
8.7 Synchronization issues in interrupt handlers. ............................................. 215
8.8 Synchronization by means of a helper task. ............................................... 216
8.9 Ethernet block diagram............................................................................... 219
8.10 General structure of the Ethernet device driver. ......................................... 221
8.11 Ring buffer used for the transmission path. ................................................ 225
8.12 Empty and full ring buffer check. ............................................................... 226

9.1 Likely sources of portability issues in an embedded system. ..................... 245

9.2 Propagation and handling of the section attribute through the toolchain. .. 266
9.3 Meaning of the weak attribute. .................................................................. 268
9.4 Handling of assembly language inserts by the compiler. ........................... 273

10.1 Summary of the F REE RTOS porting layer. ............................................... 279

10.2 Simplified stack diagrams after a F REE RTOS context save operation. ..... 285

11.1 Overview of the GCC compiler workflow. ................................................ 300

11.2 Language-dependent portion of the workflow, C language. ....................... 301
11.3 Language-independent portion of the workflow. ........................................ 306
11.4 Version numbers and ϕ nodes in SSA generation. ..................................... 308
11.5 Target-dependent code generation and optimization. ................................. 314
11.6 Basic principle of 8B9B encoding.............................................................. 326
11.7 Data flow for one iteration of 8B9B encoding............................................ 330
11.8 Encoder delay on Cortex-M3 architecture, loop unrolling enabled. .......... 340
11.9 Encoder delay on Cortex-M3 architecture, loop unrolling disabled........... 341
List of Figures xxiii

12.1 General structure of the M ODBUS device firmware. .................................. 346

12.2 Inner structure and interfaces of the M ODBUS slave protocol stack. ......... 348
12.3 MBAP header processing in the M ODBUS TCP layer and below. ............. 358
12.4 Inner structure and interfaces of the FAT FS filesystem.............................. 361
12.5 Inner structure and interfaces of the USB protocol stack. .......................... 364

13.1 Simplified view of the S PIN verification flow............................................. 379

13.2 Example of init process........................................................................... 382
13.3 Message exchange through rendezvous channel. ....................................... 397

14.1 Simplified structure of a master election. ................................................... 408

14.2 Election protocol’s timed FSM................................................................... 411
14.3 Simplified time model................................................................................. 414
14.4 Broadcast channel model............................................................................ 416
14.5 Outline of the masters model...................................................................... 418
14.6 First bug found by S PIN in the original protocol........................................ 420
14.7 Fix for the first bug (A), and second bug found by S PIN (B), involving
three masters. .............................................................................................. 421
14.8 Extended broadcast channel. ...................................................................... 423
14.9 Extended time model. ................................................................................. 424
14.10 Silent master failure.................................................................................... 425

15.1 Memory management unit (MMU) and address translation....................... 429

15.2 MMU address translation and memory protection principle...................... 430
15.3 MPU memory protection principle............................................................. 435
15.4 Memory protection by means of checksumming techniques. .................... 441
15.5 Checksumming technique applied to message passing. ............................. 443
15.6 Principle of lookup table-based CRC calculation....................................... 448
15.7 Structure marking and invalid pointer detection......................................... 456
15.8 Stack overflow detection by means of a guard area.................................... 462
15.9 State of task stack after a stack overflow. ................................................... 465

16.1 Nomenclature of object and object pointer states....................................... 482

List of Tables

2.1 Microcontrollers versus General-Purpose Processors .................................. 29

2.2 Embedded versus General-Purpose Software Development
Environments ................................................................................................ 37

3.1 GNU make Command Line Execution Options ........................................... 71

3.2 GNU make Assignment Operators ............................................................... 73
3.3 GNU make Automatic Variables .................................................................. 75

4.1 A Simple Task Set for a Cyclic Executive.................................................... 85

4.2 A Task Set That Requires Task Splitting to Be Scheduled........................... 87
4.3 A Task Set Including a Task with a Large Period......................................... 89
4.4 A Task Set to Be Scheduled by the Rate Monotonic Algorithm .................. 98

5.1 Task Management Primitives of F REE RTOS............................................. 106

5.2 Time-Related Primitives of F REE RTOS .................................................... 112
5.3 Semaphore Creation/Deletion Primitives of F REE RTOS .......................... 121
5.4 Semaphore Manipulation Primitives of F REE RTOS ................................. 122
5.5 Message Passing Primitives of F REE RTOS............................................... 131

6.1 Notation for Real-Time Scheduling Algorithms and Analysis................... 140

6.2 Task Set with U ≃ 0.9 Schedulable by Rate Monotonic ............................ 146
6.3 Task Set with U ≃ 0.9 Not Schedulable by Rate Monotonic ..................... 148

7.1 LW IP Operating System Interface and Corresponding F REE RTOS

Facilities...................................................................................................... 168
7.2 Main LW IP Protocol Enable/Disable Options ............................................ 170
7.3 Main LW IP Protocol–Specific Configuration Options ............................... 171
7.4 Main LW IP Memory Management Configuration Options ........................ 173
7.5 Other Important LW IP Configuration Options ........................................... 175
7.6 Main Functions of the netconn Networking API .................................... 176
7.7 Main LW IP netconn Types ...................................................................... 177
7.8 LW IP Network Buffer Management Functions .......................................... 183
7.9 Main Functions of the POSIX sockets API............................................ 188

9.1 Minimum Range of Basic Integer Data Types Specified by

the C Standard............................................................................................. 248
9.2 Extended Integer Data Types Specified by the C99 Standard .................... 249
9.3 Minimum and Maximum Values of C99 Integer Data Types ..................... 250
9.4 Main Compiler Flags Related to Language Standards and Dialects .......... 251
9.5 Main Compiler Flags Related to Code Portability ..................................... 252

xxv
xxvi List of Tables

9.6 Main Object Attributes, Cortex-M3 GCC Toolchain................................. 260

9.7 Main Assembly Operand Constraints Specifiers ........................................ 271

10.1 Object-Like Macros to Be Provided by the F REE RTOS Porting Layer .... 276
10.2 Function-Like Macros to Be Provided by the F REE RTOS
Porting Layer .............................................................................................. 277
10.3 Data Types to Be Provided by the F REE RTOS Porting Layer................... 278
10.4 Functions to Be Provided by the F REE RTOS Porting Layer..................... 278

11.1 Compiler Options to Dump the Internal Code Representation................... 304

11.2 Compiler Options That Control Optimization............................................ 317
11.3 Additional Optimizations Enabled by Optimization Level 3 ..................... 318
11.4 Main Architecture-Dependent Compiler Options, ARM Architecture ...... 321
11.5 Interpolated Encoder Delay, ARM7 Architecture ...................................... 332

12.1 Software Development Toolchain Components ......................................... 344

12.2 F REE MODBUS TCP/IP Protocol Stack Interface Functions.................... 349
12.3 F REE MODBUS Operating System Adaptation Functions........................ 353
12.4 F REE MODBUS M ODBUS TCP Layer Functions ..................................... 357
12.5 F REE MODBUS Application Layer Functions .......................................... 359
12.6 Links between the Application Layer and the M ODBUS TCP Layer......... 359
12.7 FAT FS Main Configuration Options........................................................... 361
12.8 Filesystem Requirements Concerning Disk I/O ......................................... 362
12.9 Filesystem Requirements upon the Operating System and Runtime
Library ........................................................................................................ 363
12.10 USB Host Controller Driver Interfaces....................................................... 366
12.11 Main USB Mass Storage Interface Entry Points ........................................ 367
12.12 Firmware Memory Footprint ...................................................................... 370
12.13 M ODBUS Communication Performance, Write Multiple Registers........... 371
12.14 Filesystem Performance, Read and Append Rates ..................................... 372

13.1 Basic P ROMELA Data Types on a Typical 32-Bit Architecture.................. 383

13.2 Summary of P ROMELA Operators in Decreasing Precedence Order ......... 386

14.1 Original (N) and Additional (A) Transitions of the Election Protocol’s
Timed FSM ................................................................................................. 412

15.1 Fields of a Typical Memory Procection Unit (MPU) Region

Table Entry.................................................................................................. 436
15.2 Access Permission Field Encoding in the ARM MPU............................... 437
15.3 Comparison between MMU and MPU Features and Their
Implementation ........................................................................................... 439
15.4 F REE RTOS Configuration Variables Related to Stack
Overflow Checks......................................................................................... 461
List of Tables xxvii

16.1 S PLINT Mode Selector Flags...................................................................... 469

16.2 S PLINT Flags Related to Basic Checks ...................................................... 479
16.3 S PLINT Annotations Related to Basic Checks ........................................... 480
16.4 Kinds of Pointers and Their Usage............................................................. 483
16.5 S PLINT Flags Related to Memory Management ........................................ 493
16.6 S PLINT Annotations Related to Memory Management ............................. 494
16.7 S PLINT Flags Related to Buffer Overflow Checks..................................... 500
16.8 S PLINT Annotations Related to Buffer Overflow Checks.......................... 501
16.9 S PLINT Annotations for Function Interfaces.............................................. 502
 1 Introduction
The goal of this book is to introduce readers to embedded software development.
This is a very broad subject and encompasses several important topics in computer
science and engineering—for instance, operating systems, concurrent programming,
compilers, code optimization, hardware interfaces, testing, and verification.
Each topic is quite complex by itself and very well deserves one whole textbook,
or probably more, to be thoroughly discussed. Unfortunately, since most of those
textbooks concentrate on one specific topic, their styles of writing are usually far
away from each other.
For instance, concurrent programming is often presented using a formal approach
based on an abstract mathematical model for describing a computer system and the
concurrent activities it must execute, along with their data dependencies and syn-
chronization constraints.
Such an approach is perfectly fine, provided that the reader has enough available
time to fully grasp the model and enough experience to realize how a real system and
its requirements fit into the model itself.
On the opposite side, standalone descriptions of how embedded hardware devices
interface with a microcontroller are usually compiled by hardware engineers. As a
consequence, although they are perfectly correct for what concerns the content, their
point of view may easily be quite far away from what a programmer expects.
As a consequence, readers are left with the hard task of mixing and matching all
these valuable sources of information, which sometimes use their own nomenclature
and jargon, in order to build their own unified, consistent knowledge about embedded
software development in their minds.
This might hardly be feasible when the reader is just entering the embedded soft-
ware development domain as a novice. The problem is further compounded by the
fact that the embedded software development process is quite different from its
general-purpose counterpart. Hence, previous experience in writing, for instance,
PC-based applications, may not be easy to leverage in the new domain.
This book takes a rather different path. In fact, all basic topics presented in the
first part of the book are discussed by following a unified approach and consistently
emphasizing their relationships and mutual dependencies, rather than isolating them
in their own world.
For instance, the description of a central topic like interrupt handling is carried
out starting from the hardware event that may trigger an interrupt request, and then
guiding the reader through the whole process—partly performed by hardware, and
partly by software—that eventually culminates in the execution of the corresponding
interrupt handling routine.
In this way, readers gain a complete understanding of several aspects of interrupt
handling that are often kept “behind the scenes” in general-purpose programming,

1
2 Embedded Software Development: The Open-Source Approach

but are indeed of utmost importance to guarantee that embedded systems work reli-
ably and efficiently.
Furthermore, virtually all chapters in the first part of the book make explicit ref-
erence to real fragments of code and, when necessary, to a specific operating system,
that is, F REE RTOS. This also addresses a shortcoming of other textbooks, that is, the
lack of practical programming examples presented and commented on in the main
text (some provide specific examples in appendices).
From this point of view F REE RTOS is an extremely useful case study because it
has a very limited memory footprint and execution-time overhead, but still provides
a quite comprehensive range of primitives.
In fact, it supports a multithreaded programming model with synchronization and
communication primitives that are not far away from those available on much bigger,
and more complex systems. Moreover, thanks to its features, is has successfully been
used in a variety of real-world embedded applications.
At the same time, it is still simple enough to be discussed in a relatively detailed
way within a limited number of pages and without overwhelming the reader with
information. This also applies to its hardware abstraction layer—that is, the code
module that layers the operating system on top of a specific hardware architecture—
which is often considered an “off-limits” topic in other operating systems.
As a final remark, the book title explicitly draws attention to the open-source
approach to software development. In fact, even though the usage of open-source
components, at least in some scenarios (like industrial or automotive applications)
is still limited nowadays, it is the authors’ opinion that open-source solutions will
enjoy an ever-increasing popularity in the future.
For this reason, all the software components mentioned and taken as examples
in this book—from the software development environment to the real-time operat-
ing system, passing through the compiler and the software analysis and verification
tools—are themselves open-source.

The first part of the book guides the reader through the key aspects of embed-
ded software development, spanning from the peculiar requirements of embedded
systems in contrast to their general-purpose counterparts, without forgetting network
communication, implemented by means of open-source protocol stacks.
In fact, even though the focus of this book is mainly on software development
techniques, most embedded systems are nowadays networked or distributed, that is,
they consist of a multitude of nodes that cooperate by communicating through a
network. For this reason, embedded programmers must definitely be aware of the
opportunities and advantages that adding network connectivity to the systems they
design and develop may bring.
The chapters of the first part of the book are:

• Chapter 2, Embedded Applications and Their Requirements. This chapter

outlines the role and purpose of embedded systems, introducing readers to
Introduction 3

their internal structure and to the most common way they are interfaced
to software development tools. The chapter also gives a first overview of
the embedded software development process, to be further expanded in the
following.
• Chapter 3, GCC-Based Software Development Tools. The main topic
of this chapter is a thorough description of the GNU compiler collec-
tion (GCC)-based software development system, or toolchain, which is ar-
guably the most popular open-source product of this kind in use nowadays.
The discussion goes through the main toolchain components and provides
insights on their inner workings, focusing in particular on the aspects that
may affect programmers’ productivity,
• Chapter 4, Execution Models for Embedded Systems. This chapter and the
next provide readers with the necessary foundations to design and imple-
ment embedded system software. Namely, this chapter presents in detail
two different software execution models that can be profitably applied to
model and express the key concept of concurrency, that is, the parallel ex-
ecution of multiple activities, or tasks, within the same software system.
• Chapter 5, Concurrent Programming Techniques. In this chapter, the con-
cept of execution model is further expanded to discuss in detail how con-
currency must be managed to achieve correct and timely results, by means
of appropriate concurrent programming techniques.
• Chapter 6, Scheduling Algorithms and Analysis. After introducing some
basic nomenclature, models, and concepts related to task-based scheduling
algorithms, this chapter describes the most widespread ones, that is, rate
monotonic (RM) and earliest deadline first (EDF). The second part of the
chapter briefly discusses scheduling analysis, a technique that allows pro-
grammers to predict the worst-case timing behavior of their systems.
• Chapter 7, Configuration and Usage of Open-Source Protocol Stacks.
In recent years, many embedded systems rapidly evolved from central-
ized to networked or distributed architectures, due to the clear advan-
tages this approach brings. In this chapter, we illustrate how an open-
source protocol stack—which provides the necessary support for inter-node
communication—can easily be integrated in an embedded software system
and how it interfaces with other software components.
• Chapter 8, Device Driver Development. Here, the discourse goes from the
higher-level topics addressed in the previous three chapters to a greater level
of detail, concerning how software manages and drives hardware devices.
This is an aspect often neglected in general-purpose software development,
but of utmost importance when embedded systems are considered, because
virtually all of them are strongly tied to at least some dedicated hardware.
• Chapter 9, Portable Software. While the previous chapters set the stage
for effective embedded software development, this chapter outlines the all-
important trade-off between code execution efficiency and portability, that
is, easiness of migrating software from one project to another. This aspect
4 Embedded Software Development: The Open-Source Approach

is becoming more and more important nowadays due to the ever-increasing

need to reduce time to market and to implement quick prototyping.
• Chapter 10, The F REE RTOS Porting Layer. This technically oriented chap-
ter scrutinizes the main components of the F REE RTOS porting layer, div-
ing into the implementation details of key operating system concepts, for
instance, context switching and the implementation of low-level critical re-
gions by disabling interrupts.
• Chapter 11, Performance and Footprint at the Toolchain Level. This chapter
illustrates, by means of a running real-world example for the most part, how
a modern high-level software development toolchain can be used to achieve
a satisfactory level of optimization, for what concerns both execution speed
and memory footprint, without resorting to assembly-level programming or
other non-portable software development techniques.
• Chapter 12, Example: A M ODBUS TCP Device. To conclude the first part
of the book, this chapter contains a comprehensive example of how the
software development techniques described in the previous chapters can be
applied to design and build a simple, but complete embedded system.

In the second part, the book presents a few advanced topics, focusing mainly on
improving software quality and dependability. The importance of these goals is ever
increasing nowadays, as embedded systems are becoming commonplace in critical
application areas, like anti-lock braking system (ABS) and motion control.
In order to reach the goal, it is necessary to adopt a range of different techniques,
spanning from the software design phase to runtime execution, passing through its
implementation. In particular, this book first presents the basic principles of formal
verification through model checking, which can profitably be used since the very
early stages of algorithm and software design.
Then, a selection of runtime techniques to prevent or, at least, detect memory
corruption are discussed. Those techniques are useful to catch any software error
that escaped verification and testing, and keep within bounds the damage it can do to
the system and its surroundings.
Somewhat in between these two extremes, static code analysis techniques are use-
ful, too, to spot latent software defects that may escape manual code inspection. With
respect to formal verification, static code analysis techniques have the advantage of
working directly on the actual source code, rather than on a more abstract model.
Moreover, their practical application became easier in recent years because sev-
eral analysis tools moved away from being research prototypes and became stable
enough for production use. The book focuses on one of them as an example.
The second part of the book consists of the following chapters:

• Chapter 13, Model Checking of Distributed and Concurrent Systems. This

chapter describes how formal verification, and model checking in partic-
ular, can be profitably used to improve software quality and even prove
that it satisfies some critical requirements. The practical advantages of this
Introduction 5

technique become evident as embedded software complexity grows, thus

limiting the effectiveness of more traditional testing techniques.
• Chapter 14, Model Checking: An Example. Building upon the general con-
cept of model checking introduced previously, this chapter shows the appli-
cation of model checking to a case study of practical, industrial interest. It
demonstrates how model checking can be used to identify low-probability
defects that may never be observed during testing, and how counterexam-
ples found by the model checker can be helpful to correct them.
• Chapter 15, Memory Protection Techniques. Since it is usually impossible
to design and develop perfect software, even after extensive testing and
formal verification, another way to enhance software dependability is to
introduce various runtime checks. This chapter focuses on several specific
kinds of check, aimed at preventing or detecting memory corruption.
• Chapter 16, Security and Dependability Aspects. This chapter describes
how software dependability can be further enhanced by means of sophisti-
cated static code analysis techniques, which go beyond what an ordinary
compiler is able to do. Furthermore, the same techniques also enhance
software quality from what concerns security attacks, an aspect of utmost
importance as embedded systems are nowadays often connected to public
communication networks.

The bibliography at the end of the book has been kept rather short because it has
been compiled with software practitioners in mind. Hence, instead of providing an
exhaustive and detailed list of references that would have been of interest mainly to
people willing to dive deep into the theoretical aspects of embedded real-time sys-
tems, we decided to highlight a smaller number of additional sources of information.
In this way, readers can more effectively use the bibliography as a starting point
to seek further knowledge on this rather vast field, without getting lost. Within the
works we cite, readers will also find further, more specific pointers to pursue their
quest.
Part I

Basics of Embedded Software

Development
 2 Embedded Applications
and Their Requirements

CONTENTS
2.1 Role and Purpose of Embedded Systems .......................................................... 9
2.2 Microcontrollers and Their Internal Structure................................................. 13
2.2.1 Flash Memory..................................................................................... 15
2.2.2 Static Random Access Memory (SRAM)........................................... 17
2.2.3 External Memory ................................................................................ 19
2.2.4 On-Chip Interconnection Architecture ............................................... 23
2.3 General-Purpose Processors versus Microcontrollers ..................................... 29
2.4 Embedded Software Development Process ..................................................... 32
2.5 Summary.......................................................................................................... 37

This chapter outlines the central role played by embedded software in a variety of
contemporary appliances. At the same time, it compares embedded and general-
purpose computing systems from the hardware architecture and software develop-
ment points of view. This is useful to clarify and highlight why embedded software
development differs from application software development for personal computers
most readers are already familiar with.

2.1 ROLE AND PURPOSE OF EMBEDDED SYSTEMS

Nowadays, embedded systems are becoming more and more popular and
widespread. They are omnipresent from our daily life to different sections of in-
dustry. For example, even simple consumer appliances, such as microwave ovens,
washing machines, fridges and so on, include several microcontrollers to perform
predefined sets of functions/procedures.
Embedded systems also play a significant role in the development of smart homes
and building automation. Embedded nodes are installed to assess changes in opera-
tional environment—for instance, to detect that nobody is in a room—and carry out
corresponding actions—for instance, turn off all the lights automatically.
This kind of automation is quite helpful as saving energy is becoming a bigger
concern day by day. The same embedded computer may also be used to complete
other kinds of activities, for example, personnel access control to buildings based on
digital identification like badges.

9
10 Embedded Software Development: The Open-Source Approach

What’s more, embedded systems are deeply involved in the transportation indus-
try, especially automotive. It is quite common to find that even inexpensive cars are
equipped with more than 10 embedded nodes, including those used for anti-lock
braking system (ABS). For what concerns industry automation, embedded systems
are deployed in production lines to carry out all sorts of activities, ranging from mo-
tion control to packaging, data collection, and so on.
The main concerns of embedded systems design and development are different
from general-purpose systems. Embedded systems are generally equipped with lim-
ited resources, for instance, small amount of memory, low clock frequency, leading to
the need for better code optimization strategies. However, fast CPUs sometimes sim-
ply cannot be adopted in industrial environments because they are supposed to work
within a much narrower range of temperature, for instance [0, 40] degrees Celsius.
Instead, industrial-grade microprocessors are generally assumed to perform sus-
tainable correct functioning even up to 85 degrees. This leads to one main concern
of embedded systems, that is reliability, which encompasses hardware, software, and
communication protocol design. In addition, processor heat dissipation in such envi-
ronments is another issue if they are working at a high frequency.
All these differences bring unavoidable changes in the way embedded software
is developed, in contrast with the ordinary, general-purpose software development
process, which is already well known to readers. The main purpose of this chapter is
to outline those differences and explain how they affect programmers’ activities and
way of working.
In turn, this puts the focus on how to make the best possible use of the limited
resources available in an embedded system by means of code optimization. As out-
lined above, this topic is of more importance in embedded software development
with respect to general-purpose development, because resource constraints are usu-
ally stronger in the first case.
Moreover, most embedded systems have to deal with real-world events, for in-
stance, continuously changing environmental parameters, user commands, and oth-
ers. Since in the real world events inherently take place independently from each
other and in parallel, it is natural that embedded software has to support some form
of parallel, or concurrent execution. From the software development point of view,
this is generally done by organizing the code as a set of activities, or tasks, which are
carried out concurrently by a real-time operating system (RTOS).
The concept of task—often also called process—was first introduced in the semi-
nal work of Dijkstra [48]. In this model, any concurrent application, regardless of its
nature or complexity, is represented by, and organized as, a set of tasks that, concep-
tually, execute in parallel.
Each task is autonomous and holds all the information needed to represent the
evolving execution state of a sequential program. This necessarily includes not only
the program instructions but also the state of the processor (program counter, regis-
ters) and memory (variables).
Informally speaking, each task can be regarded as the execution of a sequential
program by “its own” conceptual processor even though, in a single-processor sys-
Embedded Applications and Their Requirements 11

tem the RTOS will actually implement concurrent execution by switching the physi-
cal processor from one task to another when circumstances warrant.
Therefore, thoroughly understanding the details of how tasks are executed, or
scheduled, by the operating system and being aware of the most common concurrent
programming techniques is of great importance for successful embedded software
development. This is the topic of Chapters 4 through 6.
In the past, the development of embedded systems has witnessed the evolution
from centralized to distributed architectures. This is because, first of all, the easiest
way to cope with the increasing need for more and more computing power is to
use a larger number of processors to share the computing load. Secondly, as their
complexity grows, centralized systems cannot scale up as well as distributed systems.
A simple example is that, in a centralized system, one more input point may re-
quire one more pair of wires to bring data to the CPU for processing. Instead, in a
distributed system, many different Inputs/Outputs values can be transmitted to other
nodes for processing through the same shared communication link. Last but not the
least, with time, it becomes more and more important to integrate different subsys-
tems, not only horizontally but also vertically.
For example, the use of buses and networks at the factory level makes it much eas-
ier to integrate it into the factory management hierarchy and support better business
decisions. Moreover, it is becoming more and more common to connect embedded
systems to the Internet for a variety of purposes, for instance, to provide a web-based
user interface, support firmware updates, be able to exchange data with other equip-
ment, and so on.
For this reason protocol stacks, that is, software components which implement
a set of related communication protocols—for instance, the ubiquitous TCP/IP
protocols—play an ever-increasing role in all kinds of embedded systems. Chap-
ter 7 presents in detail how a popular open-source TCP/IP protocol stack can be
interfaced, integrated, and configured for use within an embedded system.
For the same reason Chapter 8, besides illustrating in generic terms how software
and hardware shall be interfaced in an embedded system—by means of suitable de-
vice drivers—also shows an example of how protocol stacks can be interfaced with
the network hardware they work with.
Another major consideration in embedded systems design and development is
cost, including both hardware and software, as nowadays software cost is growing
and becomes as important as hardware cost. For what concerns software, if existing
applications and software modules can be largely reused, this could significantly
save time and effort, and hence, reduce cost when integrating different subsystems
or upgrading the current system with more advanced techniques/technologies.
An important milestone toward this goal, besides the adoption of appropriate soft-
ware engineering methods (which are outside the scope of this book), consists of
writing portable code. As discussed in Chapters 9 and 10, an important property of
portable code is that it can be easily compiled, or ported, to diverse hardware archi-
tectures with a minimum amount of change.
12 Embedded Software Development: The Open-Source Approach

This property, besides reducing software development time and effort—as out-
lined previously—also brings the additional benefit of improving software reliability
because less code must be written anew and debugged when an application is moved
from one architecture to another. In turn, this topic is closely related to code opti-
mization techniques, which are the topic of Chapter 11.
Generally, embedded systems also enforce requirements on real-time perfor-
mance. It could be soft real-time in the case of consumer appliances and building au-
tomation, instead of hard real-time for critical systems like ABS and motion control.
More specifically, two main aspects directly related to real-time are delay and
jitter. Delay is the amount of time taken to complete a certain job, for example,
how long it takes a command message to reach the target and be executed. Delay
variability gives rise to jitter. For example, jobs are completed sometimes sooner,
sometimes later.
Hard real-time systems tolerate much less jitter than their counterparts and they
require the system to behave in a more deterministic way. This is because, in a hard
real-time system, deadlines must always be met and any jitter that results in missing
the deadline is unacceptable. Instead, this is allowed in soft real-time systems, as
long as the probability is sufficiently small. This also explains why jitter is generally
more of concern. Several of these important aspects of software development will be
considered in more detail in Chapter 12, within the context of a real-world example.
As we can see, in several circumstances, embedded systems also have rather tight
dependability requirements that, if not met, could easily lead to safety issues, which
is another big concern in some kinds of embedded systems. Safety is not only about
the functional correctness (including the timing aspect) of a system but also related
to the security aspect of a system, especially since embedded systems nowadays are
also network-based and an insecure system is often bound to be unsafe.
Therefore, embedded software must often be tested more accurately than general-
purpose software. In some cases, embedded software correctness must be ensured
not only through careful testing, but also by means of formal verification. This topic
is described in Chapter 13 from the theoretical point of view and further developed
in Chapter 14 by means of a practical example. Further information about security
and dependability, and how they can be improved by means of automatic software
analysis tools, is contained in Chapter 16.
A further consequence, related to both code reliability and security, of the limited
hardware resources available in embedded architectures with respect to their general-
purpose counterparts, is that the hardware itself may provide very limited support to
detect software issues as early as possible and before damage is done to the system.
From this point of view, the software issue of most interest is memory corruption
that takes place when part of a memory-resident data structure is overwritten with
inconsistent data, often due to a wayward task that has no direct relationship with
the data structure itself. This issue is also often quite difficult to detect, because the
effects of memory corruption may be subtle and become manifest a long time after
the corruption actually took place.
Embedded Applications and Their Requirements 13

In order to tackle memory corruption, general-purpose processors are almost in-

variably equipped with sophisticated hardware components logically interposed be-
tween the processor itself and main memory, which are usually called memory man-
agement units (MMUs). Besides providing other useful memory-management fea-
tures, a MMU allows the RTOS to specify which areas or memory a certain task is
allowed to access and in which way (for instance, read-only data access, read-write
data access, or instruction execution).
The MMU is able to trap any attempt made by a task to access a forbidden mem-
ory area or the use of a forbidden access mode before the access actually takes place,
and hence, before memory is corrupted or, for read accesses, before the task gains
access to information that does not pertain to it. When the MMU detects an illegal
access, the offending task stops executing, the RTOS takes control of the processor
and initiates a recovery action, which often involves the termination of the task itself.
To limit their cost and power consumption, embedded processors rarely imple-
ment a full-fledged MMU. Instead, some of them do provide a scaled-down version
of this component, which can perform only memory protection, often in a simplified
way with respect to an ordinary MMU. For instance, in the ARM Cortex family of
processor cores [8] this feature is optionally provided by a component called memory
protection unit (MPU), which is part of a broader protected memory system archi-
tecture (PMSA).
However, more often than not, low-cost microcontrollers offer no hardware-based
support for memory protection. As a consequence, programmers shall resort to
software-based protection techniques when required, even though those techniques
are merely able to detect memory corruption rather than prevent it. A more detailed
discussion of the different classes of memory protection usually available on embed-
ded systems will be the topic of Chapter 15.

2.2 MICROCONTROLLERS AND THEIR INTERNAL STRUCTURE

The recent advances in microcontroller design and implementation made their inter-
nal structure quite complex and very similar to the structure of a whole computer
system built twenty years ago. As a result, even inexpensive microcontrollers nowa-
days embed a variety of other elements besides the processor itself.
As shown in Figure 2.1, a microcontroller typically contains:

• One or more processor cores, which are the functional units responsible for
program execution.
• Multiple internal memory banks, with different characteristics regarding
capacity, speed, and volatility.
• Optionally, one or more memory controllers to interface the microcontroller
with additional, external memory.
• A variety of input–output controllers and devices, ranging from very
simple, low-speed devices like asynchronous serial receivers/transmitters
to very fast and complex ones, like Ethernet and USB controllers.
14 Embedded Software Development: The Open-Source Approach

Figure 2.1 Internal structure of a microcontroller (simplified).

• A bank of multiplexers and demultiplexers to route the on-chip input and

output signals associated with the memory controllers and the various in-
ternal devices toward the microcontroller external input–output ports.
• A communication infrastructure to let all the above-mentioned units ex-
change data and synchronization information.
• One or more clock generators, along with a clock and power distribution
network. Both networks are used to provide an appropriate clock and power
supply to the microcontroller units in a selective way. This is useful in order
to save power, for instance, by removing clock and power from units that
are unused in a certain application.

Is is therefore evident that, even though most of this book will focus on the pro-
cessing capabilities of microcontrollers, in terms of program execution, it is ex-
tremely important to consider the microcontroller architecture as a whole during
component selection, as well as software design and development.
For this reason, this chapter contains a brief overview of the major components
outlined above, with special emphasis on the role they play from the programmer’s
perspective. Interested readers are referred to more specific literature [50, 154] for
detailed information. After a specific microcontroller has been selected for use, its
hardware data sheet of course becomes the most authoritative reference on this topic.
Embedded Applications and Their Requirements 15

Arguably the most important component to be understood and taken into account
when designing and implementing embedded software is memory. In fact, if it is true
that processor cores are responsible for instruction execution, those instructions are
stored in memory and must be continuously retrieved, or fetched, from memory to
be executed.
Moreover, program instructions heavily refer to, and work on, data that are stored
in memory, too. In a similar way, processor cores almost invariably make use of
one or more memory-resident stacks to hold arguments, local variables, and return
addresses upon function calls.
This all-important data structure is therefore referenced implicitly upon each func-
tion call (to store input arguments and the return address into it), during the call itself
(to retrieve input arguments, access local variables, and store function results), and
after the call (to retrieve results).
As a consequence, the performance and determinism of a certain program is
deeply affected, albeit indirectly, by the exact location of its instructions, data, and
stacks in the microcontroller’s memory banks. This dependency is easily forgotten
by just looking at the program source code because, more often than not, it simply
does not contain this kind of information.
This is because most programming languages (including the C language this book
focuses on) do allow the programmer to specify the abstract storage class of a vari-
able (for instance, whether a variable is local or global, read-only or read-write,
and so on) but they do not support any standard mechanisms that allow program-
mers to indicate more precisely where (in which memory bank) that variable will be
allocated.
As will be better described in Chapters 3 and 9, this important goal must there-
fore be pursued in a different way, by means of other components of the software
development toolchain. In this case, as shown in Figure 2.2, the linker plays a central
role because it is the component responsible for the final allocation of all memory-
resident objects defined by the program (encompassing both code and data), to fit the
available memory banks.
Namely, compiler-dependent extensions of the programming language are first
used to tag specific functions and data structures in the source code, to specify where
they should be allocated in a symbolic way. Then, the linker is instructed to pick up
all the objects tagged in a certain way and allocate them in a specific memory bank,
rather than using the default allocation method.
An example of this strategy for a GCC-based toolchain will be given in Chapters 8
and 11, where it will be used to distribute the data structures needed by the example
programs among the memory banks available on the microcontroller under study. A
higher-level and more thorough description of the technique, in the broader context
of software portability, will be given in Chapter 9 instead.

2.2.1 FLASH MEMORY

The two most widespread kinds of internal memory are flash memory and static
random access memory (SRAM). Flash memory is non-volatile, that is, it does not
16 Embedded Software Development: The Open-Source Approach

Figure 2.2 Allocation of program objects in different memory banks.

lose its contents when power is removed from the microcontroller. On the other hand,
it works as a read-only memory during normal use.
Write operations into flash memory are indeed possible, but they require a special
procedure (normal store operations performed by the processor are usually not ade-
quate to this purpose), are relatively slow (several orders of magnitude slower than
read operations) and, in some cases, they can only be performed when the microcon-
troller is put into a special operating mode by means of dedicated tools.
Flash memory is usually used to store the program code (that, on recent archi-
tectures, is read-only by definition), constant data, and the initial value of global
variables.
In many cases, flash memory is not as fast as the processor. Therefore, it may be
unable to sustain the peak transfer rate the processor may require for instruction and
data access, and it may also introduce undue delays or stalls in processing activities
if those accesses are performed on demand, that is, when the processor asks for them.
Embedded Applications and Their Requirements 17

For this reason, units of various complexity are used to try and predict the next
flash memory accesses that will be requested by the processor and execute them in
advance, while the processor is busy with other activities.
For instance, both the NXP LPC24xx and LPC17xx microcontroller fami-
lies [126, 128] embed a Memory accelerator module (MAM) that works in com-
bination with the flash memory controller to accelerate both code and data accesses
to flash memory.
In this way, if the prediction is successful, the processor is never stalled waiting for
flash memory access because processor activities and flash memory accesses proceed
concurrently.
On the other hand, if the prediction is unsuccessful, a processor stall will definitely
occur. Due to the fact that prediction techniques inherently work on a statistical basis,
it is often very hard or impossible to predict exactly when a stall will occur during
execution, and also for how long it will last. In turn, this introduces a certain degree
of non-determinism in program execution timings, which can hinder its real-time
properties in critical applications.
In those cases, it is important that programmers are aware of the existence of
the flash acceleration units just described and are able to turn them off (partially or
completely) in order to change the trade-off point between average performance and
execution determinism.

2.2.2 STATIC RANDOM ACCESS MEMORY (SRAM)

Static random access memory (SRAM), unlike flash memory, is volatile, that is, it
loses its value when power is removed from the microcontroller. As a consequence,
it cannot be used as a permanent storage location for code and data.
On the other hand, internal SRAM can be directly read and written by the proces-
sor and it is most often the fastest memory available in the whole system. As such,
it is able to feed instructions and data to the processor in a fully deterministic way,
without ever introducing any delay.
As a consequence, SRAM is commonly used to store global read-write variables
and to host the processor stacks. Moreover, it can also be used to store portions of
code for which execution speed and determinism are of utmost importance. How-
ever, SRAM code execution brings a couple of side effects that should be carefully
evaluated and taken into account.

1. Being SRAM volatile, it cannot be used to permanently retain the code, which
would otherwise be lost as soon as power is removed from the system. Hence, it
is necessary to store the code elsewhere, in a non-volatile memory (usually flash
memory) and copy it into SRAM at system startup, bringing additional complexity
to system initialization.
Furthermore, after the code has been copied, its execution address (that is, the
address at which it is executed by the processor) will no longer be the same as its
load address (the address of the memory area that the linker originally assigned
to it).
18 Embedded Software Development: The Open-Source Approach

This clearly becomes an issue if the code contains absolute memory addresses to
refer to instructions within the code itself, or other forms of position-dependent
code, because these references will no longer be correct after the copy and, if
followed, they will lead code execution back to flash memory.
This scenario can be handled in two different ways, at either the compiler or
linker level, but both require additional care and configuration instructions to
those toolchain components, as better described in Chapter 3. Namely:
• It is possible to configure the compiler—for instance, by means of appropriate
command-line options and often at the expense of performance—to gener-
ate position-independent code (PIC), that is, code that works correctly even
though it is moved at will within memory.
• Another option is to configure the linker so that it uses one base address (often
called load memory address (LMA)) as its target to store the code, but uses
a different base address (the virtual memory address (VMA)) to calculate and
generate absolute addresses.
2. When the code is spread across different memory banks—for instance, part of it
resides in flash memory while other parts are in SRAM—it becomes necessary to
jump from one bank to another during program execution—for instance, when a
flash-resident function calls a SRAM-resident function. However, memory banks
are often mapped far away from each other within the microcontroller’s address
range and the relative displacement, or offset, between addresses belonging to
different banks is large.
Modern microcontrollers often encode this offset in jump and call instructions
to locate the target address and, in order to reduce code size and improve per-
formance, implement several different instruction variants that support different
(narrower or wider) offset ranges. Compilers are unaware of the target address
when they generate jump and call instructions—as better explained in Chapter 3,
this is the linker’s responsibility instead. Hence they, by default, choose the in-
struction variant that represents the best trade-off between addressing capability
and instruction size.
While this instruction variant is perfectly adequate for jumps and calls among
functions stored in the same memory bank, the required address offset may not fit
into it when functions reside in different memory banks. For the reasons recalled
above, the compiler cannot detect this issue by itself. Instead, it leads to (generally
rather obscure) link-time errors and it may be hard for programmers to track these
errors back to their original cause.
Although virtually all compilers provide directives to force the use of an instruc-
tion variant that supports larger offsets for function calls, this feature has not
been envisaged in most programming language standards, including the C lan-
guage [89]. Therefore, as discussed in Chapter 9, compiler-dependent language
extensions have to be used to this purpose, severely impairing code portability.
3. When SRAM or, more in general, the same bank of memory is used by the pro-
cessor for more than one kind of access, for instance, to access both instructions
and data, memory contention may occur.
Embedded Applications and Their Requirements 19

In fact, processors are nowadays typically designed according to a Harvard-style

architecture [108] and have got multiple memory and peripheral access buses,
which can operate in parallel to enhance performance.
For instance, even the relatively simple and inexpensive NXP LPC17xx micro-
controller family [128] incorporates an ARM Cortex-M3 processor core [9] that
is equipped with three separate buses, one for instructions, another for data, and a
third one for peripheral access.
However, memory banks almost invariably provide a single access port, which
can accommodate only one read or write transaction at any given time, for the
bank as a whole. As a consequence, if the processor generates more than one
access request toward the same bank at the same time, albeit on separate buses,
these requests will no longer be satisfied in parallel because they will be serialized
at the memory access port level.
This means that the potential parallelism at the processor bus level can no longer
be exploited in this case and execution may be slowed down by the extra memory
access latency that comes as a consequence.
It should also be noted that further limitations to parallelism may also come
as a side effect of the on-chip interconnection architecture, to be described in
Section 2.2.4.
4. Last but not least, due to hardware-related considerations (for instance, chip area
and power consumption) SRAM is in scarce supply on most microcontrollers,
especially low-end ones. On the other hand, code size is relatively large, given
the growing trend to adopt reduced instruction set computing (RISC) processor
architectures rather than complex instruction set computing (CISC) ones. There-
fore, it’s essential to carefully scrutinize which portions of code shall indeed go
into SRAM to avoid depleting it.

2.2.3 EXTERNAL MEMORY

On some microcontrollers, it is also possible to add external memory, that is, memory
implemented by additional hardware components external to the microcontroller and
connected to it by a suitable bus. The external bus is managed by means of one or
more dedicated memory controllers resident on the microcontroller itself. The same
technique can also be used to connect high-speed external peripherals.
For what concerns memory, three main kinds of memory can be incorporated in a
system in this way:

• Flash memory
• SRAM
• Dynamic Random Access Memory (DRAM)

On them, external flash memory and SRAM share the same general characteris-
tics as their on-chip counterparts. Instead, DRAM is rarely found in commerce as
a kind of on-chip microcontroller memory, due to difficulties to make the two chip
production processes coexist. It is worth mentioning the main DRAM properties here
20 Embedded Software Development: The Open-Source Approach

because they have some important side effects on program execution, especially in an
embedded real-time system. Interested readers are referred to [155] for more detailed
information about this topic.
DRAM, like SRAM, is a random access memory, that is, the processor can freely
and directly read from and write into it, without using any special instructions or
procedures. However, there are two important differences concerning access delay
and jitter:

1. Due to its internal architecture, DRAM usually has a much higher capacity than
SRAM but read and write operations are slower. While both on-chip and external
SRAM are able to perform read and write operations at the same speed as the
processor, DRAM access times are one or two orders of magnitude higher in
most cases.
To avoid intolerable performance penalties, especially as processor speed grows,
DRAM access requires and relies on the interposition of another component,
called cache, which speeds up read and write operations. A cache is basically
a fast memory of limited capacity (much smaller than the total DRAM capacity),
which is as fast as SRAM and holds a copy of DRAM data recently accessed by
the processor.
The caching mechanism is based on widespread properties of programs, that is,
their memory access locality. Informally speaking, the term locality means that,
if a processor just made a memory access at a certain address, its next accesses
have a high probability to fall in the immediate vicinity of that address.
To persuade ourselves of this fact, by intuition, let us consider the two main kinds
of memory access that take place during program execution:
• Instruction fetch. This kind of memory access is inherently sequential in most
cases, the exception being jump and call instructions. However, they represent
a relatively small fraction of program instruction and many contemporary pro-
cessors provide a way to avoid them completely, at least for very short-range
conditional jumps, by means of conditionally executed instructions. A thor-
ough description of how conditionally executed instructions work is beyond
the scope of this book. For instance, Reference [8] discusses in detail how they
have been implemented on the ARM Cortex family of processor cores.
• Data load and store. In typical embedded system applications, the most com-
monly used memory-resident data structure is the array, and arrays elements
are quite often (albeit not always) accessed within loops by means of some
sort of sequential indexing.
Cache memory is organized in fixed-size blocks, often called cache lines, which
are managed as an indivisible unit. Depending on the device, the block size usu-
ally is a power of 2 between 16 and 256 bytes. When the processor initiates a
transaction to read or write data at a certain address, the cache controller checks
whether or not a line containing those data is currently present in the cache.
• If the required data are found in the cache a fast read or write transaction, in-
volving only the cache itself and not memory, takes place. The fast transaction
Embedded Applications and Their Requirements 21

is performed at the processor’s usual speed and does not introduce any extra
delay. This possibility is called cache hit.
• Otherwise, the processor request gives origin to a cache miss. In this case, the
cache controller performs two distinct actions:
a. It selects an empty cache line. If the cache is completely full, this may
entail storing the contents of a full cache line back into memory, an oper-
ation known as eviction.
b. The cache line is filled with the data block that surrounds the address
targeted by the processor in the current transaction.
In the second case, the transaction requested by the processor finishes only after
the cache controller has completed both actions outlined previously. Therefore, a
cache miss entails a significant performance penalty from the processor’s point of
view, stemming from the extra time needed to perform memory operations.
On the other hand, further memory access transactions issued by the processor in
the future will likely hit the cache, due to memory access locality, with a signifi-
cant reduction in data access time.
From this summary description, it is evident that cache performance heavily de-
pends on memory access locality, which may vary from one program to another
and even within the same program, depending on its current activities.
An even more important observation, from the point of view of real-time embed-
ded systems design, is that although it is quite possible to satisfactorily assess the
average performance of a cache from a statistical point of view, the exact cache
behavior with respect to a specific data access is often hard to predict.
For instance, it is impossible to exclude scenarios in which a sequence of cache
misses occurs during the execution of a certain section of code, thus giving rise to
a worst-case execution time that is much larger than the average one.
To make the problem even more complex, cache behavior also depends in part on
events external to the task under analysis, such as the allocation of cache lines—
and, consequently, the eviction of other lines from the cache—due to memory
accesses performed by other tasks (possibly executed by other processor cores) or
interrupt handlers.
2. Unlike SRAM, DRAM is unable to retain its contents indefinitely, even though
power is continuously applied to it, unless a periodic refresh operation is per-
formed. Even though a detailed explanation of the (hardware-related) reasons for
this and of the exact procedure to be followed to perform a refresh cycle are
beyond the scope of this book, it is useful anyway to briefly recall its main conse-
quences on real-time code execution.
Firstly, it is necessary to highlight that during a refresh cycle DRAM is unable
to perform regular read and write transactions, which must be postponed, unless
advanced techniques such as hidden refresh cycles are adopted [155]. Therefore,
if the processor initiates a transaction while a refresh cycle is in progress, it will
incur additional delay—beyond the one needed for the memory access itself—
unless the transaction results in a cache hit.
Secondly, the exact time at which a refresh cycle starts is determined by the mem-
ory controller (depending on the requirements of the DRAM connected to it) and
not by the processor.
22 Embedded Software Development: The Open-Source Approach

As a consequence, even though the time needed to perform a refresh cycle is

small (of the same order of magnitude as a regular memory read or write op-
eration), from the processor’s point of view refresh cycles are seen as seemingly
unpredictable events that unexpectedly delay memory transactions and, more gen-
erally, program execution.
A further consideration concerning the external bus is about its speed and width
limitations, especially on low-end systems. Those limitations do not depend on the
devices attached to them and mainly depend on signal routing considerations, both
internal and external to the microcontroller chip.

• For what concerns internal signal routing, we already mentioned that typ-
ical microcontrollers have a limited number of external pins, which is not
big enough to route all internal input–output signals to the printed circuit
board (PCB).
The use of an external (parallel) bus is likely to consume a significant num-
ber of pins and make them unavailable for other purposes. A widespread
workaround for this issue is to artificially limit the external bus width to
save pins.
For instance, even tough 32-bit microcontrollers support an external 32-bit
bus, hardware designers may limit its width to 16 or even 8 bits.
Besides the obvious advantage in terms of how many pins are needed to
implement the external bus, a negative side-effect of this approach is that
more bus cycles become necessary to transfer the same amount of data.
Assuming that the bus speed is kept constant, this entails that more time is
needed, too.
• To simplify external signal routing hardware designers may also keep the
external bus speed slower than the maximum theoretically supported by the
microcontroller, besides reducing its width. This is beneficial for a variety
of reasons, of which only the two main ones are briefly presented here.
• It makes the system more tolerant to signal propagation time skews and
gives the designer more freedom to route the external bus, by means of
longer traces or traces of different lengths.
• Since a reduced number of PCB traces is required to connect the mi-
crocontroller to the external components, fewer routing conflicts arise
against other parts of the layout.

A rather extreme, but representative, example of how the number of external

wires needed to connect an external memory—flash memory in this case—can be
reduced to a minimum is represented by the recently introduced serial peripheral in-
terface (SPI) flash interface. This interface was first introduced in the personal com-
puter domain and is nowadays gaining popularity in the embedded system world,
too.
It can be configured as either a serial or a low-parallelism interface (from 1 to 4
data bits can be transferred in parallel) that needs only from a minimum of 3 to a
Embedded Applications and Their Requirements 23

maximum of 6 wires, plus ground, to be implemented. These figures are much lower
than what a parallel bus, even if its width is kept at 8 bits, requires.
As it is easy to imagine, the price to be paid is that this kind of interface is likely
unable to sustain the peak data transfer rate a recent processor requires, and the
interposition of a cache (which brings all the side effects mentioned previously) is
mandatory to bring average performance to a satisfactory level.
Regardless of the underlying reasons, those design choices are often bound to cap
the performance of external memory below its maximum. From the software point of
view, in order to assess program execution performance from external memory, it is
therefore important to evaluate not only the theoretical characteristics of the memory
components adopted in the system, but also the way they have been connected to the
microcontroller.

2.2.4 ON-CHIP INTERCONNECTION ARCHITECTURE

Besides the external connections mentioned previously, contemporary microcon-
trollers incorporate a significant number of internal connections, among functional
units residing on the same chip.
The overall on-chip interconnection architecture therefore plays a very signifi-
cant role in determining and, sometimes, limiting microcontroller performance and
determinism, as the external bus does with respect to external memory and devices.
Earlier system’s internal interconnections were based on a simple, single-bus
structure supporting only one data transfer operation, or transaction, at a time. To deal
with the growing complexity of microcontrollers, which nowadays embed internal
components of diverse speed and characteristics, and to achieve better modularity,
performance, and flexibility, bus-based architectures soon evolved in an interconnec-
tion infrastructure incorporating multiple heterogeneous buses, which communicate
by means of bridges.
For instance, as summarized in Figure 2.3, the LPC2468 microcontroller [125,
126] is equipped with the following internal buses:
• A local bus that connects the processor to the main SRAM bank and to the
fast general-purpose input-output (GPIO) ports.
• Two advanced high-performance bus (AHB) buses, hosting one high-
performance input-output controller each, namely Ethernet and USB, as
well as the two additional SRAM banks used by those controllers for data
storage. One of the AHB buses also hosts the external memory controller,
through which external memory and devices can be accessed, as explained
in Section 2.2.3.
• One advanced peripheral bus (APB) bus shared among all the other, lower-
performance peripherals like, for instance, CAN controllers.

The components connected to a bus can be categorized into two different classes:

1. Bus masters, which are able to initiate a read or write transaction on the bus,
targeting a certain slave.
24 Embedded Software Development: The Open-Source Approach

Figure 2.3 Bus- and bridge-based on-chip interconnection.

2. Bus slaves, which can respond to transactions initiated by masters, but cannot
initiate a transaction on their own.
A typical example of bus master is, of course, the processor. However, peripheral
devices may act as bus masters, too, when they are capable of autonomous direct
memory access (DMA) to directly retrieve data from, and store them to, memory
without processor intervention.
A different approach to DMA, which does not require devices to be bus masters,
consists of relying on a general-purpose DMA controller, external to the devices. The
DMA controller itself is a bus master and performs DMA by issuing two distinct bus
transactions, one targeting the device and the other one targeting memory, on behalf
of the slaves.
For instance, to transfer a data item from a device into memory, the DMA con-
troller will first wait for a trigger from the device, issue a read transaction targeting
Embedded Applications and Their Requirements 25

the device (to read the data item from its registers), and then issue a write trans-
action targeting memory (to store the data item at the appropriate address). This
approach simplifies device implementation and allows multiple devices to share the
same DMA hardware, provided they will not need to use it at the same time.
In order to identify which slave is targeted by the master in a certain transaction,
masters provide the target’s address for each transaction and slaves respond to a
unique range of addresses within the system’s address space. The same technique is
also used by bridges to recognize when they should forward a transaction from one
bus to the other.
Each bus supports only one ongoing transaction at a time. Therefore all bus mas-
ters connected to the same bus must compete for bus access by means of an arbitra-
tion mechanism. The bus arbiter chooses which master can proceed and forces the
others to wait when multiple masters are willing to initiate a bus transaction at the
same time. On the contrary, several transactions can proceed in parallel on differ-
ent buses, provided those transactions are local to their bus, that is, no bridges are
involved.
As shown in Figure 2.3, buses are interconnected by means of a number of
bridges, depicted as gray blocks.
• Two bridges connect the local bus to the AHB buses. They let the proces-
sor access the controllers connected there, as well as the additional SRAM
banks.
• One additional bridge connects one of the AHB buses to the APB bus. All
transactions directed to the lower-performance peripherals go through this
bridge.
• The last bridge connects the two AHB buses together, to let the Ethernet
controller (on the left) access the SRAM bank residing on the other bus, as
well as external memory through the external memory controller.

The role of a bridge between two buses A and B is to allow a bus master M
residing, for instance, on bus A to access a bus slave S connected to bus B. In order
to do this, the bridge plays two different roles on the two buses at the same time:
• On bus A, it works as a bus slave and responds on behalf of S to the trans-
action initiated by M.
• On bus B, it works as a bus master, performing on behalf of M the transac-
tion directed to S.

The kind of bridge described so far is the simplest one and works in an asymmetric
way, that is, is able to forward transactions initiated on bus A (where its master port
is) toward bus B (where the slave port is), but not vice versa. For instance, referring
back to Figure 2.3, the AHB/AHB bridge can forward transactions initiated by a
master on the left-side AHB toward a slave connected to the right-side AHB, but not
the opposite.
Other, more complex bridges are symmetric instead and can assume both master
and slave roles on both buses, albeit not at the same time. Those bridges can also be
26 Embedded Software Development: The Open-Source Approach

seen as a pair of asymmetric bridges, one from A to B and the other from B to A,
and they are often implemented in this way.
As outlined above, bus arbitration mechanisms and bridges play a very important
role to determine the overall performance and determinism of the on-chip intercon-
nection architecture. It is therefore very important to consider them at design time
and, especially for what concerns bridges, make the best use of them in software.
When the processor (or another bus master) crosses a bridge to access memory
or a peripheral device controller, both the processor itself and the system as a whole
may incur a performance and determinism degradation. Namely:

• The processor clearly incurs a performance degradation when accessing

lower-speed peripheral buses, which may not be able to sustain the pro-
cessor’s peak data transfer rate. Moreover, depending on their internal
construction, bridges themselves may introduce additional delay besides
the time strictly required to perform the two bus transactions they are
coordinating.
The overall performance of the system may degrade, too, because a sin-
gle transaction spanning one or more bridges keeps multiple buses busy at
the same time and those buses are unable to support other simultaneous
transactions.
At the same time—unless the system implements more sophisticated bus
access protocols supporting split transactions—a transaction going from a
faster bus to a slower bus keeps the faster bus occupied for the time needed
to complete the transaction on the slower bus.
• Even more importantly for a real-time system, memory or peripheral access
times become less deterministic because, informally speaking, the more
bridges the transaction has to cross to reach its target, the more likely it
becomes that bus arbitration mechanisms introduce delay somewhere along
the path because of bus contention.

In order to evaluate the exact amount of contention to expect, it is important to

highlight once more that, although the processor can be considered the most im-
portant bus master in the system, some DMA-capable peripheral devices can act as
masters, too. Fast devices, such as the Ethernet controller, may indeed generate a
significant amount of bus traffic. In these cases, it is important to configure the bus
arbiter to give priority to the masters that are more critical from the real-time perfor-
mance point of view, if possible.
One last aspect worth mentioning is that bridges also play a crucial role in de-
termining slave accessibility from a certain master. In fact, in order for a master to
be able to successfully target a certain slave in a transaction it must be possible to
build a complete path from the master to the slave within the interconnection system,
possibly passing through one or more bridges.
If building such a path is impossible, then the bus master simply cannot access the
slave. This situation is possible especially for bus masters other than the processor,
and is indeed common especially on low-cost microcontrollers. As a consequence,