Search icon
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Over 7,000 tech titles at $9.99 each with AI-powered learning assistants on new releases
Hands-On Embedded Programming with C++17
Hands-On Embedded Programming with C++17

Hands-On Embedded Programming with C++17: Create versatile and robust embedded solutions for MCUs and RTOSes with modern C++

By Maya Posch
$35.99 $9.99
Full star icon Full star icon Full star icon Full star icon Full star icon 5 (1 Ratings)
Book Jan 2019 458 pages 1st Edition
$35.99 $9.99
$15.99 Monthly
$35.99 $9.99
$15.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Jan 31, 2019
Length 458 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781788629300
Vendor :
Category :
Table of content icon View table of contents Preview book icon Preview Book

Hands-On Embedded Programming with C++17

Chapter 1. What Are Embedded Systems?

Essentially, the embedded part of an embedded system refers to the state of being embedded into a larger system. The system that has been embedded is a computer system of some description, which has one or more very specific functions in the overall system, rather than being a general-purpose component. This larger system can be digital, mechanical, or analog in nature, while the additional integrated digital circuitry tightly interacts with data from and to interfaces, sensors and memory to implement the actual system functionality.

In this chapter, we will look at the following topics:

  • Different categories of embedded platforms
  • Examples of each category
  • Development challenges of each category

The many faces of embedded systems

Every computerized function in today's devices is implemented using one or multiple microprocessors, meaning a computer processor (central processing unit, or CPU) usually contained in a single integrated circuit (IC). The microprocessor comprises at least the arithmetic logic unit (ALU) and control circuitry, but logically also registers, and input/output (I/O) banks, in addition to more advanced features commonly tailored to a specific product category (wearables, low power sensors, mixed signal, ...) or market (consumer, medical, automotive, ...).

At this point in history, almost all microprocessors are found in embedded systems. Even though people are likely to possess a computer, laptop, and smartphone, maybe even a tablet, the number of embedded microprocessors in a given household far dwarfs the number of general-purpose microprocessors.

Even within a laptop or PC, there are a number of embedded microprocessors in addition to its general-purpose CPU. These microprocessors have tasks like handling keyboard or mouse input, processing touch-screen inputs, converting streams of data into Ethernet packages, or creating video or audio output.

In older systems, such as the Commodore 64, this same pattern can be seen, with a CPU IC, sound IC, video IC, and so on. Whereas the CPU runs whatever code the application developer has written, the other chips in the system have very specific purposes, down to the controller IC for the floppy or hard disk drive.

Outside of general-purpose computers, we find embedded microprocessors everywhere, often in the form of even further integrated MCUs. They control kitchen devices, washing machines, and the engines of our cars, in addition to the higher-level functions and the processing of sensor information.

While the first microwaves were analog devices, using mechanical timers and variable resistors to set power level and duration, today's microwaves contain at least one microcontroller, which is responsible for handling user input, driving a display of some type, and configuring the microwave's systems. The display itself can have its own microcontroller, depending on the complexity of the chosen configuration.

Perhaps more excitingly, embedded systems also provide monitoring, automation and fail-safe features that keep airplanes flying, ensure that guided missiles and space rockets perform as intended, and enable ever-increasing possibilities in areas such as medicine and robotics. The avionics of an airplane constantly monitor countless parameters from a multitude of sensors, running the same code on its triple-redundant configuration to detect any possible glitches.

Tiny yet powerful microprocessors enable the rapid analysis of chemicals and DNA or RNA strands, which would have taken racks of equipment before. With the progress of technology, an embedded system has become small enough that it can be sent through the human body to monitor its health.

Beyond Earth, space probes and rovers on Mars, the Moon, and asteroids are performing a myriad of duties every day, again with the courtesy of well-tested embedded systems. The Moon missions themselves were made possible due to the first major example of an embedded system in the form of the Apollo Guidance Computer. This 1966-era embedded system consisted of wire-wrapped boards full of triple-input NOR logic gates, built for the explicit purpose of handling navigation, guidance, and control of the Command Module and Lunar Module launched by the Saturn V rockets.

