Jon TitusAsk an engineer who uses microcontrollers whether processor cores matter and you'll likely hear, "Not much." People at three MCU vendors--Silicon Laboratories, Renesas, and Microchip Technology echo this answer. The capabilities and types of peripherals blended into an MCU chip matter much more.

"Ten years ago, people did a lot of programming in assembly language, so CPU architecture played a larger role in choosing an MCU" said Ritesh Tyagi, product marketing director for MCU solutions in the Consumer & Industrial Business Unit at Renesas Electronics America. "Programmers and engineers understood one type of architecture and stayed with it. But in the mid to late '90's programmers shifted more effort to writing code in C. That meant they didn't have to learn about MCU architectures in as much detail, so the architectures no longer played a dominant role in MCU selection."

"That's good news," noted Mike Salas, director of marketing for the MCU division at Silicon Laboratories. "Semiconductor companies now have a lot more interest in creating the peripherals that surround a core CPU. We use an enhanced 8051 CPU in our MCUs and then put our mixed-signal experience to work in capacitance-touch sensing, LCD controllers, wireless transceivers, and other on-chip peripherals."

"Look at direct-memory access [DMA] as an example of a new peripheral," said Erlendur Kristjansson, product marketing manager in Microchip's high-performance microcontroller division. "DMA has become more of a standard feature even in some of our 16-bit MCUs. In some cases, engineers think they need additional processor speed or performance because they must move a lot of data. But the DMA capability lets hardware on the chip--but external to the CPU--take over functions the engineers would normally do in code. So, the DMA channels can assume many of the CPU's intensive data-transfer tasks and free it for other tasks or let it stay in a low-power state. The addition of DMA means engineers might not need all the MCU performance they think they do."

"Traditionally, engineers have used external hardware to control an LCD or other type of display," continued Kristjansson. "But instead of adding an external LCD controller, engineers now find it already built into an MCU. That type of approach also helps engineers reduce the cost of a design because they don't need the extra controller chip or space for it on a circuit board. To provide engineers with flexibility and choice, we also supply drivers and firmware libraries that support either an on-chip or off-chip LCD controller, which helps jump start projects."

Requirements for wireless communications have also caused MCU manufacturers to look beyond their CPU architectures and concentrate on peripherals and support software. "The engineers who work with MCUs don't want to become radio-design experts," said Salas. "They don't want to think about how to add a power amplifier or low-noise amplifier to an RF circuit, so we integrate those functions within an MCU chip. The engineers no longer have to figure out how to connect a wireless transceiver to an MCU and get them to talk to each other. Integrating everything in one package gives engineers an easy-to-use drop-in device."

"You can take a similar approach with capacitive touch sensors," said Salas. "Touch sensing can look like black magic to an engineer unfamiliar with this technology. They immediately ask, 'How do I design the sensing surface and contacts and then interface it to a touch screen? How do I create the capacitance-sensing circuits to provide useful information?' By integrating the sensing technologies within the MCU as a black-box, we simplify the engineers' jobs."

Although the types of on-chip peripherals dominate engineers' concerns about which MCU chip to specify, these engineers do not live by hardware alone. "They also need a complete 'eco system' that includes hardware and software tools, third-party tools, application notes, sample code, development kits, tutorials, lab exercises, and other resources," emphasized Tyagi of Renesas. "Engineers and designers want an MCU with all the support pieces already in place."

"Suppose an engineering team must write industrial motor-control software and they already have a complicated vector-control algorithm that works," said Tyagi. "They have used the MCU-X architecture but they want to examine the MCU-Z architecture that seems to offers higher performance, a different mix of peripherals, a smaller package, and so on. They expect the manufacturer of MCU-Z will have a ready-to-go motor-control design and coded algorithms the team can use to evaluate MCU-Z. Then they can modify that code and use it in their motor application. The team cannot spend another 12 months writing new code." Without that type of support--regardless of CPU architecture and capabilities--an investigation of MCU-Z will come to a dead stop. "Manufacturers cannot give engineers a super MCU with no support," said Tyagi.

GopherGopher to the Rescue
The wide variety of peripherals available in MCUs can pose a challenge. How do you determine which devices you can operate independently without pin-sharing conflicts and how can you easily compare vendors' parametric specs? The GOPHER software from Gruntware  ( will do the job. You can select the peripherals you want, enter how many of each you want, choose manufacturers or device families to compare, and GOPHER finds the appropriate devices. GOPHER lets you select from 140+ search parameters from 25 MCU suppliers; from Analog Devices to Zilog. The free GOPHER Web version on the Gruntware Web site lets you use 19 search parameters. I recommend GOPHER highly.