Entries Tagged ‘Microcontroller’

Boosting energy efficiency – Energy debugging

Monday, April 4th, 2011 by Oyvind Janbu

Using an ultra low power microcontroller alas does not by itself mean that an embedded system designer will automatically arrive at the lowest possible energy consumption.  To achieve this, the important role of software also needs to be taken into account.  Code needs to be optimized, not just in terms of functionality but also with respect to energy efficiency.  Software has perhaps never really been formally identified as an ‘energy drain’ and it needs to be.  Every clock cycle and line of code consumes energy and this needs to be minimized if best possible energy efficiency is to be achieved.

While the first two parts of this article have proposed the fundamental ways in which microcontroller design needs to evolve in the pursuit of real energy efficiency, so this third part considers how the tools which support them also need to change.  Having tools available that provide developers with detailed monitoring of their embedded systems’ energy consumption is becoming vital for many existing and emerging energy sensitive battery-backed applications.

As a development process proceeds, code size naturally increases and optimizing it for energy efficiency becomes a much harder and time-consuming task.  Without proper tools, identifying a basic code error such as a while loop that should have been replaced with an interrupt service routine can be difficult.  Such a simple code oversight causes a processor to stay active waiting for an event instead of entering an energy saving sleep mode – it therefore matters!  If these ‘energy bugs’ are not identified and corrected during the development phase then they’re virtually impossible to detect in field or burn-in tests.  Add together a good collection of such bugs and they will have an impact on total battery lifetime, perhaps critically so.

In estimating potential battery lifetimes, embedded developers have been able to use spreadsheets provided by microcontroller vendors to get a reasonable estimation of application behavior in terms of current consumption.  Measurements of a hardware setup made by an oscilloscope or multimeter and entered into spreadsheets can be extrapolated to give a pretty close estimation of battery life expectancy.  This approach however does not provide any correlation between current consumption and code and the impact of any bugs – the application’s milliamp rating is OK, but what’s not known is whether it could be any better.

With a logic analyzer a developer gets greater access to the behavior of the application and begins to recognize that ‘something strange’ is going on.  Yes it’s a ‘code view’ tool, and shows data as timing diagrams, protocol decodes, state machine traces, assembly language or its correlation with source level software, however it offers no direct relationship with energy usage.

Combine the logic analyzer, the multimeter, and the spreadsheet and you do start to make a decent connection between energy usage and code, but the time and effort spent in setting up all the test equipment (and possibly repeating it identically on numerous occasions), making the measurements and recording them into spreadsheets can be prohibitive if not practically impossible.

Low power processors such as the ARM Cortex-M3 however are already providing a SWO (serial wire output) that can be used to provide quite sophisticated and flexible debug and monitoring capabilities that tool suppliers can harness to enable embedded developers to directly correlate code execution with energy usage.

Simple development platforms can be created which permanently sample microcontroller power rail current consumption, convert it, and send it along with voltage and timing data via USB to a PC-based energy-to-code profiling tool.  Courtesy of the ARM’s SWO pin, the tool can also retrieve program counter information from the CPU.  The coming together of these two streams of data enables true ‘energy debugging’ to take place.

Provided that current measurements have a fairly high dynamic range, say from 0.1µA to 100mA, then it’s possible to monitor a very wide and practical range of microcontroller current consumption.  Once uploaded with the microcontroller object code, the energy profiling tool then has all the information resources it needs to accurately correlate energy consumption with code.

The energyAware Profiler tool from Energy Micro shows the relationship between current consumption, C/C++ code, and the energy used by a particular function. Clicking on a current peak, top right, reveals the associated code, bottom left.

The tool correlates the program-counter value with machine code, and because it is aware of the functions of the C/C++ source program, it can then readily indicate how energy use changes as various functions run.  So the idea of a tool that can highlight to a developer in real time, an energy-hungry code problem comes to fruition.  The developer watches a trace of power versus time, identifies a surprising peak, clicks on it and is immediately shown the offending code.

Such an ability to identify and rectify energy drains in this way and at an early stage of prototype development will certainly help reduce the overall energy consumption of the end product, and it will not add to the development time either, on the contrary.

We would all be wise to consider the debug process of low power embedded systems development as becoming a 3-stage cycle from now on:  hardware debugging, software functionality debugging, and software energy debugging.