The ubiquitous and versatile nature of embedded systems has made them an inseparable part of modern life.

For embedded systems, they are usually distinguished between the following categories:

  • Microcontrollers (MCUs)
  • System-on-Chip (SoC), often as a Single-Board Computer (SBC)


One of the driving factors of innovation in the field ofembedded systems is cost, since they will often be high-volume, cheap consumer products. To that end, it helps to have the entire microprocessor, memory, storage, and input/output peripherals on a single chip, simplifying implementation effort, reducing PCB real estate, all with the added benefit of faster and simpler design and production with higher yield. This led to the development of microcontrollers (MCUs) during the 1970s: single-chip computer systems that could be added to a new design for a minimal cost.

With the introduction of Electrically Erasable Programmable Read-Only Memory (EEPROM) to MCUs in the early 1990s, it first became possible to rewrite the program memory of MCUs repeatedly without having to resort to erasing memory content using ultraviolet light through a special quartz window in the MCU's packaging. This allowed for much easier prototyping and further reduced cost and - as far as development and lower-volume production is concerned - in-circuit programming.

As a result of this, many systems that were previously controlled by intricate mechanical and analog mechanisms (like elevators and temperature controllers) now contain one or more MCUs, which handle the same functionality while reducing costs and increasing reliability. By having the features handled in software, developers were also free to add advanced features such as complex preset programs (for washing machines, microwaves, and so on) and simple to complex displays to provide feedback to the user.


TMS 1000

The first commercially available MCU was Texas Instrument's TMS 1000, a general-purpose 4-bit, single-chip system. It was first made available for sale in 1974. The original model had 1 KB of ROM, 64 x 4 bits of RAM, and 23 I/O pins. They could be clocked at speeds from 100 to 400 KHz, with each instruction executing in six clock cycles.

Later models would increase the ROM and RAM sizes, though the basic design remained largely unchanged until production ceased in 1981:

The size of the MCU die was roughly 5 x 5 millimeters, small enough to fit in a DIP package. This type of MCU used mask-programmable ROM, meaning that you could not get a blank TMS 1000 chip and program it. Instead, you would have to send the debugged program to Texas Instruments to have it physically produced using a photolithography mask, resulting in a metallic bridge for each bit.

Being a fairly primitive design (relative to later MCUs), it lacked a stack and interrupts, had a set of 43 instructions and two general-purpose registers, making it quite similar to the Intel 4004 CPU. Some models had special peripherals for driving vacuum fluorescent displays (VFD) and for continuously reading inputs to handle user input via a keyboard without interrupting the main program. Its basic pinout looked as follows:

Obviously the pin functions predate the general purpose input/output (GPIO) pins we know today - the K pins can only be used for input, while output pins are denoted as O and control pins are marked with R. The OSC pins are to be connected to an external oscillator circuit. Much like with discrete logic ICs, the Init pin is used to initialize the chip on power-up and has to be kept high for at least six cycles, whereas recent MCUs have integrated Power-On Reset (POR) and a reset pin that needs at most a discrete resistor and capacitor.

According to the original Texas Instruments press release from 1974, these microcontroller could be had for as little as $3 or less if you bought them in large quantity. They would be used in popular toys such as the Speak and Spell, but also just about everywhere else, including household appliances, automobiles, and scientific equipment. By the time production ceased in the early 1980s, many millions had been sold.

It's also interesting to note that while one-time programmable low cost microcontrollers have gone down in price a lot, the class of products has persevered - as an example, the Padauk PMS150C can now be had for $0.03 and whilst offering an 8 bit architecture, its 1K words of ROM and 64 bytes of RAM sound oddly familiar.

Intel MCS-48

Intel's response to Texas Instrument's successful TMS 1000 MCU was the MCS-48 series, with the 8048, 8035, and 8748 being the first models released in 1976. The 8048 has 1 KB of ROM and 64 bytes of RAM. It is an 8-bit design with a Harvard architecture (split code/data memory), introducing a native word size of 8 bits and interrupt support (two single-level) and is compatible with 8080/8085 peripherals, making it a highly versatile MCU. The advantage of wider ALU and register word sizes is still perceivable today, where for example a 32 bit addition is sequentially executed on an 8 bit MCU as a series of 8 bit additions with carry.

