
Although 8-bit MCUs continue to be the most widely used, the increasing processing requirements of many embedded applications suggest a transition to faster processors. Much publicity has been made on 32-bit devices, expecting them to bring power and address new challenges. Reality is more complex as the performance that designers expect for their systems is more than only MIPS. Migrating to a new architecture is not always necessary.
Reaching the BoundariesMost 8-bit architectures were developed before the emergence of high-level languages such as C. The instruction set was made for assembler, and the CPUs lack key functionality such as 16-bit arithmetic support, conditional jumps and memory pointers. Many of these architectures require several clock cycles per instruction, limiting the available MIPS at a given frequency. Some of them have reduced the clock division and increased frequency, but the theoretical MIPS are not efficiently available. Another issue is the lack of support for large memory sizes that are required in today's applications.
To solve older CPU architectures' inability to meet market needs, many vendors promote 32-bit solutions. This is great for applications that need 32-bit processing power, but many designers switch to 32-bit for the wrong reasons. Solving the 8-/16-bit microcontroller limitations with a 32-bit MCU comes at a high price. A 32-bit CPU contains significantly more digital logic than any 8-/16-bit CPU and uses more aggressive process technologies than 8-/16-bit MCUs. This increases the maximum speed and reduces the size of digital logic, but it also increases the static power consumption dramatically. For many battery powered or energy critical applications, a transition from 8-/16-bit to 32-bit is not possible. High precision analog peripherals, high EMC tolerance, high I/O drive strength, external and internal oscillator options and low voltage detectors are essential for embedded applications and not easy to achieve with aggressive processes.
System performance is not just a function of MIPS, and a higher clock rate does not always solve the system performance problem. Performance is also a function of how efficiently those MIPS are used. In interrupt-driven or communication-intensive applications, better system performance is more likely to be achieved by off-loading data transfer and interrupt handling functions from the CPU and at the same time providing extra communication channels to avoid bottlenecks.
This is the approach used by some new ultra-low power microcontrollers such as the AVR XMEGA. The new devices have a flexible DMA controller and an independent event-handling system with a dedicated routing network. These features, coupled with a single-cycle 32MHz AVR RISC CPU, provide the ultra low power consumption associated with 8-bit MCUs and system performance that can exceed low-end 32-bit MCUs in many applications.
The XMEGA is based on Atmel's RISC AVR CPU, and is compatible with all other 8-bit AVR MCUs. Identical memory space and memory locations for all peripheral registers in all XMEGA devices provide 100% code compatibility between all devices. All code libraries and drivers are directly reusable from the smallest to the biggest device. XMEGA also offers high-accuracy, high-speed analog peripherals with 12-bit ADCs with up to 2MSPS, 12-bit DACs with up to 1MSPS and advanced analog comparators. The XMEGA also has a 4-channel DMA controller. Without using the CPU, data can be moved from a peripheral register to internal or external SRAM, between SRAM locations, and even between peripheral registers directly. The DMA can transmit from 1 byte to 16 Mbytes in a single transfer. The large data transfer size is possible due to the simple linear data memory address space in the AVR, and auto increment/decrement and reload features in the DMA controller.
Event system avoids latency and saves even more MIPS - like a reflex in the human body the XMEGA's Event System enables inter-peripheral communications without CPU or DMA usage. Events are routed between peripherals through a dedicated network outside the CPU, data bus and DMA controller. This Event System enables the possibility for a change of state in one peripheral to automatically trigger actions in other peripherals.
The XMEGA consumes only 0.35mA/MHz in active mode and offers true 1.6V operation including all analog modules, oscillators, and Flash and EEPROM programming. Using the second generation of picoPower technology, the XMEGA consumes 100nA with RAM data retention and wake-up interrupts enabled. When running a real time counter (RTC) from an external 32kHz crystal it consumes 0.65uA. With its watchdog timer (WDT) clocked from a dedicated on-chip 1kHz ultra-low power oscillator and a true brown-out-detector (BOD) that uses less than 1uA, XMEGA uses 2uA in sleep mode with RTC, WDT and BOD running. This approach achieves a much more accurate RTC clock and better safety than using an internal low power oscillator and zero-power BOD. The payoff is substantial for battery operated applications, such as metering or ZigBee, that require several years of battery life.
There is a great advantage for most 8- and 16-bit applications to avoid moving to a 32-bit MCU. By adding innovative features, high end peripherals and conserving CPU cycles, an 8-/16-bit MCU like XMEGA can achieve system performance while maintaining their superior low power characteristics, and user friendliness which results in fast product development cycles. With code compatibility with all existing AVR devices and by using the same tools and development platform, the XMEGA offers designers a unique opportunity to easily extend the reach of their applications.
by Kristian Saether, Atmel Corp