Finding the right size Microcontroller
• Electronics • Technical Articles • South-East European INDUSTRIAL Мarket - issue 1/2014
Keith Curtis
Microchip Technology Inc.
The choice of which Microcontroller to use is made at the start of an embedded-control project. The options are to select an 8-bit, 16-bit or 32-bit MCU and either start from a low-cost micro and migrate up, or downsize from a high end micro.
There are no hard and fast rules: a number of factors will influence the decision including the level of control and processing power the project will require, the power limitations... the list is almost endless. Requirements such as the need to work in a harsh environment, or to interface with a human being to other systems can be as vital as considering how fast the product has to respond to changes. The end result can be selection paralysis as an engineer weighs conflicting requirements and demands.
The solution can be found in a requirements document which allows an engineer the opportunity to weigh the alternatives. The first section should tackle basic functionality:
• What tasks will the system carry out?
• What are the inputs and outputs for the system?
• How much data storage will it require?
• How quickly must the system perform its tasks and respond to events?
Table 1 shows an example list for a simple thermostat control.
Design constraints should feature in part two:
• What is the material and assembly cost target?
• What is the power requirement of the system?
• What is the physical-size limitation of the system?
• What will be the operating environment for the system?
Table 2 shows a sample list for the same simple thermostat control.
Once these requirements are clearly defined, a preliminary list of resource requirements for the system can be drawn up, as shown in the following example:
1. Data memory - how much data ram is required?
• 165 bytes
2. Flash memory - how much program space is required?
• 2300 words
3. Peripherals - list what on-chip peripherals are a ’must have’, and what on-chip peripherals are ’nice to have’?
• Must Have: LCD peripheral, USART, ADC
• Nice to Have: Cap-touch peripheral, Real-time clock peripheral
4. External circuitry - what other signal-conditioning or control circuitry is required?
• Temperature sensor
• Watchdog timer
• Open collector drivers for heat/cool
• Voltage regulator
5. Processing speed - how many MIPS are required to do the job?
• 500 KIPS to 1 MIPS
At this point in the process, accuracy isn’t essential; the aim is to get a rough order of magnitude in order to establish a numerical basis for the trade-off analysis to follow. Figure 1 shows some of the alternatives that need to be weighed as part of the design.
The chart shows a range of 8-bit through 32-bit; each item listed is on a continuum, ranging from one extreme to the other. This doesn’t mean that full functionality of all elements at the extreme of the chart are impossible, 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 an RTOS solution for 8-bit microcontrollers is impossible, 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 MCUs.
Hardware or Software?
The question, in relation to digital peripherals, is to consider whether to create the functionality in software or hardware. This has far reaching implications for the design. Processing power must be traded off against hardware complexity. It is the difference, for example, between implementing a software-based stepper motor controller and a controller chip. The selection will affect processor speed and program memory requirements, system cost, board size and possibly current consumption.
Some limitations may be hidden. For example, a USART function can be built in software, as both transmit and receive functions can be emulated in this way. The problem is, the receive function must continuously poll for the falling edge of the start bit, to accurately synchronise 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. At this stage, the best approach is to be aware of lurking limitation but initially just note the potential options and know the potential costs.
Real-Time Response or RTOS?
Decisions must be made on how to multi-task in the design and whether to use a real time operating system (RTOS), or will I build my system out of interleaved state machines? 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 options will impact the data/programming memory requirements and the processing power required for the system.
RTOSs fall in to two basic categories; pre-emptive and cooperative. Both allow switching between multiple tasks, but differ in the trigger for the switch, which in turn has an impact on the requirements for variable storage and peripherals and should be factored into the system requirements.
Sleep Power or Dynamic Power Control?
The options are a control that has all-or-nothing current consumption, or a more graduated system that allows sections of the design to be turned off. Both have their merits; the decision will be heavily affected by decisions made earlier in the Hardware/Software section. The question centres on whether some of the system should be left awake and drawing current to handle the system idea tasks; or whether to employ an automated hardware system that can handle simple tasks while the processor is asleep and drawing much smaller quiescent current.
Robust Electrical Design
Although in an ideal world, all designs should be robust electrically, there can be a compromise concerning how that robustness is achieved. This question relates to both the Power and Hardware/Software questions.
For example, a power-conversion function could be delivered using a more software-centric design, which uses a software function to generate the feedback control. The alternative is to employ 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 to revisit some of the compromises and make some hard choices.
Having already highlighted the peripherals which are essential and those which fall in to the category of a "nice to have" proves valuable when making the final decision. It is recommended to employ a microcontroller that is part of a family with upward and downward-compatible siblings and which provides options in the event that memory and/or peripherals need to be added or subtracted 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, the cost and complexity of the required design tools should be considered as this will impact the support, testing and production staff making the final product.
The availability of pre-built stacks and library functions is another important design consideration. 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 those blocks may not be compatible with the design. For example, some blocks may monopolise 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 it is important to ask specific questions before committing to the use of prefab code.
Finally, consider code reuse in your final decision because there is no reason to keep reinventing the wheel on each new design. Finding a manufacturer that produces a broad range of microcontrollers and sticking with them will allow the reuse of a lot of what is developed in future designs which can cut development and testing time.
LATEST issue 1/2023