The MCS-48 features over 96 instructions, most of them a single byte in length, and allows for external memory to be added in addition to the internal memory. In a community effort, available information on the MCS-48 family has been compiled and released at .

Here we consider the simplicity of the MCS-48 functional block diagram and compare it to that of its successors as follows:

Even for a design that was introduced just a few years after the TMS 1000, the rapid evolution of MCU designs is evident. Since MCU design evolved alongside popular CPU designs of the time, including the 6502, its 16-bit version, and what would eventually become the M68K processor family, there are many similarities to be found.

Due to its flexible design, it remained popular and in production until the 1990s, until the MCS-51 (8051) series gradually replaced it. See the next section for more details on the 8051.

The MCS-48 was used in the keyboard of the original IBM PC as its controller. It was also used with the 80286 and 80386 to perform A20 line gating and reset functions in the case of the former. Later PCs would integrate these features into Super I/O devices.

Other notable uses of the MCS-48 include the Magnavox Odyssey video game console and a range of Korg and Roland analog synthesizers. While masked ROM (up to 2 KB) was an option with the MCS-48 family, the 87P50 used an external ROM module for its programming, and the 8748 and 8749 featured up to 2 KB EPROM, which allowed for the MCU's internal programming to be altered repeatedly.

Like with standalone EPROM modules, this requires the package to contain a fused quartz window, which allows for ultraviolet light to reach the MCU die, as can clearly be seen in the following photograph of an 8749 MCU with EPROM (by Konstantin Lanzet, CC BY-SA 3.0):

The charge stored in the EPROM cells that defines bits as written dissipates within a 20-30 minute exposure to strong ultraviolet light. The same can be achieved in direct sunlight over the course of a few weeks. The erase cycle usually implies removing the package and putting it in the light tight erasing device. After this, the EPROM can be programmed anew. The specified data retention of an EPROM is about 10-20 years at 85°C, and because the degradation accelerates exponentially with temperature, statements of 100 years or more at room temperature are not uncommon (27C512A: 200 years).

Due to the expense of creating the quartz window and integrating it into the package, one-time programmable EPROMs were used for a while, which allow for the easy programming of an EPROM, but mounted the programmed die in an opaque package so that it could not be reprogrammed any more. Ultimately, EEPROMs became available in the early 1980s, which replaced EPROMs almost completely. EEPROMs can be rewritten about a million times before they begin to develop issues when retaining stored data. Their data retention performance is similar to that of EPROMs.

Intel MCS-51

Recent chips from Cypress CY7C68013A (USB peripheral controller) to Ti CC2541 (a Bluetooth SoC) feature commodity 8051 cores, demonstrating that the Intel MCS-51 family design remains popular to this day. There's a plethora of derived MCUs by other manufacturers as well, even though Intel stopped producing this series of MCUs in March of 2007. First introduced in the 1980s, it's an 8-bit MCU like the 8048, but expands heavily on its feature set.

The functional block diagram as depicted in the Intel 80xxAH datasheet is shown as follows:

It's very similar to the Atmel (now microchip) AT89S51  which is still in production today.

Datasheets commonly address size and performance metrics in a Features list, as quoted below for the AT89S51:

  • 4K Bytes of in-system programmable (ISP) flash memory - Endurance: 10,000 write/erase cycles (was 1,000,000 for EEPROM)
  • 4.0 V to 5.5 V operating range
  • Fully static operation: 0 Hz to 33 MHz (was 12 MHz)
  • Three-level program memory lock
  • 128 x 8-bit internal RAM
  • 32 programmable I/O lines

