Right Sizing the Micro

The article explains how to select the right microcontroller for engineering project..

When starting an embedded-control project, the first question that inevitably comes up is, “Which Microcontroller should I use?” Should I go for a low-cost micro and migrate up, or start with a high-end micro and downsize? Do I need an 8-bit, 16-bit or 32-bit MCU?

Unfortunately, the simple answer is, “It depends.” What level of control will the project need? What are the power limitations? Will it have to work in a harsh environment? What kind of processing power will be required? Does it interface with a human being, or other systems? How fast does it have to respond to changes? The list goes on and on, and if the engineer is not careful, a kind of paralysis can set in and hobble the project.

The solution is to collect all the requirements together in one place and weigh the tradeoffs. Personally, I like to use a requirements document; basically, a one- to two-page document that clearly, and as completely as possible, outlines the basic requirements of the project.

Typically, I like to start with the basic functionality of the project:

1. What tasks will the system perform?
2. What are the system inputs and outputs?
3. How much data storage will be required?
4. How quickly must the system perform its tasks and respond to events?

Table 1 shows an example list for a simple thermostat control.

Next, the document should include design constraints:

1. What are the materials and assembly cost targets?
2. What are the power requirements of the system?
3. What are the physical-size limitations of the system?
4. What is the target operating environment for the system?

Table 2 shows an example list for the same simple thermostat control.

When I have these requirements clearly defined, I can start a preliminary list of resource requirements for the system:

1. Data memory; how much data ram is required?
   165 bytes
2. Flash memory; how much program space is required?
   2300 words
3. Peripherals; what on-chip peripherals are needed on the MCU, and what on-chip peripherals would be nice to have?

Must have

1. LCD peripheral
2. USART
3. ADC

Nice to Have

1. Cap-touch peripheral
2. Real-time clock peripheral

4. External circuitry; what other signal-conditioning or control circuitry is required?

1. Temperature sensor
2. Watchdog timer
3. Open collector drivers for heat/cool
4. Voltage regulator

5. Processing speed; how many MIPS are required to do the job?
500 KIPS to 1 MIPS

I don’t worry about the absolute accuracy of my estimates at this point. I am just trying to get a rough order of magnitude, so I have a numerical basis for the trade-off analysis to follow. Figure 1 shows some of the tradeoff decisions that I will need to make in the design.

Notice that the chart shows a range of 8-bit through 32-bit. The idea is that each item listed is a continuum, ranging from one extreme to the other. It doesn’t mean that both extremes are not possible at either end; it just means that they are easier to implement. For example, Real-Time Response is listed at the 8-bit end of the chart, while RTOS is listed at the 32-bit end. This doesn’t mean that there isn’t an RTOS solution available for 8-bit microcontrollers, just that RTOSs are more prevalent at the 16- and 32-bit end, and that their memory footprints are proportionally smaller in 16- and 32-bit microcontrollers.

Hardware Versus Software

Let’s start with the first item on the list; hardware versus software. (For the moment, lets limit the question to digital peripherals; we will discuss analog peripherals below.) The question is fairly far reaching in a design. Basically, will I create some or all of the functions I need in software, or will I use hardware? The tradeoff is processing power versus hardware complexity. For example, should I implement a software-based stepper motor controller, or should I use a controller chip? The answer will affect my processor speed requirements, program memory requirements, system cost, board size, and possibly current consumption.

There may also be hidden limitations. For example, it is certainly reasonable to build a USART function in software, as both transmit and receive functions can be emulated in software. The problem is, the receive function must continuously poll for the falling edge of the start bit, to accurately synchronize its receive timing. This can put a considerable drain on processing power. Even if an interrupt-on-change function is available, the latency time of the interrupt service routine may make accurate timing of the edge problematic. So be careful when trading hardware peripherals for their software-based alternatives, there may be lurking limitations. For now, just note the potential options and know the potential costs.

Real-Time Response Versus RTOS

The next tradeoff concerns a similar decision for the software design of the project; Real-Time Response/RTOS. Here, I have to make a decision about how I am going to multi-task in my design. Will I use a real time operating system (RTOS), or will I build my system out of interleaved statemachines? Both have advantages. The RTOS handles all of the switching between states and simplifies the software design, while a real-time-response system requires a smaller memory footprint and makes real-time-response control easier to implement. Both choices will have some impact on the data/programming memory requirements and, potentially, the processing power required for the system.

Another potential complication may lurk in the type of RTOS to be used. RTOSs fall into two basic categories; preemptive and cooperative. Both allow switching between multiple tasks, but differ in the trigger for the switch. This results in differing requirements for variable storage and peripherals, which should be factored into the system requirements.

Sleep Power Versus Dynamic Power Control