Microcontroller development tools need to evolve to enable designers to identify wasteful ‘energy bugs’ in software during the development cycle.  Discovering energy-inefficient behavior that endanger battery lifetime during a product field trial is after all rather costly and really just a little bit too late!

When is single better than multiple?

Wednesday, March 30th, 2011 by Robert Cravotta

For decades, many embedded designs used separate processors for handling the signal and control processing. Part of the reason for using separate and different types of processors is that the data and processing characteristics of control and signal processing are different enough to warrant different implementations. Control processing is characterized by frequent context switches as the control software must handle different asynchronous events so as to minimize the latency between when an event occurs and when the controller responds to that event. Microcontroller architectures that specialize in control processing usually include circuitry that enables them to detect and respond to interrupts quickly and deterministically.

In contrast, signal processing is characterized by very few context switches. Rather, signal processing exhibits relatively repetitive and predictable processing – however, the amount of computing that must be performed at each data point is usually substantial and overloads traditional microcontroller architectures. Signal processing architectures trade-off efficient context switching for efficient loop processing via special loop instructions and data handling via additional buses.

Because controllers and signal processors differ so much at the architectural level, the skills required to program them are different and the tools to develop with them are different. Managing two different processors simplifies partitioning the processing tasks, but it also increases the complexity of integrating between the two processing systems for the design team.

Within the last decade, a hybrid processing architecture emerged that combined control and signal processing into a single instruction stream. The most recently used label for such processors is digital signal controllers (DSC) which acknowledges its combined architectural trade-offs. DSCs are able to perform context switching like a microcontroller, but they are also able to process light weight signal processing tasks better than a microcontroller. However, they are not capable of handling heavy-lifting signal processing as well as dedicated signal processing architectures.

Hybrid architectures and the development tools to work with them have matured. Hybrid architectures allow a development team to use the same processor architecture throughout each part of the design which supports using the same instruction set and same development tools. However, the interface between the controller and signal processing tasks is limited to the architectural trade-offs that the processor architect made. If the trade-offs that were made match the needs for the project it is being used in, then all is well, but any mismatch will affect the development team’s implementation options.

When is using the single instruction stream benefit of a DSC or hybrid architecture better than using the multiple instruction stream approach of multiple and different types of processors in a design? Have you made this trade-off decision with any of your designs? When did you choose one over the other and why?

Boosting energy efficiency – Sleeping and waking

Friday, March 18th, 2011 by Oyvind Janbu

While using a 32-bit processor can enable a microcontroller to stay in a deep-sleep mode for longer, there is nevertheless some baseline power consumption which can significantly influence the overall energy budget. However, historically 32-bit processors have admittedly not been available with useful sub-µA standby modes. With the introduction of power efficient 32-bit architectures, the standby options are now complementing the reduced processing and active time.

With the relatively low power consumption many microcontrollers exhibit in deep sleep, the functionality they provide in these modes is often very limited.  Since applications often require features such as real time counters, power-on reset / brown-out detection or UART reception to be enabled at all times, many microcontroller systems are prevented from ever entering deep sleep since such basic features are only available in an active run mode.  Many microcontroller solutions also have limited SRAM and CPU state retention in sub-µA standby modes, if at all.  Other solutions need to turn-off or duty-cycle brown-out and power-on reset detectors in order to save power.

In the pursuit of energy efficiency then microcontrollers need to provide product designers with a choice a sleep modes offering the flexibility to scale basic resources, and thereby the power consumption, in several defined levels or energy modes.  While energy modes constitute a coarse division of basic resources, additional fine-grained tuning of resources within each energy mode should also be able to be implemented by enabling / disabling individual peripheral functions.

There’s little point though in offering a microcontroller with tremendous sleep mode energy consumption if its energy efficiency gains are lost due to the time it takes for the microcontroller to wake up and enter run mode.

When a microcontroller goes from a deep sleep state, where the oscillators are disabled, to an active state, there is always a wake-up period, where the processor must wait for the oscillators to stabilize before starting to execute code.  Since no processing can be done during this period of time, the energy spent while waking up is wasted energy, and so reducing the wake-up time is important to reduce overall energy consumption.

Furthermore, microcontroller applications impose real time demands which often mean that the wake-up time must be kept to a minimum to enable the microcontroller to respond to an event within a set period of time.  Because the latency demanded by many applications is lower than the wake-up time of many existing microcontrollers, the device is often inhibited from going into deep sleep at all – not a very good solution for energy sensitive applications.

