Hands-On Embedded Programming with C++17

3.2 (6 reviews total)
By Maya Posch
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. What Are Embedded Systems?

About this book

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.

Publication date:
January 2019
Publisher
Packt
Pages
458
ISBN
9781788629300

 

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)
 

Microcontrollers


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 https://devsaurus.github.io/mcs-48/mcs-48.pdf .

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. 

PIC

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:

Family

Pins

Memories

Details

PIC10

6-8

384-896 bytes ROM, 64-512 bytes RAM

8-bit, 8-16 MHz, modified Harvard

PIC12

8

2-16 KB ROM, 256 bytes RAM

8-bit, 16 MHz, modified Harvard

PIC16

8-64

3.5-56 KB ROM,  1-4 KB RAM

8-bit modified Harvard

PIC17

40-68

4-16 KB ROM, 232-454 bytes RAM

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

PIC18

28-100

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

8-bit modified Harvard

PIC24 (dsPIC)

14-144

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

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

PIC32MX

64-100

32-512 KB ROM, 8-32 KB RAM

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

PIC32MZ EC

PIC32MZ EF

PIC32MZ DA

64-288

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).

PIC32MM

20-64

16-256 KB RAM, 4-32 KB RAM

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

PIC32MK

64-100

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.

AVR

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:

Family

Pins

Memories

Details

ATtiny

6-32

0.5-16KB ROM 0-2 KB RAM

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

ATmega

32-100

4-256 KB ROM 0.5-32 KB RAM

 

ATxmega

44-100

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:

Device

Flash (KB)

EEPROM (KB)

RAM (KB)

General purpose I/O pins

16-bit PWM channels

UART

ADC channels

ATmega640

64

4

8

86

12

4

16

ATmega1280

128

4

8

86

12

4

16

ATmega1281

128

4

8

54

6

2

8

ATmega2560

256

4

8

86

12

4

16

ATmega2561

256

4

8

54

6

2

8

 

 

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:

Core

Announced

Architecture

Instruction set

M0

2009

Armv6-M

Thumb-1, some of Thumb-2.

M0+

2012

Armv6-M

Thumb-1, some of Thumb-2.

M1

2007

Armv6-M

Thumb-1, some of Thumb-2.

M3

2004

Armv7-M

Thumb-1, Thumb-2.

M4

2010

Armv7-M

Thumb1, Thumb-2, optional FPU.

M7

2014

Armv7E-M

Thumb-1, Thumb-2, optional FPU.

M23

2016

Armv8-M

Thumb-1, some of Thumb-2.

M33

2016

Armv8-M

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.

ESP8266/ESP32

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.

Others

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.

Challenges

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 https://xdevs.com/article/rpi3_oc/. 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.

Challenges

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.

 

Summary


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.

About the Author

  • Maya Posch

    Maya Posch is a senior C++ developer with more than 15 years of experience. Discovering the joys of programming early on, and later the joys of electronics, she has always expressed a profound interest in technology, a passion that she gladly shares with others. Describing herself as a C developer who happens to like C++ and Ada, she likes to seek the limits of what can be done with the minimum of code and hardware to accomplish everything that is cool, new, and exciting. She also enjoys FPGA development, AI, and robotics research, in addition to creative writing, music, and drawing.

    Browse publications by this author

Latest Reviews

(6 reviews total)
quite bit of details and lots of information presented nicely..embedded was not my field but I wanted learn some basics..and this one does it
I am 20 years embedded programming for a living with C, ready to expand to C++, while this book celebrates embedded programming with C++, it does not give concrete examples of migrating from C to C++ nor any significant advice or strategy for using C++ for embedded. The examples are so pallid. Sorry.
Good service. Book was in good condition.

Recommended For You

Book Title
Unlock this book and the full library for only $5/m
Access now