Another hardware decision concerns the system power requirements: Sleep Power/Dynamic Power Control. Here the question is, will I go with a control that has all-or-nothing current consumption, or will I go with a more graduated system that allows me to turn off sections of my design. Both have a place in designs, and my choice will be heavily affected by my decisions earlier in the Hardware/Software section. Basically, the question is, will I be required to leave some of my system awake and drawing current, to handle the system idle tasks; or, do I have an automated hardware system that can handle simple tasks while the processor is asleep and drawing much smaller quiescent current?

Robust Electrical Design

A related question is the need for a robust electrical design. Now, don’t get me wrong, I believe that all designs should be robust electrically, but there can be a tradeoff concerning how that robustness is achieved. This question ties back to both the Power and Hardware/Software questions.

For example, let’s consider a power-conversion function. One option is to use a more software-centric design, which uses a software function to generate the feedback control. The second option uses an op-amp-based loop filter with a simpler analog feedback PWM. Both systems work, and both are currently in use in the industry. The differences are that the software-based system must remain active while the power converter is operating, which may require a higher operating current. And, in the event that the program counter in the microcontroller is corrupted, the hardware-based system is unaffected by the microcontroller recovery function, making it more electrically robust in a noisy environment.

Analog Signal Chain Versus Calculation (DSP)

The fifth item gets back to the question of hardware versus software, but this time it has to do with using an analog signal chain versus calculation (i.e., a DSP). The tradeoff here concerns system controls. Will I use an analog signal chain to condition input signals and generate outputs, or will I use software? This question becomes more of a grey area than the aforementioned hardware versus software question. Here, the question has a much more profound affect on the microcontroller choice. To implement a Proportional-Integral-Derivative (PID) function or a digital-filter design, the microcontroller really must have a couple of on-chip features. The first requirement is a Hardware Multiply function that is capable of keeping up with the system requirements for feedback and control. The second required feature is a high-speed, high-resolution Analog-to-Digital Converter (ADC).

Now, some simple feedback controls can be implemented using micros without these features, but they tend to be slow and they typically use up all of the available processing power to accomplish the task. The simpler option, in these cases, is to go with an analog system to accomplish the necessary functions, and relegate the microcontroller to a supervisory role. However, there are some functions that require greater speed, or are more difficult—even impossible—to implement in analog, such as non-linear feedback controls and Infinite Impulse Response (IIR) filters. Here, the better (or only) option is to use a software solution, plus any necessary analog fault-detection circuitry.

Real World Versus Advanced Machine

The final tradeoff is a question of usage. Is the system a small automated control with only a limited user interface, or a more advanced system with networking and a more complex user interface? Clearly, I am not going to try to use a QVGA with a touch screen to implement a $9.99 home thermostat control. But, I might need this user interface for a system that is networked into a large office-building environmental control system. It is really a question of how much bandwidth is required for the user interface and whether any connectivity is required. There may also be requirements based upon the aesthetic “Look and Feel” trends in the marketplace, or even requirements for operation by a user wearing gloves. All of these requirements should be weighed to determine the appropriate complexity for the system.

OK, so we have made all the tradeoffs and adjusted our list of system resource requirements appropriately, now what? Well, this is where we get out the catalogs and start looking for an appropriate microcontroller. See Table 3 for an example Microcontroller selection matrix. We have a good idea on the processing power required, the memory required (flash and RAM), and the peripheral mix required.

Now, it is unlikely that you will find an exact match. More than likely, you will have to revisit some of your tradeoffs and make some hard choices. This is part of the reason we noted which peripherals were nice to have versus must have. The only real advice I can give you here is try to find a microcontroller that is part of a family with upward and downward-compatible siblings. This will give you options, in the event that you have to either add or subtract memory and/or peripherals to add features or cut cost. There is a silicon and a test cost associated with each function, and the cost of each starts to add up. Some functions have more incremental cost than others. So, when the final product selection options are narrowed down, it’s good to refer back to your must have vs. nice to have lists. Also, consider the cost and complexity of the required design tools. You will be buying these tools, not only for yourself, but also for the support, testing and production staff making the final product.

Additional Considerations

Another important design consideration is the availability of pre-built stacks and library functions. Some manufacturers make pre-built code available for specific functions, such as graphical display drivers, serial-communication functions and capacitive-touch functions. These standard blocks can save a considerable amount of time and testing, but make sure that the blocks are compatible with your design. For example, some blocks may monopolize one or more peripherals, preventing other functions from accessing them. There may also be timing requirements that conflict with other functions in the system, so be sure to ask specific questions before committing to the use of prefab code.

Most importantly, consider code reuse in your final decision. There is no reason to keep reinventing the wheel on every design. Find a manufacturer that produces a broad range of microcontrollers and stick with them. This will allow you to reuse a lot of what you develop in future designs, cutting development and testing time. Additionally, using a wide variety of manufacturers’ tools and parts can put a heavy burden on your test, support and production people.