Lift off for 32bit
Thanks to the use of more aggressive process technologies, large-memory 32bit microcontrollers are making inroads in embedded systems.
In the world of microcontrollers, old boundaries are breaking down. The 8, 16 and 32bit microcontroller markets had distinct characteristics that saw the vendors push very different architectures and products in each of them. But demands for more on-chip memory and better performance are seeing an increasing number of customers migrate from older 8 and 16bit microcontroller architectures to the 32bit world. A consequence of the trend is increased compatibility between different product lines. A couple of years ago, Freescale Semiconductor decided to make it easier to move between its 8bit and 32bit lines with the introduction of the Flexis microcontrollers. These are parts that have identical pinouts and on-chip peripherals but different processors cores: some have the 8bit SO8 core, derived from the 6805 architecture, and the 32bit products are based around the ColdFire version 1 - the first follow-on to the company's 68000 architecture. "Flexis provides a bridge between the Coldfire and 8bit worlds: an opportunity for an upward migration from 8bit," says Bruno Baylac, vice president of marketing for the industrial segment at Freescale.
Freescale is not alone in using peripheral compatibility to ease the process of moving an application from the 8bit to the 32bit world. You might not fancy porting the application to a new architecture. But trying to learn a new complicated peripheral and create a new driver for it that works with the current application code? Forget it. That is the argument that Jochen Hanebeck, senior vice president and general manager of the microcontrollers business unit, used to explain to engineers at Embedded World in February that peripheral compatibility is important. Hanebeck went further, arguing that application porting is pricier than many believe. He claimed that, for an industrial project looking to ship volumes of 20,000 units a year, even over a five-year period, the cost of switching from 16bit to 32bit software - through recompilation and porting efforts - would cost more than sticking with the old architecture, as long as that architecture has been given comparable speed boosts, even assuming a 20 per cent cost reduction in hardware costs if the switch to 32bit is made.
If porting is a pain, why do it? Trends in software development outside the confines of individual projects are encouraging people to change their favoured microcontrollers. At the root of it all is project time. Hanebeck showed how the average microcontroller in a washing machine uses twice as much memory as the computers in the Space Shuttle's main control systems. The washing-machine designers have a lot less time to get their project done, and so trade code efficiency for time. In software development terms, one immediate benefit of the 32bit environment is that you can kiss goodbye to paging and segmentation. In order to deal with more than 64KB of code or data memory at a time, most 8bit and 16bit architectures have to use complex paging schemes as most use 16bit address registers. "Linear address space is so much easier to understand. Especially if you are used to programming on a PC," says Anders Holmberg, product manager at tools developer IAR Systems.
However, this does not mean that linear addressing is not possible on an 8bit architecture. STMicroelectronics says it has implemented linear addressing - supporting up to 16MB of memory - on its latest 8bit microcontroller architecture, the STM8. In keeping with the trend to have overlapping portfolios, many of the STM8 parts will use the same peripherals as the ARM-based STM32. But, instead of encouraging customers to simply move to 32bit to get bigger memory arrays, Alexander Cjazor, marketing manager for ST's automotive body-electronics microcontroller group, says the company saw a need for an 8bit line as well, primarily from the Chinese market. Customers there are cost-sensitive enough to take the difference in core size between 8bit and 32bit processing into account. However, realising that paging is difficult to use, ST designed the STM8 so that 8bit registers could be combined to generate the 24bit addresses needed to address up to 16MB. Linear addressing is not the only consideration: moving to 32bit can simplify some other aspects of development, particularly with high-level languages. Holmberg says more customers are turning to C++ for embedded designs: "Universities are pushing C++. And users are used to that way of working."
In principle, there is no reason why a sub-32bit processor cannot run code generated by a C++ compiler. However, making the code run quickly often involves more work from the developers: many of the base types in a language such as C and C++ were defined assuming a 32bit architecture. Haydn Povey, product manager at ARM, says the trend to use meta-languages such as the block-based environments made popular by The Mathworks' Simulink and National Instruments' Labview will further help with the move to 32bit. "The meta-languages are very popular in automotive and they are leaking into other domains," he says. "They are a natural fit for 32bit. I think that in the next few years, they will have the same relationship to C as C has to assembler now." A steady migration to 32bit does not necessarily spell the end of the 8bit and 16bit markets. Povey says: "Unit volumes [in 8bit] will grow as new people come in." Things that used to rely on hardwired logic are using microcontrollers instead: "The switch in the vacuum cleaner is no longer a switch, it's a microcontroller."