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

Documentation saves lives


It's become somewhat of a running joke that programmers don't like to write documentation and thus refer to the code that they've written as self-documenting code. The reality is that without clear documentation of the design requirements, architecture overview, design plans, and with the API documentation, you risk the future of the project and both one's fellow developers and the end-users who rely on the software to function.

Following procedures and doing all the boring paperwork before you can start writing the first line of code may seem like a complete killjoy. Unfortunately, the reality is that, without this effort, this knowledge will remain locked in the heads of the project's developers, which complicates the integration of the firmware into the rest of an embedded project and makes future maintenance, especially if moved to a different team, a daunting prospect.

The simple fact is that no code is self-documenting, and even if it were, no hardware engineer is going to go through thousands of lines of code to figure out what kind of signal is being put out on a specific GPIO pin when a particular input condition for the MCU occurs.