We're going to be limiting our search to STM32 parts since that's the example family we're using throughout this book. In Chapter 15, FreeRTOS Memory Management we'll be covering how to prevent tasks from accessing memory they shouldn't, which will require us to make use of a part with a memory protection unit. One of the goals of this book is to keep hardware interaction as accessible as possible, which leads to the next two requirements: status display and cost. 

Some means of displaying status will likely translate into a simple LED (ideally multiple). There should be some form of feedback for the programmer to be able to see what's going on at a glance in order to ensure the code is actually doing something. In a real embedded environment, this would likely take the form of additional instrumentation, such as oscilloscopes, logic analyzers, and DMMs. In the spirit of keeping this accessible for as many people as possible, we'll be explicitly avoiding those tools. So, rather than relying on external tools and the debugger alone, we're going to be on the lookout for on-board indicators.

The nice-to-haves aren't hard requirements, but they are desirable qualities the system would possess in a perfect world. Ideally, the target dev board would also be part of a larger hardware ecosystem, which would enable people to use existing hardware they might already have to further explore the concepts in this book. A USB port attached to the target MCU would also be great to have—that way, we would be able to use a virtual comm port to output debug instead of using only the debugger. Finally, in Chapter 16, Multi-Processor and Multi-Core Systems, we will look at a brief introduction and a few tips on developing our board with multiple CPUs. Although this topic is deserving of its own book (many have already been written from an architectural perspective), it would be nice to have some code that we could put into action on actual hardware.