but then the list goes on with modern core, peripheral, low power and usability features:

  • Two 16-bit timer/counters
  • Six interrupt sources
  • Full duplex UART serial channel
  • Low-power Idle and power-down modes
  • Interrupt recovery from power-down mode
  • Watchdog timer
  • Dual data pointer
  • Power-off flag
  • Fast programming time
  • Flexible ISP programming, byte- and page-mode

The only major changes to the 8051 architecture over the past decades involved migrating from the original n-type metal oxide semiconductor (NMOS) transistor technology to complementary MOS (CMOS) – usually denoted as 80C51 – and more recently the addition of USB, I2C, and SPI interfaces, as well as advanced power management and debugging interfaces that have become ubiquitous since the beginning of this century. The Atmel application note 3487A doesn't give a concise explanation for the letter S, however the then new in-circuit serial programming (ISP) might thereby be highlighted.

The pinout diagram of the AT89S51 documents the SPI pins (MOSI, MISO, SCK):

Beyond standalone MCUs, 8051 cores are also integrated into larger systems where a low-power, basic MCU is dedicated to diverse, low speed, real-time or high I/O count tasks. A broad range of chips from the likes of Ti CC2541 (Bluetooth low energy SoC) to Cypress CY7C68013A (FX2LP™ USB peripheral controller) underline the utility and relevance of the 8051 architecture to this day. 

In field-programmable gate array (FPGA) or application specific integration circuit (ASIC) development, 8051-type processors are also commonly deployed as soft cores, where they are adapted and added to VHDL and Verilog HDL projects to handle tasks that lend themselves better to sequential execution without the need for tight timing or large bandwidth. Last but not least, the charm of soft cores lies in the ability to use full-featured development and debugging tools while maintaining tight integration with the remaining hardware design. The equivalent of only a few hundred bytes of program code run by a soft core might well be a large state machine, memories, counters and ALU-like logic, all of which raises the question which implementation is easier to validate and maintain. 


The PIC family of MCUs was first introduced in 1976 by General Instrument, using their new CP1600 16-bit CPU. This CPU was nearly compatible with the PDP-11 series of processors with its instruction set.

In 1987, General Instrument spun off its microelectronics division to create Microchip Technology, which became an independent company in 1989. Microchip technology produces new PIC designs to this day.  Alongside the evolution of PIC cores and peripherals, on-chip memory technology development yielded the introduction of light tight encapsulated EPROM for on-time programmable and later EEPROM for in-circuit reprogramming capabilities. Like most MCUs, PIC MCUs have a Harvard architecture. Today, PIC designs range from 8-bit to 32-bit, with a wide range of features. These are the PIC families as the time of writing this book:







384-896 bytes ROM, 64-512 bytes RAM

8-bit, 8-16 MHz, modified Harvard



2-16 KB ROM, 256 bytes RAM

8-bit, 16 MHz, modified Harvard



3.5-56 KB ROM,  1-4 KB RAM

8-bit modified Harvard



4-16 KB ROM, 232-454 bytes RAM

8-bit, 33 MHz, superseded by the PIC18, though third-party clones exist.



16-128 KB ROM, 3,728-4,096 bytes RAM

8-bit modified Harvard

PIC24 (dsPIC)


64-1,024KB ROM, 8-16 KB RAM

16-bit, DsPIC (dsPIC33) MCUs have digital signal processing (DSP) peripherals built in.



32-512 KB ROM, 8-32 KB RAM

32-bit, 200 MHz MIPS M4K with MIPS16e mode, released in 2007.





512-2,048 KB ROM, 256-640 KB static RAM (32 MB DDR2 DRAM)

32-bit, MIPS ISA (2013), PIC32MZ DA version (2017) having a graphics core. Core speeds of 200 MHz (EC, DA) and 252 MHz (EF).



16-256 KB RAM, 4-32 KB RAM

32-bit microMIPS, 25 MHz, variant optimized for low cost and low power.



512-1,024 KB ROM, 128-256 KB RAM

32-bit, 120 MHz, MIPS ISA, variant introduced in 2017. Targeted at industrial control and other forms of deeply integrated applications.