A beneficial solution would be to use a very fast RC oscillator that instantly wakes up the CPU and then optionally transfers the clock source to a crystal oscillator if needed. This meets both the real time demands as well as encourages run- and sleep mode duty cycling. Albeit the RC oscillator is not as accurate as a crystal oscillator, the RC oscillator is sufficient as the CPUs clock source during crystal start-up.

We know that getting back to sleep mode is key to saving energy. Therefore the CPU should preferably use a high clock frequency to solve its tasks more quickly and efficiently.  Even if the higher frequency at first appears to require more power, the advantage is a system that is able to return to low power modes in a fraction of the time.

Peripherals however might not need to run at the CPU’s clock frequency.  One solution to this conundrum is to pre-scale the clock to the core and peripherals, thereby ensuring the dynamic power consumption of the different parts is kept to a minimum.  If the peripherals can further operate without the supervision of the CPU, we realize that a flexible clocking system is a vital requirement for energy efficient microcontrollers.

The obvious way for microcontrollers to use less energy is to allow the CPU to stay asleep while the peripherals are active, and so the development of peripherals that can operate with minimum or no intervention from the CPU is another worthy consideration for microcontroller designers.  When peripherals look after themselves, the CPU can either solve other high level tasks or simply fall asleep, saving energy either way.

With advanced sequence programming, routines for operating peripherals previously controlled by the CPU can be handled by the peripherals themselves.  The use of a DMA controller provides a pragmatic approach to autonomous peripheral operation.  Helping to offload CPU workload to peripherals, a flexible DMA controller can effectively handle data transfers between memory and communication or data processing interfaces.

Of course there’s little point in using autonomous peripherals to relieve the burden of the CPU if they’re energy hungry.  Microcontroller makers also need to closely consider the energy consumption of peripherals such as serial communication interfaces, data encryption/decryption engines, display drivers and radio communication peripherals.  All peripherals must be efficiently implemented and optimized for energy consumption in order to fulfill the application’s need for a low system level energy consumption.

Taking the autonomy ideal a step further, the introduction of additional programmable interconnect structures into a microcontroller enable peripherals to talk to peripherals without the intervention of the CPU, thereby reducing energy consumption even further.  A typical example of a peripheral talking to another peripheral would be an ADC conversion periodically triggered by a timer. A flexible peripheral interconnect allows direct hardware interaction between such peripherals, solving the task while the CPU is in its deepest sleep state.

The third part of this three part article explores the tools and techniques available for energy debugging.

Boosting energy efficiency – How microcontrollers need to evolve

Monday, February 21st, 2011 by Oyvind Janbu

Whatever the end product, all designers have specific tasks to solve and their solutions will be influenced by the resources that are available and the constraints of cost, time, physical size and technology choice.  At the heart of many a good product, the ubiquitous microcontroller often has a crucial influence on system power design and particularly in a brave new world that’s concerned with energy efficiency, users are entitled to demand a greater service from them.  The way microcontrollers are built and operate needs to evolve dramatically if it is to achieve the best possible performance from limited battery resources.

Bearing in mind that the cost of even a typical coin cell battery can be relatively high compared to that of a microcontroller, there are obvious advantages in designing a system that offers the best possible energy efficiency.  It can enable designers to reduce the cost and size of a battery.  Secondly, it can enable designers to significantly extend the lifetime of a battery, consequently reducing the frequency of battery replacement and for certain products the frequency, cost and ‘carbon footprint’ associated with product maintenance call-outs.

Microcontrollers, like many other breeds of electronic components, are these days very keen to stress their ‘ultra low power’ credentials, which is perfectly fine and appropriate where a device’s dynamic performance merits; however, with a finite amount of charge available from a battery cell, it is how a microcontroller uses energy (i.e. power over the full extent of time), that needs to be more closely borne in mind.

Microcontroller applications improve their energy efficiency by operating in several states – most notably active and sleep modes that consume different amounts of energy.

Product designers need to minimize the product of current and time over all phases of microcontroller operation, throughout both active and sleep periods (Figure 1). Not only does every microamp count, but so does every microsecond that every function takes.  This relationship between amperage and time makes the comparison of 8-, and 16-bit microcontrollers with 32-bit microcontrollers less straightforward. Considering alone their current consumption characteristics in a deep-sleep mode, it is easy to understand why 8-bit or 16-bit microcontrollers have been in an attractive position in energy sensitive applications, where microcontroller duty cycles can be very low.  A microcontroller may after all stay in a deep sleep state for perhaps 99% of the time.

