Taking the 32-bit plunge promises payoffs

Before discussing the migration from 8 to 32 bits, it is important to clarify where the 16-bit microcontroller fits into the picture. Primary research with embedded engineers across many different markets suggests that most engineers who outgrow 8-bit MCUs move directly to 32-bit controllers. It seems that for most engineers, a 16-bit MCU is not a viable upgrade alternative.

This is particularly interesting in comparison with the massive migration from 4 to 8 bits that has taken place over the past decade. Clearly, history isn't repeating itself, since few designs were migrated directly from 4 to 16 bits. One reason for this break from the past is that the ARM7TDMI has established itself as a standard CPU core. Currently, more than 30 semiconductor vendors are shipping ARM7TDMI-based products, and the core has become even more of a de facto standard than the widely licensed 80C51. Such a dominant architecture was never conceived in the 16-bit world, which mostly consists of single-source proprietary cores.

Moreover, process geometry shrinks have almost erased the price difference between 16- and 32-bit MCUs. On-chip memory and peripherals take up so much silicon real estate that the cost of the core nearly disappears in the budget. For most applications, upgrading from a 4-bit MCU to a 16-bit alternative was not even considered, because of big price differences.

Driving factors
So what specific fac tors are fueling the shift from 8- to 32-bit architectures? One is the growing need for a broader addressing range. Many 8-bit architectures today are limited to 64k of addressing range. Some microcontroller families are unable to address external program memory, thus limiting the address range to whatever memory is implemented on the chip. A few 8-bit architectures are able to address up to a few megabytes of off-chip memory, and in some cases, extended address range is achieved by adding to an existing architecture. But often the solutions vary by company and are not code-compatible, and the extended addressing capabilities still lack the efficiency of a 32-bit architecture. An 8-bit microcontroller is still only 8-bit, and the arithmetic involved in calculating addresses wider than 16-bits imposes a heavy load on most 8-bit architectures. Many 32-bit microcontrollers feature a synchronous DRAM, which dramatically lowers the cost of larger data memories. By comparison, 8-bitters can address SRAM only.

The need for more performance is also driving the move to 32-bit controllers. Not only do applications demand more raw CPU power in terms of clock speed, but the proliferation of communications interfaces such as Ethernet and USB in embedded applications increases the need for advanced on-chip peripherals. The availability of 8-bit MCUs with on-chip Ethernet MAC is sparse for a good reason: TCP/IP is too complex a protocol to run properly on most 8-bit architectures.

In cases where the MCU runs TCP/IP or other protocols in addition to handling application control functions, the need for an RTOS quickly becomes reality. Most 8-bit microcontrollers are not architected for real-time task switching, and few good real-time operating systems are available. Also, DMA controllers are common on 32-bit MCUs and are used to offload the CPU when the controller is receiving or transmitting large amounts of data.

It's also worth noting that there is a growing tendency among customers to avoid single-so urce architectures. With the exception of the 80C51, single-source architectures dominate the 8-bit MCU market. That implies a significant tool investment and a substantial amount of work every time code is ported from one architecture to another. With the ARM7TDMI becoming the de facto standard architecture for the lower end of the 32-bit embedded space, embedded engineers have regained the freedom to choose among microcontrollers from different vendors without losing the investment in code base and development tools.

Barriers
Nonetheless, migrating from 8 to 32 bits involves far more than just code recompilation and board relayout. Whereas the 32-bit MCU opens up a new world in terms of possibilities, it also introduces a new set of real and perceived issues to deal with.

The myth of higher component cost is one that should be addressed. There is a perception that "more bits cost more," but this is not always valid, since many 32-bit MCUs are manufactured in a 0.18-micron proces s. Also, one has to consider the application's total bill of materials. In many cases one 32-bit MCU can replace several components because of extra performance and on-chip peripherals. Often, engineers compare only the price of the microcontroller instead of the entire system cost-and that prevents many engineers from even contemplating the move.

The cost analysis of a networked image device, for example, with a 32-bit MCU reveals a $2 higher component cost for the 32-bit solution-a small price to pay considering that JPEG decompression and faster, 100-Mbit/second Ethernet connection speeds can be included. The added market value of the added functionality by far outweighs the increase in component cost. Not only that, but the redesign provides plenty of performance overhead that can be used for future expansions.

Memory usage could be viewed as another barrier. Few 32-bit MCUs feature on-chip code memory, although that is changing. The main issues with off-chip memory are EMI, power consump tion, access time and security.

The cost of development tools is not necessarily a real barrier. An 8-bit development suite includes a compiler and an emulator/debugger, which could cost as much as $4,000. In some cases, one can get by with much less; but few free compilers are available, and almost all 8-bit devices require a dedicated emulator. Often, using several derivatives based on a single architecture requires the use of several emulators.

When investing in 32-bit development tools, one can easily spend far more than $4,000. However, since free GNU debuggers and compilers are available and since most 32-bit MCUs do not require an emulator for real-time debugging, one can get started with a modest investment in development tools. That, of course, requires silicon vendors to make the effort of porting, testing and supporting the free tool chain.

In some cases, fear of complexity could be enough to make engineers hesitate to move to 32-bit. Developers of 8-bit microcontrollers ge nerally have little experience with RTOSes and programming. Fear that the learning curve is too steep or too long will be a barrier to many 8-bit design engineers. But when the performance requirements reach the physical limits of what an 8-bit microcontroller can do, the design tweaking involved in adding more features becomes extremely resource-demanding. At this point it is always better to make the leap.

Embarrassment of riches
Then there's the sheer number of devices to consider. The 8-bit MCU offering comprised approximately 1,300 devices from more than 40 vendors. A similar number of vendors have offered 240 devices in the 32-bit category. Although the difference in device selection is expected to have shrunk somewhat over a two-year period, it is still substantial. That is why configurable devices such as those offered by Altera and Triscend have success in the 32-bit market space.

Engineers struggling with the decision to upgrade to the 32-bit MCU, must take a look at the total system cost, since often the performance of the application can be increased by an order of magnitude for a minimal increase in cost. There's extra work involved in learning a new architecture and a new tool set, but squeezing the last Mips out of an already bogged-down 8-bitter could also easily burn few late hours in the lab.

Geir Kjosavik is director of business development at Triscend Corp.

See related chart