The PIC32 families are interesting in that they're based on an MIPS processor core, and use this Instruction Set Architecture (ISA) instead of the PIC ISA that's used by all other PIC MCUs. The processor core design they share is the M4K, a 32-bit MIPS32 core from MIPS Technology. Between these families, the differences are easy to spot when looking at the block diagrams from their respective datasheets.

The decades of development in the PIC line of microcontrollers are perhaps best made tangible in the form of functional block diagrams, so we start by looking at the PIC10:

These are very small MCUs, with barely any peripherals around a processor core not more closely defined here—and the referenced table only mentions the memory layout. The I/O port is very minimal and the I2C and UART interfaces we know today are not implemented as peripheral logic. To pick an example for a controller next in line, the PIC16F84 datasheet is very detailed in terms of processor architecture and shows that more power-up and reset circuitry has been added while also expanding GPIO and adding EEPROM for easy integrated non-volatile storage.  Self-contained serial peripherals are still absent.

Next, we'll have a look at the PIC18:

The PIC18 family is the latest 8-bit PIC architecture, with MCUs covering a wide range of applications. It has significantly more I/O options than the PIC10, PIC12, and PIC16 families, while also offering more options in terms of ROM and RAM and now providing USART in conjunction with a synchronous serial port for 4-wire SPI. Also note that the ports now have alternate pin functions and the routing from peripherals to the pins and the corresponding configuration registers are not shown for simplicity.

Next, let's observe the focus shifting from the core to Port and Peripheral capabilities in the  PIC24 functional block diagram:

The diagram is similar to that of the PIC10, with the CPU abstracted away as a single block relative to the rest of the MCU. Each of the PORT blocks being a set of I/O pins, we're running out of space to display all the possible pin functions.

Each I/O pin can have a fixed function (linked with a peripheral module), or have an assignable function (hardware-level rerouting, or done in software). Generally, the more complex the MCU, the more likely it is that I/O pins are generic and not fixed-function.

Finally we have look at the PIC32:



This block diagram is for PIC32MX1XX/2XX devices in the PIC32MX family. It is usually clocked at 50 MHz.

An interesting property of the PIC32 architecture is that it effectively turns the Harvard architecture M4K MIPS CPU into a more John von Neumann-like architecture by having both program instructions and data travel over the System Bus Matrix.  Note that the space dedicated to a single processor register in the PIC10 diagram now casually depicts a complex digital or mixed signal peripheral, or the powerful JTAG in-circuit programming and debugging interface.


The AVR architecture was developed by two students at the Norwegian Institute of Technology, with the original AVR MCU developed at Nordic VLSI (now Nordic Semiconductor). It was originally known as μRISC and available for licensing until the technology was sold to Atmel. The first Atmel AVR MCU was released in 1997.

Today, we can look back on a multitude of 8-bit AVR families:







0.5-16KB ROM 0-2 KB RAM

1.6-20 MHz. Compact, power-efficient MCUs, with limited peripherals.



4-256 KB ROM 0.5-32 KB RAM




16-384 KB ROM, 1-32 KB RAM

32 MHz, largest AVR MCUs, with extensive peripherals and performance-enhancing features such as DMA.

There also used to be an 32-bit AVR32 architecture, but it was deprecated by Atmel as it moved to the ARM 32-bit architecture instead (SAM). See the ARM-based MCU section for more details on SAM. More detailed information is found in the corresponding Product Selection Guide.

Additionally, Atmel used to have so-called Field Programmable System Level Integrated Circuit (FPSLIC) MCUs: hybrid AVR/FPGA systems. These essentially allowed you to add your own peripherals and functionality to the hardware of an AVR MCU.


Let's look at the ATtiny family. This is the block diagram of the ATtiny212/412 series of MCUs:


This series of ATtiny MCUs can run up to 20 MHz, with up to 4 KB of Flash ROM and 256 bytes of SRAM, as well as up to 128 bytes of EEPROM, all in an 8-pin package. Despite its small size, it has a large number of peripherals, which can be routed to any supported pin:

Contrast this with the popular ATmega2560 and related MCUs, which have the following properties:


