In Chapter 4, Resource-Restricted Embedded Systems, we looked at how to pick an appropriate microcontroller for an embedded platform. While designing the firmware for the MCU, it's essential that we consider not only the resource requirements of specific codes, but also the ease of debugging.

An important advantage of using C++ is the abstractions it offers, including the ability to subdivide the code into logical classes, namespaces, and other abstractions that allow us to easily reuse, test, and debug the code. This is a crucial aspect in any design, and an aspect that needs to be implemented fully before one can proceed with actually implementing the design.

Depending on the design, it can be either very easy or frustratingly hard to debug any issue, or anything in between. If there's a clean separation between all the functionality, without leaky APIs or similar problems that could leak internal, private data, creating different versions of fundamental classes for things such as integration and unit testing will be easy.

Simply using classes and the like is no guarantee for a design that is modular. Even with such a design one can still end up passing internal class data between classes, thus breaking modularity. When this happens, i will complicate the overall design as the level of dependencies increases with changes to data structures and data formats potentially causing issues elsewhere in the application and will require creative hacks while writing tests and reimplementing APIs as part of larger integration tests.

In Chapter 4, Resource-Restricted Embedded Systems, we looked at how to pick the proper MCU. The points of RAM, ROM, and floating-point usage are obviously down to the design we picked to fit the project. As we covered in Chapter 2, C++ as an Embedded Language, it's important to understand what the code we write is compiled into. This understanding allows one to get an intuitive feeling for what the resource cost of a line of code is going to be like without having to step through the generated machine code and create an exact clock cycle count from there.

It should be obvious at this point that before one can pick an MCU, one must have a pretty good idea of the overall design and the resource requirements, so starting off with a solid design is essential.