Book Image

Hands-On Embedded Programming with C++17

By : Maya Posch
5 (1)
Book Image

Hands-On Embedded Programming with C++17

5 (1)
By: Maya Posch

Overview of 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.
Table of Contents (19 chapters)
Title Page
Copyright and Credits
About Packt
Contributors
Preface
Index

Avoiding real hardware


One of the biggest advantages of OS-based development on platforms such as embedded Linux is that it's so similar to a regular desktop Linux installation. Especially when running an OS such as a Debian-based Linux distribution (Armbian, Raspbian, and others) on SoCs, we have practically the same tools available, with the entire package manager, compiler collections, and libraries available with a few keystrokes.

This is, however, also its biggest pitfall.

We can write code, copy it over to the SBC, compile it there, run the test, and make changes to the code before repeating the process. Or, we can even write the code on the SBC itself, essentially using it as our sole development platform.

 

 

The main reasons why we should never do this are as follows:

  • A modern PC is much faster.
  • Testing on real hardware should never be done until the final stages of development.
  • Automated integration testing is made much harder.

Here, the first point seems fairly obvious. What takes a single...