8bit fighting back
4 mins read
Despite the allure of the 32bit mcu, 8bit micros still have a viable future. By Chris Edwards.
Luminary Micro started it several years ago when it became the first company to use ARM's Cortex-M3 core. While the entry level part did not have much on it, it gave Luminary the opportunity to launch a 32bit microcontroller for $1. Others followed suit, using either ARM cores or their own, in a plan to win share from the largest mcu market: that for 8bit parts.
Andreas Eieland, product marketing manager at Atmel, says: "We think we are still some years away from the peak 8bit year. There is strong growth in 32bit, but 8bit has a 40% market share – and that's measured in revenue; the difference in units is huge."
Jim Stuart, Freescale's European marketing manager for industrial and multimarket mcus, agrees. "People have been forecasting 8bit's demise for the last 10 years."
Despite 8bit's resilience, 32bit suppliers aim to use a shrinking cost imbalance to drive things more quickly in their direction. STMicroelectronics' ceo Carlo Bozotti said at a recent financial analysts meeting: "We have anticipated a migration from 8bit to 32bit architectures and we will expand these families. This is a great opportunity."
Geoff Lees, general manager of NXP's mcu business, argues: "Our basic ARM M0 core is smaller than almost all 8051s, but with more memory. We have 1kbyte of flash versus 128byte of eeprom on a typical 8051."
The difference comes from the way in which chipmakers have pushed process technology more aggressively for their 32bit offerings, generally using 0.18µm or more advanced processes. The 8bit families tend to use 0.35µm or 0.25µm.
Eieland notes: "Part of the drive towards 32bit can be explained by the demand for more peripherals." The additional MIPS are generally needed for interrupt processing, although it is possible to avoid the shift to 32bit by putting more intelligent peripherals onto 8bit products, which Atmel has done, he says.
Compiler and instruction set design in 32bit architectures has advanced to the point where there can be little difference in code-memory efficiency, although the performance advantages of using short variables on resource limited 8bit processors can improve use of data memory.
Lees recalls: "We were surprised when we did benchmarks, but the number of pure 8bit applications that don't use subroutines and don't use a 'huge' memory model [to access more than 64kbyte of memory] is dwindling. We ran tests on the 8051MX. When it reached 64kbyte, instead of going to 64.1k, it went to 71 or 72k instead."
The flat memory architecture of 32bit means any need for paging or segmentation lies way beyond the on chip memory capacity of any mcu for some years into the future.
Stuart says he wrote an application for Freescale's Flexis parts, which provides I/O compatibility between 8bit and 32bit versions. "It came to around 100kbyte and was pretty much identical when compiled for ColdFire v1. Code size is not a major issue," says Stuart. "And, if you are dealing with short timescales, there is a lot of benefit in moving to 32bit."
Fanie Duvenhage, Microchip's director of applications, architecture and marketing for microcontroller and security products, argues: "The perception is that 32bit software is easier to write. You do have to be more concerned with the resources, but whether you write for 32, 16 or 8bit, you have to be conscious of how you handle the hardware: make sure I/O registers and important memory blocks don't get corrupted by extraneous events. Simply moving to 32bit doesn't get you around the detailed diligence you need."
Stuart adds: "Although, for ease of use, I would go for 32bit every time, that is not the only criterion. It is fine in low to medium volume applications, but in high volume, every cent counts. If you can do it with a part that is 5cents cheaper, you go for that part and put the investment into software development."
Duvenhage says the choice of process technology tends to hold back 32bit devices. "If we developed the 8bit mcus that customers tell us they need on more advanced processes, they would become more expensive. The first first thing we get bombarded with is a requirement for 5V operation. You can to that with 32bit, but it's not easy. The processes used to make those mcus low cost do not really support 5V without a lot of overhead."
Eieland stresses: "Voltage tolerance is important. We are not running on very aggressive processes and that gives wider voltage tolerance. It means customers don't need to buy a $1 voltage regulator or, with some 32bit devices, several voltage regulators."
Although some specialist low power 32bit mcus have appeared, Stuart argues: "For low power, 8bit will still give benefits over 32bit."
Eieland adds: "The leakage on 8bit devices is unmatched by 32bit products. There is a lot of marketing about nano amp standby, but this may only be with a few registers active, not with the full ram contents available. That will have an impact on wakeup time."
To try to maintain a price differential against competition from 32bit parts, some manufacturers are looking to move 8bit devices to smaller geometries. Renesas has started by porting its R78 architecture to 0.13µm, using a combination of design and process adjustments to keep leakage low. Although Renesas classes the RL78 as a 16bit core, Mohammed Dogar, head of product marketing in Europe, says this is now the baseline level for its mcus. "We won't develop new 8bit versions."
Eieland sees the need for process migration. "In order to be competitive, 8bit parts will have to move to more aggressive processes and provide more flash. But they can run in cheaper fabs where the wafer cost is lower."
Stuart says 8bit parts ported from 0.25µm processes do not need to lose features such as higher voltage tolerance: "We are continuing with 5V compatibility on the next generation technology. It won't be 90nm; it will be somewhere in between. As you go to smaller memory sizes, 90nm offers less from a cost perspective and the smaller the geometry, the more voltage protection you need."
In the meantime, suppliers are trying to avoid getting designed out completely when customers migrate from 8bit architectures by using development tools that provide a common front end to their 8, 16 and 32bit products.
"You can select the target architecture behind the scenes and the compiler knows how to make that work," Duvenhage claims. "You can move up and down pretty transparently."
Stuart says designers will have wider choice when it comes to picking a target mcu. "We do see a squeeze on 8bit and there will be a larger overlap with 32bit than we ever had. But, for 8bit products, the next technology node will probably last another five years. Maybe after that, demand for 8bit will diminish, but it won't diminish fast. We think 32bit will have an impact, but new 8bit applications keep popping up all the time."