Flash (KB)



General purpose I/O pins

16-bit PWM channels


ADC channels











































With GPIO pins numbering in the dozens, the block diagram is correspondingly more complex, with many more port blocks for the I/O pins:

Here, all the incoming and outgoing arrows indicate a single pin or block of pins, most of them general-purpose. Because of the large number of pins, it is no longer practical to use an inline package format (DIP, SOIC, and so on) for the physical chip.

For the ATmega640, 1280 and 2560, a 100-pin TQFP package is used, here with the functionality of each pin indicated as found in its datasheet:


The ATxmega family is very similar to the ATmega, with a similar pinout, mostly differentiating themselves using architectural changes and optimizations, more ROM and RAM, and peripheral options.

Whether to pick an ATtiny, ATmega, or ATxmega MCU depends first and foremost on the requirements you have for your project, specifically the required input and output, types of peripherals (serial, SPI, I2C, CAN, and so on), and the size of both the code and the RAM required to run this code.

M68k and Z80-based

The Zilog Z80 8-bit processor is an Intel 8080-compatible processor, which competed with other microprocessors during the 1980s, powering home computers and gaming systems including the Nintendo Game Boy, Sega Master System, Sinclair ZX80/ZX81/Spectrum, MSX, and Tandy TRS-80.

Zilog introduced an MCU (Z380) based around the Z80 microprocessor in 1994, with various updates over the years, including the Z8, eZ80, and others. Z80 clones are also quite common.

Another popular 1980s era microprocessor is the Motorola 68k (or 68000). It's 16-bit for its ALU and external data bus, but with 32-bit registers and 32-bit internal data bus. After its introduction in 1979, its architecture is still in use today, with Freescale Semiconductor (now NXP) producing a number of 68k microprocessors.

Motorola introduced numerous MCUs based around the 68k architecture, including the MC68320 communications controller in 1989. Current 68k-based MCU designs include the ColdFire, which is a fully 32-bit design.

ARM Cortex-M

A very common type of 32-bit MCU is the ARM Cortex-M family. It includes the M0, M0+, M1, M3, M4, M7, M23, and M33, with a number of them having a floating point unit (FPU) option for increased floating point performance.

Not only are they used as standalone MCUs, they are also commonly integrated into System-on-Chip (SoC) devices to provide specific functionality, such as touchscreen, sensor, or power management functionality. As Arm Holdings doesn't manufacture any MCUs themselves, many third-party manufacturers have licensed the designs, sometimes making their own modifications and improvements.



Here is a brief overview of these MCUs:




Instruction set




Thumb-1, some of Thumb-2.




Thumb-1, some of Thumb-2.




Thumb-1, some of Thumb-2.




Thumb-1, Thumb-2.




Thumb1, Thumb-2, optional FPU.




Thumb-1, Thumb-2, optional FPU.




Thumb-1, some of Thumb-2.




Thumb 1, Thumb-2, optional FPU.

The Thumb instruction sets are compact, 16-bit-length instructions, making them ideal for embedded, resource-restricted systems. Other ARM microprocessor families can also support this Thumb instruction set in addition to the 32-bit instruction set.

H8 (SuperH)

H8 family MCUs were commonly used with 8-, 16-, and 32-bit variations. Originally created in the early 1990s by Hitachi, new designs were still being created by Renesas Technology until a few years ago, though the latter recommends new designs use the RX (32-bit) or RL78 (16-bit) families. A notable use of an H8 MCU is in the Lego Mindstorms RCX controller, which uses an H8/300 MCU.


The ESP family are 32-bit MCUs that are produced by Espressif Systems, with integrated Wi-Fi (both) and Bluetooth (ESP32) functionality.

The ESP8266 first appeared in 2014, when it was sold by a third-party manufacturer, Ai-Thinker, in the form of a module (ESP-01) that could be used by another MCU or microprocessor-based systems to provide Wi-Fi functionality. The ESP-01 module contained firmware for this purpose, which allowed the module to be addressed using Hayes-style modem commands.


