The choice of which microcontroller (MCU) 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:
1. What tasks will the system carry out?
2. What are the inputs and outputs for the system?
3. How much data storage will it require?
4. 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 address the following questions:
1. What is the material and assembly cost target?
2. What is the power requirement of the system?
3. What is the physical size limitation of the system?
4. 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 –
a. LCD peripheral.
b. USART.
c. ADC.
Nice to have –
a) Capacitive touch peripheral.
b) Real-time clock peripheral.
4. External circuitry – what other signal-conditioning or control circuitry is required?
a. Temperature sensor.
b. Watchdog timer.
c. Open collector drivers for heat/cool.
d. 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 is not 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 does not 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 does not 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 to build the 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 into 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 idle 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 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 or calculation (DSP)?
Again examining the question of hardware versus software, the compromise here concerns system controls and whether to use an analog signal chain to condition input signals and generate outputs, or to use software.
The answer to this question has a significant impact on the microcontroller choice. The microcontroller really must have a couple of on-chip features to implement a proportional-integral-derivative (PID) function or a digital filter design.
The first requirement is a hardware multiply function that is capable of keeping up with the system requirements for feedback and control, and the second is a high-speed, high-resolution analog-to-digital converter (ADC).
Simple feedback controls implemented using micros without these features tend to be slow and typically use up all of the available processing power to accomplish the task. The simpler option is to opt for an analog system to accomplish the necessary functions with the microcontroller performing a supervisory role.
Some functions will 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. In these cases, the best option is to use a software solution alongside any necessary analog fault detection circuitry.
Real world or advanced machine?
The final question relates to usage and whether the system has a small automated control with a limited user interface, or a more advanced system with networking and a more complex user interface. Whilst there would be no need to use a QVGA with a touch screen to implement a $9,99 home thermostat control, such a user interface may be needed for a system that is networked into a large office/building environmental control system.
The answer lies in how much bandwidth is required for the user interface and whether any connectivity is required. The aesthetic trends in the marketplace may impact the choice as well as more practical requirements for operation by a user wearing gloves. All of these requirements should be weighed in turn to determine the appropriate complexity for the system.
Once the list of system resource requirements has been adjusted to allow for the acceptable compromises, the designer can start to look for the appropriate microcontroller to meet those requirements. Table 3 shows an example microcontroller selection matrix which reflects the examination of the processing power, memory (Flash and RAM) and peripheral mix required.
An exact match is unlikely; the designer will need to revisit some of the compromises and make some hard choices. Having already highlighted the peripherals which are essential and those which fall into 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 is 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.
Additional considerations
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.
| Email: | [email protected] |
| www: | |
| Articles: | More information and articles about Tempe Technologies |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version