However, if product designers are concerned with every microamp and microsecond every function takes, then using a 32-bit microcontroller should be being considered for even in the ‘simplest’ of product designs.  The higher performance of 32-bit processors enables the microcontroller to finish tasks quicker so that they can spend more time in the low-power sleep modes, which lowers overall energy consumption.  32-bit microcontrollers are therefore not necessarily ‘application overkill’.

More than that though, even simple operations on 8-bit or 16-bit variables can need the services of a 32-bit processor if system energy usage goals are to be achieved.  By harnessing the full array of low-power design techniques available today, 32-bit cores can offer a variety of low-power modes with rapid wake-up times that areon par with 8-bit microcontrollers.

There is a common misconception that switching from an 8-bit microcontroller to a 32-bit microcontroller will result in bigger code size, which directly affects the cost and power consumption of end products.  This is borne of the fact that many people have the impression that 8-bit microcontrollers use 8-bit instructions and 32-bit microcontrollers use 32-bit instructions.  In reality, many instructions in 8-bit microcontrollers are 16-bit or 24-bit in length.

The ARM Cortex-M3 and Cortex-M0 processors are based on the Thumb-2 technology, which provides excellent code density.  Thumb-2 microcontrollers have 16-bit as well as 32-bit instructions, with the 32-bit instruction functionality a superset of the 16-bit version.  Typical output from a C compiler gives 90% 16-bit instructions. The 32-bit version would only be used when the operation cannot be performed with a 16-bit instruction.  As a result, most of the instructions in an ARM Cortex microcontroller program are 16-bits.  That’s smaller than many of the instructions in 8-bit microcontrollers, typically providing less compiled code from a 32-bit processor than 8- or 16-bit microcontrollers.

The second part in this three part series looks deeper at the issues around microcontroller sleep modes.

Considerations for 4-bit processing

Friday, December 10th, 2010 by Robert Cravotta

I recently posed a question of the week about who is using 4-bit processors and for what types of systems. At the same time, I contacted some of the companies that still offer 4-bit processors. In addition to the three companies that I identified as still offering 4-bit processors (Atmel, EM Microelectronics, and Epson), a few readers mentioned parts from NEC Electronics, Renesas, Samsung, and National. NEC Electronics and Renesas merged and Renesas Electronics America now sells the combined set of those company’s processor offerings.

These companies do not sell their 4-bit processors to the public developer community in the same way that 8-, 16-, and 32-bit processors are. Atmel and Epson told me their 4-bit lines support legacy systems. The Epson lines support most notably timepiece designs. I was able to speak with EM Microelectronics at length about their 4-bit processors and gained the following insights.

Programming 4-bit processors is performed in assembly language only. In fact, the development tools cost in the range of $10,000 and the company loans the tools to their developer clients rather than sell them. 4-bit processors are made for dedicated high volume products – such as the Gillette Fusion ProGlide. The 4-bit processors from EM Microelectronics are available only as ROM-based devices, and this somewhat limits the number of designs the company will support because the process to verify the mask sets is labor intensive. The company finds the designers that can make use of these processors – not the other way around. The company approaches a developer and works to demonstrate how the 4-bit device can provide differentiation to the developer’s design and end product.

The sweet spot for 4-bit processor designs are single battery applications that have a 10 year lifespan and where the device is active perhaps 1% of that time and in standby the other 99%. An interesting differentiator for 4-bit processors is that they can operate at 0.6V. This is a substantial advantage over the lowest power 8-bit processors which are still fighting over the 0.9 to 1.8V space. Also, 4-bit processors have been supporting energy harvesting designs since 1990 whereas 8- and 16-bit processor vendors are only within the last year or so beginning to offer development and demonstration kits for energy harvesting. These last two revelations strengthen my claim in “How low can 32-bit processors go” that smaller sized processors will reach lower price and energy thresholds years before the larger processors can feasibly support those same thresholds – and that time advantage is huge.

I speculate that there may be other 4-bit designs out there, but the people using them do not want anyone else to know about them. Think about it, would you want your competitor to know you were able to simplify the problem set to fit on such a small device? Let them think you are using a larger, more expensive (cost and energy) device and wonder how you are doing it.

