Power Drives MCU Evolution
Requirements for portable, low-power consumer devices, as well as energy-efficient embedded systems, drive MCU development and offer options for embedded engineers.
According to Stan Lee (and Spider-Man’s Uncle Ben), great power brings great responsibility. For embedded developers, the opposite is often true. The superhero task that brings great responsibility is to do even more with even less power. This is obvious for portable, battery-powered devices, but it’s true also in growing microcontroller market applications such as automotive and industrial, where energy-efficiency drives demand and design parameters. We talked to MCU experts about power and performance tradeoffs—and more—in our roundtable discussion. See what Andreas Eieland, senior marketing manager for flash-based microcontrollers at Atmel Corporation; Alexis Alcott, product marketing manager of MCU16 marketing and Wayne Freeman, product marketing manager for the Security, Microcontroller & Technology Development Division of Microchip Technology, Inc.; and Steve Darrough, vice president of marketing at IXYS- Zilog have to say.
EECatalog: Microcontroller vendors are taking a variety of technology approaches to reduce device size and power. What are some of the tradeoffs embedded developers need to consider as they weigh their options?
|Alexis Alcott||Wayne Freeman|
Alexis Alcott and Wayne Freeman, Microchip Technology Inc.: With the expansion of embedded systems into portable electronics, metering and medical applications, designers are required to come up with designs that are both portable and consume low power. One of the most important considerations for an embedded developer is to consider the tradeoffs between power consumption and other factors such as size, cost and complexity. Advanced process technologies used in the manufacturing of MCUs can reduce die size and lower costs, but with the tradeoff of increasing the leakage currents and static power consumption. On the other hand, selecting an MCU with a larger process technology reduces leakage currents but results in higher dynamic current consumption and larger die size. Microcontroller vendors who control their own manufacturing processes offer a special advantage in being able to control the tradeoffs and design specifically for lowest power offerings.
Andreas Eieland, Atmel Corporation: There are two sides to this question: analog and digital. For the analog portion, there are tradeoffs between accuracy, size and power and you can only fully optimize two of the three. Many vendors, including Atmel, design optimization for a tradeoff between these three by providing a selectable bias current going into the analog module so that the developer can select the best power/performance tradeoff for his application
For digital modules, the first tradeoff is to optimize for active-mode or sleep/static-mode power consumption. There are many tricks for optimizing leakage such as making transistors longer. But this affects your maximum speed—so basically transistors get slower the longer you make them. Another option is to back bias your SRAM, but this impacts the size of the die. For Atmel, it comes down to the peripherals available on a product and what markets and type of applications we believe will be the best fit. This is all determined when we sit down in our spec phase and go through the different options.
Steve Darrough, IXYS-Zilog: Several considerations emerge when trading power utilization against performance, depending on the applications and their needs. An example is the use of state machines and system-looping techniques in the architecture, which can reduce consumption yet still allow the microcontroller to have its required resources to support the application. Some applications, like wireless, can use polling and other types of techniques to achieve better power utilization.
EECatalog: Today’s users of microcontroller-based mobile devices demand long battery life along with instant-on response. How are developers balancing those conflicting requirements?
Alcott and Freeman, Microchip: MCUs designed for low-power applications are loaded with features for managing power vs. performance. For example, many products offer distinct modes that can lower power from full Run at <1 mW to <100 nW in sleep modes. In between, there are many modes that allow developers to trade off between power, response time and performance. Doze mode allows the core speed to scale down, while leaving the peripheral speed constant. This has the impact of reducing current, but offers instant-on response back to full speed run by the core. A few steps lower, there are several sleep modes, which shut off the core and flash, but can retain RAM and register states, along with the ability to run a variety of peripherals. Sleep mode takes power consumption to just 21 µW, but allows for ADC operation, LCD operation, UART message detection, timers and interrupt detection. The wake-up time from this mode can be as low as 5 µs. Lower-power sleep modes are also available that further reduce the current consumption to just 1 µW with LCD, UART, timers and interrupts all still available in this mode, with RAM and register values maintained with wake-up times of 110 µs. For lowest current consumption, deep-sleep mode powers off all of the logic on this chip with the exception of a real-time clock, watch-dog timer and interrupts, reducing current to just 120 nW. In this mode, the wake-up time is extended to allow for the power-up of the core and peripherals and memory initialization, which can take up to 200 µs to 1 ms. As you can see, flexibility is key to offering designers many choices to manage the tradeoffs between extending battery life and wake-up times depending on their application requirements.
Eieland, Atmel: For process geometries 130nm and smaller, the SRAM leakage is normally what breaks your power budget, especially if the ambient temperature is high. The RAM retention is also what you need together with rapid-stabilizing RC oscillators to ensure an instant-on response. For larger process geometries, you do not have any issues with the instant-on/RAM retention requirements, even over temperature.
Many vendors stay in relatively large process geometries to keep the leakage down, while others do partial RAM retention or even just a couple of bytes of retention. However, retaining only a handful of bytes is normally not enough to ensure an instant-on response as you will still have to re-initialize your peripherals, etc., before you can react to whatever wakes up the device. Atmel allows its device peripherals to cooperate and make intelligent decisions. This ensures reduced wake-up frequency by allowing the device to remain in sleep if the peripheral decides that the CPU is not required to resolve the situation. At the same time, the system can identify an important event and sound the alarm to wake-up the system.
Darrough, IXYS-Zilog: Soft start, memory utilization and other techniques leverage harvesting to extend and renew charging of the power source.
EECatalog: Touch sensing is now commonly integrated with microcontrollers, but with rapid evolutions in user interfaces—such as voice and gesture—what capabilities should developers be watching for moving forward?
Alcott and Freeman, Microchip: During the last few years, the evolution in user interface technology was very rapid—touch keys to touchless interface driven by the consumer market and expanding into all products with user interfaces. Capacitive touch buttons can be implemented with many PIC MCUs, including open algorithms and techniques to engineers, so that they can have the freedom to innovate with touch implementations. Touch can be integrated into systems with products including various performance levels, peripheral mixes, eXtreme Low Power (XLP), small packaging, and unique technologies such as metal over capacitive. From a system level, we are seeing touch buttons/sliders integrated with applications in higher-end microcontrollers in addition to the low-cost dedicated touch controllers.
In addition to our touchscreen technologies, for analog resistive and projected capacitive, we also see growing “touch pad” solutions, for user interface on end equipment such as remote controls and automotive. Another new trend is “touch-less” interface with intuitive, gesture-based, non-contact user interfaces for a broad range of end products.
Eieland, Atmel: Touch with lower-power consumption, without the need for external components and support for hover are features we are seeing, and currently offering. Gestures on the touch surface can already be supported by an extra layer of code on most touch implementations and I am confident we will see products that support hovering gestures soon.
Darrough, IXYS-Zilog: New navigational technologies are emerging now that will challenge developers with new interfacing application models. Emerging examples are e-ink, flexible paper and the advancement of even optical navigation are now emerging that create the need for new and creative solutions.
EECatalog: MCU performance and complexity continues to rise. What do developers need to consider with respect to development tools?
Alcott and Freeman, Microchip: When evaluating any development tool infrastructure, engineers should focus on four areas: The IDE, or integrated development environment, must be easy to use, highly modular and support a wide range of MCU price and performance points. C compilers should be as highly optimized as possible for the target architectures to ensure the smallest code footprint. Developers should also look for a wide range of available development hardware, from simple prototyping boards to highly functional test-and-measurement kits. We offer hundreds of development hardware tools, which give customers the option of selecting the appropriate tool for their development task. Our tool offering is designed to take advantage of a unique feature of Microchip’s MCU portfolio—the consistent use of similar peripherals across the product line. This allows for maximum re-use of existing code base in future projects. Lastly, the availability of supporting documentation and personal assistance are highly important to consider.
Eieland, Atmel: At Atmel, we believe tools should be easily accessible, easy-to-use and low-cost so that you do not have to go to your bosses’ boss to get the PO signed. In addition, Atmel ensures that we use our application engineers to write the basic drivers, stacks and example applications for our devices so that our customers won’t be required to spend their precious R&D time on writing code that will not differentiate their end product. Even more, we’ve gotten some very good feedback on our integrated development environment that offers compilers, simulators, documentation and more in one program. With regards to complexity, we also see more engineers involved in a typical program; as a response to this, we have added plug-ins for revision control of documents and a collaborative workspace inside Atmel Studio
Darrough, IXYS-Zilog: Development environments need agility now more than ever. Development environments that are proprietary or even difficult to work in meet more and more opposition to adoption rate. Value is better established in providing interoperability and open development communities
EECatalog: What kinds of safety and security considerations do developers need to keep in mind for MCU-based applications such as medical or financial transaction devices?
Alcott and Freeman, Microchip: Financial transaction devices require a very high level of encryption to protect data that is being transferred. Developers also need to consider items such as Privacy (AES-128), Authenticity (HMAC) and Integrity (SHA-2). Developers need to look for availability of free software libraries with the ability to implement flexible solutions on a broad range of microcontroller options.
Medical applications may also require a high level of security. For example, access control to a drug-dispensing station may need to authenticate a user and provide secure transmission of data. Safety considerations would apply to products that are implanted in the body for example. For the implantable device, designers must consider FDA requirements and provide a high-quality, reliable product. For example, one safety requirement is the removal of radio frequencies that are within a hospital room environment that could interfere with equipment. New technology such as body area network (BAN) systems being developed now may not use radio frequency technology for transmission. One example of this is the Microchip BodyCom™ technology that offers short-range, low-data-rate secure communication solution utilizing the human body as the transmission medium as a safe alternative.
Eieland, Atmel: Similar to power consumption, there is a split in requirements around 130nm. For devices in larger geometries, CRC checks, tamper proofing, lock bits and self-programming control commands, etc. are sufficient. Previously there were concerns for single-event upsets on smaller geometries, but at least for earth-based applications, we do not see a need for that anymore—at least for geometries 90nm and up.
For devices around the 130-150nm range and below, a designer should look into features like memory built-in self tests (MBIST) and perhaps a hardware CRC solution to ensure that they can run the CRC algorithm more frequently and with less overhead. Having a dedicated device service unit on the silicon that manages IP access, lock bits, and the previously mentioned CRC and MBIST is definitely something to look at.
For all geometries, having the possibility to run encryption in either hardware or software for both communication and firmware upgrades, as well as mechanisms to protect against intrusive IP attacks, are important and something Atmel addresses.
Darrough, IXYS-Zilog: New security threats are surfacing that compromise not only sensitive data, but now with DoS attacks meant to disrupt functionality. Many systems suffer performance challenges due to invasive attacks mean to even redirect normal operational functionality.
Cheryl Berglund Coupé is editor of EECatalog.com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Windows Developer’s Journal and she has developed presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology companies and agencies in the Northwest.