Its system specifications are as follows:

  • Tensilica Xtensa Diamond Standard L106 microprocessor (32-bit)
  • 80-160 MHz CPU speed
  • Less than 50 KB of RAM available for user applications (with Wi-Fi stack loaded)
  • External SPI ROM (512 KB to 16 MB)
  • Wi-Fi support for 802.11 b/g/n

As the 32-bit MCU on the ESP-01 module was found to be capable of far more than the simple modem task assigned to it, it soon came to be used for more general-purpose tasks, with a range of upgraded ESP8266 modules (with integrated EEPROM chip), as well as breakout boards. Of the latter, the NodeMCU-style board has become very popular, though a number of other third-party manufacturers have made their own breakout boards, which provide different form factors and functionality.

The basic block diagram for the ESP8266EX looks as follows:


After the immense success of the ESP8266, Espressif Systems developed the ESP32, which used an upgraded, dual-core CPU, among other changes. Its block diagram looks like this:


Its specifications are as follows:

  • Xtensa 32-bit LX6 (dual-core) microprocessor
  • 160-240 MHz CPU speed
  • 520 KB of SRAM
  • Wi-Fi support for 802.11 b/g/n
  • Bluetooth v4.2 and BLE (low energy)

Both the ESP8266 and ESP32 are generally sold as complete modules, with the MCU, external ROM module, and a Wi-Fi antenna either integrated into the board or with an external antenna option:

The metal shielding can covering the board helps to protect the board from electromagnetic interference,  benefiting its Wi-Fi (and Bluetooth, in the case of the ESP32) transceiver, but the whole design with a fixed antenna and geometry is required for FCC certification and later use as an approved module. Connecting an external antenna with higher gain may violate local regulations. The FCC ID it comes with is instrumental in getting a product containing such a module approved for commercialization.


In addition to the previously listed MCUs, there is a wide range of MCUs available from a number of manufacturers with different architectures. Some, like the Propeller MCU from Parallax with its multi-core architecture, are fairly unique, whereas most simply implement the usual single-core CPU architecture with a number of peripherals, RAM, and internal or external ROM.

Beyond physical chips, Altera (now Intel), Lattice Semiconductor, and Xilinx provide so-called soft cores, which are MCUs that are meant to be run on a FPGA chip, either as standalone components or as part of a larger design on that FPGA. These can also be targeted by C/C++ compilers.


The main development challenges with MCUs lie in the relatively limited resources that are available. Especially with the small, low-pin-count MCUs, you have to have a good idea of how many resources (CPU cycles, RAM, and ROM) a particular piece of code takes up, and whether it's realistic to add a specific feature.

This also means that picking the right MCU for a particular project takes both technical knowledge and experience. The former is required to pick an MCU that will suit the task; the latter is very helpful for the optimal MCU and helps to shorten the time that's required to make a choice.

System-on-Chip/Single Board Computer

Systems-on-Chips (SoCs) are similar to MCUs, but distinguish themselves from those types of embedded systems by having some level of integration while still requiring a number of external components to function. They are commonly found as part of a single board implementation (Single Board Computer (SBC)), including the PC/104 standard, and more recently form factors such as the Raspberry Pi and derivative boards:

This diagram was used from It clearly shows how an SBC (in this case, the Raspberry Pi 3) is laid out. The BCM2837 is the ARM-based SoC, providing the CPU core and basic peripherals (mostly broken out into the header section). All of the RAM is in an external module, as are the Ethernet and Wi-Fi peripherals. ROM is provided in the form of an SD (Flash) card, which also provides storage.

Most SoCs are ARM-based (Cortex-A family), though MIPS is quite common as well. SBCs are commonly used in industrial settings.

Other instances are mass produced boards, such as those for smartphones, which do not form a predefined form factor, but still follow the same pattern of having the SoC and external RAM, ROM, and storage, as well as various peripherals. This is in contrast with the MCUs of the previous section, which would always be able to function by themselves, except for the few requiring an external ROM.


