Consistent Peripheral Implementation Can Key Designers’ MCU Choices

Myriad factors can impact the choice a design team makes in selecting a microcontroller (MCU) for a project. Certainly you should look for a match in terms of cost and processing power to the application at hand, and the MCU architecture and instruction set may come into play. A design team should also search out an MCU that has the integrated peripheral functionality that matches system requirements, but most every MCU vendor offers a similar broad peripheral mix. Increasingly it’s the consistency of peripheral implementation across a manufacturer’s MCU portfolio that may be the most important factor since developing drivers and learning the register-level interface to a peripheral takes significant time in the development cycle.

Time to market remains the top priority in most projects today. So the MCU selection process is often focused on a device that can accelerate the design process.

Looking back, the instruction set architecture (ISA) has often been thought most important in terms of slashing design time. In the days of assembly language programming, ISA knowledge was certainly key to a quick start on a project. Today, however, most design teams use a high-level language such as C or C++ even with low-end MCUs. Ritesh Tyagi, director or product/segment marketing at Renesas, said, “I haven’t seen more than 1 or 2% of our customers that are working primarily in assembly language.”

Despite the move to high-level languages, several MCU vendors are touting the advantages of standardizing on one MCU core. For example, STMicroelectronics, NXP Semiconductor, Texas Instruments (TI), Freescale, and others all are increasingly relying on the ARM core and ISA for their 32-bit products although TI and Freescale also have alternative 32-bit architectures.

The question arises as to whether reliance on MCUs based on the ARM ISA is in itself an advantage for system designers. As mentioned earlier, knowledge of the ISA provides little advantage for the software developer. And even though multiple MCU vendors use the same core, each vendor relies on its own tried and true peripheral mix. So a designer working with a TI ARM-based MCU today, and an NXP ARM-based MCU in six months may benefit little in terms of a fast start due to a common ISA, but may have to develop a new driver set to effectively access the on-chip peripherals.

Peripheral consistency speeds development

The key to cutting design time is reuse of both code and knowledge, and reuse of driver software and portions of an existing code base. So Increasingly, it’s the peripheral implementation that leads design teams to stick with a particular MCU vendor according to several device manufacturers. Indeed MCU vendors seem to be striving for peripheral consistency whether the MCU at hand is ARM based, MIPS based, or like most legacy families based on a proprietary architecture.

Consider as an example, the ubiquitous USB peripheral. Microchip director of applications, architecture & marketing Fanie Duvenhage said, “We are probably the only vendor to offer a consistent USB solution across 8-, 16-, and 32-bit MCUs.” That consistency allows the code reuse than can cut development time. And note that the consistency comes across Microchip’s legacy PIC family and the 32-bit MIPS-based PIC32 MCUs.

Renesas has faced an even broader challenge in peripheral consistency given that the company and its product line have evolved from the initial merger of Hitachi and Mitsubishi, and the more recent addition of NEC into the mix. Still the company is quickly moving to a consistent peripheral architecture. For example in the communications area, Tyagi asserts that functions such as CAN and LIN are similar across the 8-bit R8C, the 16-bit M16C, and the 32-bit RX families.

The R8C doesn’t support USB but the follow-on RL78 that is just coming to market does. In the USB case, Tyagi says design teams can largely use the same driver across the families according to Tyagi, although he noted that 8-bit designs may only use USB peripheral functionality whereas 32-bit designs might require both host and peripheral functionality.

8- to 32-bit migration

Freescale is another company that both has a diverse set of microarchitectures across its MCU portfolio, and that has utilized consistency in peripherals to ease the migration path for system designers. For example, when the company rolled out its Coldfire V1 32-bit family derived from the Motorola 68000 architecture, it did so with complete peripheral compatibility with the 8-bit HCS08 family that was derived from the Motorola 6800 architecture. The families shared timer, A/D converter, SCI, SPI, I2C and other peripherals.

Subsequently Freescale added more capable peripherals to higher performance MCUs such as Ethernet support and more precise data converters as the company spawned Coldfire V2, Coldfire V3, and Coldfire V4/V4E MCU families. Still the company has strived for peripheral compatibility to allow design teams to easily move up or down the portfolio in terms of choosing an MCU with the desired price and performance attributes.

Renesas’ Tyagi sums up the goal saying, “Companies need an MCU platform that supports low-, mid-, and high-end members of a product family. They need orthogonality in the peripheral set. People want to know how much code they can reuse.”

Data converters scale with MCU performance

Still some peripherals will inevitably differ simply due to performance capabilities. For example, data converters are among the most widely used MCU peripherals. But a low-end 8-bit MCU doesn’t need an A/D converter with the same precision, number of channels, or sampling rate that’s required in an application for a 32-bit MCU.

Micochips’s Duvenhage said, “It’s not realistic to think that you could have one universal A/D converter implementation.” Instead, Microchip focuses on using a similar architecture across its portfolio in terms of the register-level interface to the converter. And Duvenhage says that the company especially strives for consistency in transition points for instance offering very similar converters in a high-end 8-bit PIC18 product and in the 16-bit PIC24 and dsPIC products. That consistency allows design teams to easily migrate up or down the portfolio.

Renesas takes a similar approach according to Tyagi. He points out that the register implementation is similar in the 8-bit R8C family to the implementation in the 32-bit RX family. But the former integrates a 10-bit converter while the RX family integrates 12- to 16-bit converters.

Designers will find more compatibility in some peripheral types than others. For example, Microchip offers very similar PWM peripherals across its portfolio according to Duvenhage. He said, “We offer enhanced capture and compare functions even on our low end MCUs.” Indeed the company offers a single PWM channel in its PIC12 and PIC16 products. The capture mode supports timing of an event and the compare mode triggers an external event after a predetermined time. These functions are in addition to the standard PWM operating mode. Still the functionality is enhanced as you go up the Microchip portfolio via finer resolution and more operating modes.

Many factors impact the development time required to complete an MCU-based project and minimizing that time is a goal that most design teams share. Reusing code across projects is a key element in reducing time to market. The driver software and subroutines that deal with the peripherals integrated on an MCU are areas that are ripe for code reuse. Design teams should certainly consider the consistency of peripheral implementations when selecting an MCU for a project. It may be that even though you need a more powerful MCU with more memory for the new project, that you can choose an MCU with peripherals that are very similar to an MCU you had used previously. That consistency in peripherals will impact how much existing code can be leveraged on the new project. Certainly you should consider all aspects of an MCU – ISA, development tools, power consumption, cost and others -- when choosing a device for your next project. But the peripherals set may prove most important in the selection process.