What is your favorite debugging anecdote?

Wednesday, December 1st, 2010 by Robert Cravotta

We all know stories about how something went wrong during a project and how we or someone else was able to make a leap of logic that enabled them to solve the problem. However, I think the stories that stick with us through the years are the ones that imparted a longer term insight that goes beyond the actual problem we were trying to solve at the time. For example, I have shared two such stories from my days as a junior member of the technical staff.

One story centers around solving an intermittent problem that ultimately would have been completely avoided if the development team had been using a more robust version control process. The other story involves uncovering an unexpected behavior in a vision sensor that was uncovered only because the two junior engineers that were working with the sensor were encouraged to think beyond the immediate task they were assigned to do.

More than twenty years later, these two stories still leave me with two key insights that I find valuable to pass on to other people. In the version control story, I learned that robustness is not just doing things correctly, but involves implementing processes and mechanisms to be able to automatically self-audit the system. Ronald Reagan’s saying “Trust but verify” is true on so many levels. In the valuing uncertainty story, I learned that providing an appropriate amount of wiggle room in work assignments is an essential ingredient to creating opportunities to grow your team member’s skills and experience while improving the performance of the team.

I suspect we all have analogous stories and that when we share them with each other, we scale the value of our lessons learned that much more quickly. Do you have a memorable debugging anecdote? What was the key insight(s) you got out of it? Is it a story that grows in value and is worth passing on to other members in the embedded community? I look forward to seeing your story.

Are you, or would you consider, using a 4-bit microcontroller?

Wednesday, November 24th, 2010 by Robert Cravotta

Jack Ganssle recently asked me about 4-bit microcontrollers. He noted that there are no obvious 4-bit microcontrollers listed in the Embedded Processing Directory – but that is partly because there are so few of them that I “upgraded” them to the 8-bit listing a few years back. In all the years I have been doing the directory, this is the first time someone has asked about the 4-bitters.

I suspect the timing of Jack’s inquiry is related to his recent article “8 bits is dead” where he points out that the predicted death of 8-bit microcontrollers continues to be false – in fact, he predicts “that the golden age of 8 bits has not yet arisen. As prices head to zero, volumes will soar putting today’s numbers to shame.” I agree with him, the small end of the processing spectrum is loaded with potential and excitement, so much so that I started a series on extreme processing thresholds a few months ago to help define where the current state of the art for processing options is so that it is easier to identify when and how it shifts.

The timing of this inquiry also coincides with Axel Streicher’s article asking “Who said 16-bit is dead?” Axel makes a similar observation about 16-bit processors. I would have liked to have seen him point out that 16-bit architectures is also a sweet spot for DSC (digital signal controllers), especially because Freescale was one of the first companies to adopt the DSC naming. A DSC is a hybrid that combines architectural features of a microcontroller and a digital signal processor in a single execution engine.

A comment on Jack’s article suggested that this topic is the result of someone needing a topic for a deadline, but I beg to differ. There are changes in the processing market that constantly raise the question of whether 8- and 16-bitters will finally become extinct. The big change this year was the introduction of the Cortex-M0 – and this provided the impetus for me to revisit this same topic, albeit from a slightly different perspective, earlier this year when I asked “How low can 32 bits processors go?” I offer that a key advantage that smaller processors have over 32-bit processors is that they reach lower cost and energy thresholds several years before 32-bit processors can get there, so the exciting new stuff will be done on the smaller processors long before they are put on a 32-bit processor.

In contrast, the humble 4-bit gets even less to no attention than the 8- and 16-bitters – but the 4-bit microcontroller is not dead either. Epson just posted a new data sheet for a 4-bit microcontroller a few weeks ago (I am working to get them added to the Embedded Processing Directory now). The Epson 4-bitters are legacy devices that are used in time pieces. EM Microelectronics’ EM6607 is a 4-bit microcontroller; I currently have a call to them to clarify its status and find out what types of applications it is used in.You can still find information about Atmel’s MARC4 which the company manages out of their German offices and is not currently investing any new money into.

So to answer Jack’s question – no, 4-bit processors are not dead yet, and they might not die anytime soon. Are any of you using 4-bit processors in any shape or form? Would you consider using them? What types of processing characteristics define a 4-bitter’s sweet spot? Do you know of any other companies offering 4-bit processors or IP?