Compared to MCUs, the development challenges of SoCs tend to be far less severe. Some of them are on the level and have an interface where you can even develop directly on the device, even doing compilation cycles on the device without having to do cross-compilation on a PC and copying over the binary. This is also helped by running a full OS instead of developing for the bare hardware.

The obvious disadvantage is that with this increase in features comes an increase in complexity, and the resulting complications, such as having to deal with user accounts, setting permissions, managing device drivers, and so on.


In this chapter, we got an in-depth look at what constitutes an embedded system. We learned how to distinguish between the various types of embedded systems, as well as how to determine the basics of picking the right MCU or SoC for a project.

After this chapter, the reader should feel comfortable reading through datasheets for MCUs and SoCs, explaining the differences between both, and determining what is needed for a given project.

The next chapter will look at why C++ is a highly suitable choice for the programming of embedded systems.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Know how C++ works and compares to other languages used for embedded development
  • Create advanced GUIs for embedded devices to design an attractive and functional UI
  • Integrate proven strategies into your design for optimum hardware performance


C++ is a great choice for embedded development, most notably, because it does not add any bloat, extends maintainability, and offers many advantages over different programming languages. Hands-On Embedded Programming with C++17 will show you how C++ can be used to build robust and concurrent systems that leverage the available hardware resources. Starting with a primer on embedded programming and the latest features of C++17, the book takes you through various facets of good programming. You’ll learn how to use the concurrency, memory management, and functional programming features of C++ to build embedded systems. You will understand how to integrate your systems with external peripherals and efficient ways of working with drivers. This book will also guide you in testing and optimizing code for better performance and implementing useful design patterns. As an additional benefit, you will see how to work with Qt, the popular GUI library used for building embedded systems. By the end of the book, you will have gained the confidence to use C++ for embedded programming.

What you will learn

Choose the correct type of embedded platform to use for a project Develop drivers for OS-based embedded systems Use concurrency and memory management with various microcontroller units (MCUs) Debug and test cross-platform code with Linux Implement an infotainment system using a Linux-based single board computer Extend an existing embedded system with a Qt-based GUI Communicate with the FPGA side of a hybrid FPGA/SoC system

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Jan 31, 2019
Length 458 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781788629300
Vendor :
Category :

Table of Contents

19 Chapters
Title Page Chevron down icon Chevron up icon
Copyright and Credits Chevron down icon Chevron up icon
About Packt Chevron down icon Chevron up icon
Contributors Chevron down icon Chevron up icon
Preface Chevron down icon Chevron up icon
1. What Are Embedded Systems? Chevron down icon Chevron up icon
2. C++ as an Embedded Language Chevron down icon Chevron up icon
3. Developing for Embedded Linux and Similar Systems Chevron down icon Chevron up icon
4. Resource-Restricted Embedded Systems Chevron down icon Chevron up icon
5. Example - Soil Humidity Monitor with Wi-Fi Chevron down icon Chevron up icon
6. Testing OS-Based Applications Chevron down icon Chevron up icon
7. Testing Resource-Restricted Platforms Chevron down icon Chevron up icon
8. Example - Linux-Based Infotainment System Chevron down icon Chevron up icon
9. Example - Building Monitoring and Control Chevron down icon Chevron up icon
10. Developing Embedded Systems with Qt Chevron down icon Chevron up icon
11. Developing for Hybrid SoC/FPGA Systems Chevron down icon Chevron up icon
1. Best Practices Chevron down icon Chevron up icon
2. Other Books You May Enjoy Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon

Customer reviews

Filter icon Filter
Top Reviews
Rating distribution
Full star icon Full star icon Full star icon Full star icon Full star icon 5
(1 Ratings)
5 star 100%
4 star 0%
3 star 0%
2 star 0%
1 star 0%

Filter reviews by

Druilhe Jean-Louis Feb 8, 2024
Full star icon Full star icon Full star icon Full star icon Full star icon 5
livre synthétique permettant de retrouver l'essentiel sur des questionnements comme le polymorphisme appliqué à l'embedded.
Feefo Verified review Feefo image
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.