Going from 8- to 32-bit MCUs takes tools

This is one of several software issues that are defining the shape of today's and tomorrow's MCU choices. Rather than force designers to adapt to available hardware resources, MCUs must be made to accommodate their software requirements. In addition to compatible 8- and 32-bit versions, MCUs can offer a wide variety of off-the-shelf software intellectual property (IP)-minimizing the need for ASIC hardware-and generous amounts of on-board flash memory for code storage.

Several examples illustrate the usefulness of peripheral compatibility across 8- and 32-bit MCUs. Utility power meters provide one good example because they have shifted from the traditional mechanical meter to electronic versions based on 8-bit devices, followed by versions based on 32-bit MCUs. The meters provided more detailed information about power usage, such as the amount of power consumed at peak times. An 8-bit MCU supports a simple infrared output function that allows meter readers to gather data electronically.

Upgrading to a 32-bit MCU lets the meter exchange detailed information with the utility provider via a phone line or the power line itself. The meter can include a card reader that allows customers to buy power using a debit card, a solution well-suited for developing countries whose power companies may not have a strong billing infrastructure. The 32-bit MCU can run software that makes modem hardware unnecessary and that measures power consumption with integrated circuitry, implementing a sophisticated but i nexpensive one-chip system.

Power meters are used worldwide under a variety of conditions, and the companies that make them need a design that can adapt as needed. The basic functions of the 8- and 32-bit meters are the same: measure the power consumed in specific time periods and communicate that information to the utility. With 8- and 32-bit MCUs that have compatible peripherals, the companies can use the same basic code for making measurements and calculating tariffs across the product line.

For this approach to work, the MCUs' functional registers, timers, UARTs and other resources need the same names and configurations. A header file can handle any minor differences in memory map addresses. Upgrading to a 32-bit MCU is necessary to implement networking and security features and makes it practical to execute functions in software that would otherwise require external hardware.

Many motor control applications face similar reasons for upgrading to 32-bit. In the past, motor control algorithms were usually simple and could be handled by 8-bit devices. Now many applications require more sophisticated and high-accuracy motor control algorithms that, due to the need for 32-bit math, can only be implemented by a 32-bit MCU or a dedicated motor control DSP. These algorithms can reduce both power consumption and cost with no additional sensors.

Typical motor control applications that use these 32-bit MCUs include standard household electronics like washers, dryers, refrigerators, freezers, dishwashers and air conditioners, as well as hybrid cars and factory machines.

Another upgrade exists in applications that contain multiple 8-bit MCUs or a combination of an 8-bit MCU and a dedicated hardware engine with a DSP architecture for tasks like voice or image processing, or both. Integrating the functionality of the various processors into a single 32-bit device can reduce costs, save space and simplify system control.

In all of the upgrades, the 32-bit MCU lets engineers l everage software-based functions to reduce or eliminate dependence on external hardware. Off-the-shelf software IP lets engineers take advantage of assembly-code-optimized functions that make maximum use of the MCU. These functions span a broad range and may include image processing, audio processing, communication interfaces and user interfaces. These types of functions have typically been regarded as hardware blocks in a system-on-chip (SoC). By exploiting spare cycles from a 32-bit MCU, engineers can reduce the complexity of an ASIC or eliminate the ASIC altogether.

In other cases the designs can migrate in the other direction, and it becomes necessary to eliminate separate MCU and ASICs and roll all of the hardware into a single SoC. For this reason, it may be useful to design embedded applications around a 32-bit MCU whose functionality can be transferred as IP directly to an SoC. Again, this strategy allows the reuse of existing software.

Future upgrades
The desire for a sing le-chip solution has led to MCUs that include as much as a megabyte of flash memory. Flash capacities will likely continue to expand to accommodate increasingly complex software functions, with the benefit of flexibility to upgrade or change the functions remotely in the field and make masked-ROM versions of MCUs unnecessary.

In many MCUs, the flash occupies more silicon area than the 32-bit processor itself, even though innovations such as split-gate flash are reducing the size of memory cells. The use of RISC CPUs is also helping to reduce the relative size of the processor. Compared with CISC architectures, a RISC CPU executes instructions much faster for a given clock speed and consumes much less power, so RISC-based MCUs are growing in popularity.

Another emerging trend is to use multiple 32-bit cores in one MCU rather than trying to push a single CPU's performance capabilities. This multiple-CPU approach may seem like the mirror image of consolidating multiple 8-bit MCUs into one 32-bit device, but the idea is to pack the 32-bit CPUs into a single device controlled by a sophisticated multiprocessor real-time operating systems. This strategy reduces power consumption by optimizing the software task allocation among multiple processors. Using compatible 32-bit cores also supports the migration of existing application software-the key to cost-effective MCU design.

Steve Ikei is senior engineering manager for NEC Electronics America Inc., Microcontroller SBU.

See related chart