Matching microcontrollers to most applications is a relatively simple feat. The task becomes more onerous, though, when high performance meets low-power requirements. Portables, remote monitoring systems, and even low-cost motor controls fall into this category. Choosing MCUs augmented with specialized hardware or additional processors is one way to garner the performance without moving up to higher-performance processors.
Software delivers the goods at one end of the spectrum, while ASICs lie at the other extreme. Sitting somewhere in between are most MCUs. One 8-bit example, Zilog's Z8 Encore! XP, has a 20-MHz eZ8 processor surrounded by the usual complement of serial and parallel interfaces. It also adds a few useful twists like a UART port with IrDA encoder/decoder, a temperature sensor, and a transimpedance amplifier. These peripherals can simplify the job that the processor must perform, but the processor remains the center of attention.
To reduce power, many MCUs can power down the processor while letting peripherals continue to operate. The peripheral restarts the processor when a particular action occurs, such as receiving a character or the occurrence of a timeout. MCUs typically weave in a standard set of peripherals, including serial ports, general-purpose I/O (GPIO) ports, and timers. Analog-to-digital converters (ADCs) and digital-to-analog converters (DACs) are also standard for MCUs servicing analog interfaces.
Servicing this array of peripherals keeps an MCU humming. However, power becomes an issue when the processor must run at full speed and all peripherals are active. The ability to power down unused or idle peripherals can reduce consumption, but the processor is typically the most power-hungry component. Thus, minimizing the processor's power requirements will take a serious bite out of overall system consumption.
In applications such as motor control, specialized peripherals can help low-end 8- and 16-bit MCUs boost performance. They tend to deliver more performance so these MCUs can handle a chore. In addition, they can slow or shut down 32- and 64-bit MCUs while continuing to run. Specialized peripherals often handle bit manipulations that are less efficient with 32- or 64-bit registers.
A host of specialized peripherals is available on standard MCUs. Many target a specific application or class of application. Texas Instruments' (TI) MSP430FE42x ESP430 power-meter MCU incorporates a set of ADCs and a modified version of the main MSP430, the DSP430 (Fig. 1). The subsystem is specifically designed to obtain power-meter readings where overall system power consumption must be minimized. A programmer can't modify the subsystem, which was programmed by TI. So, it's a specialized but fixed-function peripheral.
Another TI chip, the MSP430FW42x Single-Chip W-Meter, is designed as a water-meter recording device. It blends together a 10-bit DAC and comparator along with two state machines that are accessible to the programmer. This allows for more customization, enabling the peripheral to operate on its own so the main processor can shut down when idle.
DMA (direct memory access) support is one reason why TI's MSP430 line can take advantage of its peripherals. Thanks to the DMA flexible implementation, an application can configure and forget both DMA and specialized-peripheral support.
MOTOR CONTROL AND TIMING
In some cases, DMA support and application-specific peripherals simply don't provide enough flexibility. This comes up often in motor control, where timing details can become very complex. In this instance, a programmable solution that's timing-specific but less than a digital-signal-processor (DSP) coprocessor may be the right choice.
To that end, Motorola/Freescale Semiconductor has a range of Time Processor Units (TPUs) with various MCUs. The eTPU (enhanced TPU) is the latest incarnation, winding up in products like the Coldfire MFC5232 (Fig. 2). The eTPU consists of one or two programmable micro engines. Unlike specialized peripherals, the eTPU requires developers to create a substantial amount of code to get useful work out of the peripheral. Here, it's a matter of handling timing-based I/O such as pulse-width modulation (PWM) and quadrature encoder support often used with motor-control applications.
For simple PWM control, developers can employ standard support code for the eTPU. Or to make the eTPU sing, they can turn to third-party programming products. Ash Ware's eTPU Development Kit provides a C compiler for the eTPU, enabling MCU programmers to configure the eTPU.
These intelligent on-chip peripherals essentially bring asymmetric multiprocessing to MCUs. Ubicom's hardware-based multiprocessing support also brings symmetric multiprocessing to its MCU.
Still, don't overlook MCUs specifically designed for such applications as motor control. NEC's 8-bit, 20-MHz D78F0714 and the 32-bit, 32-MHz V850ES/IK1 target three-phase motor control for a single motor. While it may appear from the spec sheet to have the usual collection of timer and analog interfaces, a closer look reveals a set of interconnected peripherals that readily handle a specific task within a range of parameters.
Mobile multimedia devices resemble motor-control applications in that a preselected set of peripherals can often address an application. The processors often reside at the high end of the spectrum, but they're typically augmented with peripheral hardware that provides even more performance with lower power requirements.
Take the Renesas SH-MobileV2 RISC-based MCU, which targets portable multimedia devices (e.g., cell phones). It has a 32-bit, 133-MHz SH3-DSP CPU core with Java support and built-in DSP functions, plus a 2D/3D graphics engine cache. Intelligent peripherals include the on-chip MPEG-4 acceleration, a two-channel sound I/O unit, and a color-management unit that generates color conversions tailored to the characteristics of various displays. Of course, the SH-MobileV2 has typical MCU peripherals like an IrDA interface and a USB 2.0 interface.
Targeting a specific aspect of an application works even better when a standard exists, such as CAN (controller-area network). CAN support can be implemented with a simple serial port, but an intelligent implementation can significantly reduce system overhead (Fig. 3).
A sophisticated CAN interface like that found in the Infineon C505 line or in MCUs from companies like Microchip and Mitsubishi Electric have an application interface based on a mailbox architecture. Here, the main processor simply drops data in a specific location for a remote device. The CAN interface moves the data automatically, including handling of all the necessary protocol overhead. As with many intelligent peripherals, these CAN interfaces often operate independently of the main processor. They wake the processor when an event occurs, such as receiving data from another device.
CAN isn't the only standards-based communication link in hardware. CAN is often a link to LIN (local interconnect network), a lower-speed network often used to control simple devices like switches within an automobile. Intelligent LIN interfaces are available, though they're less common than CAN as LIN is slower but less complex to implement in software. This is another reason to consider hardware-based solutions: reduction in code requirements. Less code is particularly important for smaller MCUs with a more limited address range and where minimized flash-memory capacity often means lower cost.
One communications link not currently addressed is Ethernet TOE (TCP/IP offload engine) support. Ethernet interfaces are common, but they require significant software stacks and horsepower to handle the communication chores. Such is the case for wireless interfaces too. This should change over time, as Ethernet continues to move down the chain and as single-chip, networked, MCU solutions become more common. Likewise, the growth of interfaces like Zigbee will push the protocol implementation into hardware or into an intelligent peripheral that may be an MCU itself.
Analog components are appearing in a wide range of MCUs, from Philips Semiconductor's 8051-based LPC935 with dual 8-bit ADCs to Analog Devices' MicroConverter series, which includes 8052 and ARM7TDMI processors combined with a heavy-duty, 24-bit delta-sigma ADC.
Silicon Labs integrated a pair of high-performance 16-bit ADCs into its C8051F064 (Fig. 4). The 1-Msample ADCs can be serviced by an intelligent DMA unit that even delivers digital data to the I/O ports, allowing the chip to be an intelligent differential ADC or a dual, single-ended ADC. It's possible to power down the 8051 processor core when waiting for messages from an external source.
The analog/DMA combination is quite powerful, especially when trying to use an 8- or 16-bit micro to handle a fast, high-resolution, analog data stream. The DMA approach can't perform the fast, sophisticated data manipulation possible with a 32-bit processor, but this level of processing isn't required for all applications.
Choosing the right MCU, or fitting a round specialized peripheral into a square hole, often becomes challenging. Many times, rolling your own peripheral is the best solution. Many products haven taken this approach, but most have gone by the wayside. Two that have persevered are Cypress Semicondcutor's PSoC and Atmel's FPSLIC (Field Programmable System Level Integrated Circuit).
The Cypress PSoC architecture uses a combination of digital and analog blocks (Fig. 5). Each block can be configured as a single peripheral or linked together to create peripherals that are more complex. The available chips contain a variable number of digital (up to 16) and analog (up to 12) blocks. Low-cost versions are available for less than $1, making them an interesting alternative to fixed-function MCUs.
It's possible to program the analog and digital blocks into almost any configuration. But designers typically will choose from a set of predefined peripherals, like a serial port or an ADC. The configuration program that generates a configurate file lets developers drag-and-drop standard components in much the same way as a designer would lay out a board-level design. The chip chosen for the final implementation only requires the number of blocks necessary to support the specified high-level components, minimizing system cost.
The Atmel AT94Kxx FPSLIC takes a lower-level approach, linking an 8-bit AVR RISC processor with a 5- to 40-kgate FPGA (Fig. 6). The device contains requisite MCU peripherals like timers, PWM, UART, and GPIO ports. Additional standard peripherals can be implemented in the FPGA using the System Designer FPSLIC design software. More often, though, the FPGA is used to implement an application-specific hardware component. This requires a more complicated HDL design process and co-verification.
FPGA companies like Xilinx and Altera have chips that also incorporate one or more processors inside an FPGA. But this approach is more to augment an FPGA, rather than augment a standard processor via an FPGA. These products usually require all peripherals to be implemented in the FPGA, and memory configuration and programming turn into more-complex tasks. Furthermore, using devices like FPSLIC and PSoC to perform system configuration as part of the bootstrap process significantly limits startup and design tasks.
Intelligent on-chip peripherals, always common in MCUs, are now multiplying and gaining complexity as they infiltrate more intensive applications. Connectivity requirements are pushing features like authentication and encryption into hardware. We should expect to see more MCUs with multiple intelligent on-chip peripherals.
|NEED MORE INFORMATION?|
|Ash Ware Inc.||www.ashware.com|