8-bit Microcontrollers Remain a Leading Choice Thanks to Cooperative Processing

Just over 40 years ago, the first 8-bit microcontroller appeared was released to the market. Engineers quickly saw the advantages it brought. As a single device that contained a full microprocessor, memory, timer and I/O ports, it greatly simplified the bill of materials (BoM) and design of many electronic products. The microcontroller soon found its way into computer keyboards while derivatives and competitors spread into a huge number of embedded systems in the following decades.

Although microcontroller manufacturers have since introduced devices based on 16-, 32- and even 64-bit architectures, the 8-bit architecture continues to have a strong role in embedded systems. Today, 8-bit microcontrollers are used for a broad range of applications. In many cases, the 8-bit microcontroller is the only software-programmed device in the system. Smoke alarms and industrial sensor modules are key examples. Alternatively, one or more 8-bit microcontrollers are used alongside other processors based on 16-, 32- or 64-bit architectures. Those keyboard controllers were examples of the latter: smart peripherals that made the job of the computer’s host processor much easier. It no longer had to consume many cycles debouncing and scanning input lines. The use of multiple cooperating components in this example improved overall performance. In today’s microcontrollers, a similar concept is used in which multiple cooperating components work alongside each other to improve overall performance.
When faced with a new product concept that calls for embedded processor-based control, the designer needs to consider how the workload can best be split across resources. It may be a relatively complex system that uses a combination of different processors such as a smart speaker. Alternatively, the systems may be much simpler, such a home smoke alarm that can function with all its software running on an 8-bit microcontroller. In either case, cost effectiveness and energy efficiency are vital considerations and will steer the designer towards an architecture that is not simply to employ a single software-driven processor.
The simplest approach from a hardware perspective may seem to be to use an operating system to allow many different tasks to coexist on one high-performance processor. But this is almost always not an energy-efficient approach, because data exchange between the system and its inputs and outputs often takes place at a much lower rate than the peak pipeline throughput of a high-end processor. While I/O transactions are performed, a 32-bit or 64-bit processor capable of running at 1GHz or more has to wait many cycles for each new byte or word to appear. One way to avoid polling constantly is to use interrupts. This lets the processor continue with core work while each I/O transaction is in flight. But the need to push and pop values onto the system stack with each context switch incurs many cycles of overhead after each interrupt.
Interrupts from external events drive many embedded systems. They wait for some signal of outside activity before performing intensive processing on the inputs. As a result dealing efficiently with their overhead is essential. It was as true of the keyboard controllers of the late 1970s as it is today. Instead of polling for inputs constantly, they could wait for an electrical contact to be made. The resulting pulse would be sensed by an interrupt controller that would signal to the microprocessor’s firmware that it needs to scan the keypad lines to detect which key had been pressed and send a message to the host computer regarding which character it represents.

For most of its working life, a typical IoT system will do very little processing; most of its functions are needed only during short bursts of activity. A smart speaker, for example, only needs to start to try to recognise human speech when a strong enough audio signal in the right frequency range is picked up by the microphone.
For example, a smoke alarm does not need to perform measurements on the air that enters its chamber at microsecond intervals. The environment does not change quickly enough to require it. The alarm can use sampling at a rate of once every second or lower to determine whether air quality is at a level where it needs to analyse the results more carefully. The calculations will generally take a fraction of a second even on cores running at low megahertz rates. In both cases, keeping the processor core running between measurements in an idle loop will waste energy. The solution is to put the core into a low-power sleep mode when it enters the idle loop and to wake it when an interrupt arrives from a system clock or counter, or if an event-driven peripheral detects external activity.
To maintain high performance, high-end processors make use of local SRAM caches to store frequently accessed instructions and data. If caches are not used, they need to copy code from relatively slow flash memory into SRAM or DRAM to maintain good instruction throughput of caches. To save power during sleep, these memories will lose their contents and need to be refreshed after a wakeup signal before the processor can begin execution, which takes energy and adds latency.
Most 8-bit processors are better matched to the performance and capabilities of non-volatile memory, loading instructions from flash directly. They often contain local non-volatile data memories to store persistent data between wakeup cycles and thus rarely need to reload their SRAM scratchpads. The result is a core that is more responsive to external events, despite lower peak computation throughput.
As a result, system designers often favour using 8-bit microcontrollers alongside 16-, 32- or 64-bit processors in more complex systems to perform event-handling logic in a more power- and compute-efficient manner. In a smart speaker, an 8-bit microcontroller can be used to handle audio inputs when there is no need to process speech. It can run simple algorithms to first determine whether the incoming sound is above background levels and then whether it appears to be noise or has characteristics consistent with human speech. If the signal seems to be important enough, it can wake up the primary processor for further analysis.
The cooperative-processing architecture does not stop at the processor core. There are often situations where the flexibility of software execution is not required to handle a large proportion of the external event the system detects. For example, in the case of the smart speaker, the processor does not need to determine if an incoming sound has speech characteristics if the microphone is only picking up low-level background noise. Core Independent Peripherals (CIPs) can perform functions independently of the processor core, such as comparisons of analogue inputs with reference levels. For example, if the amplitude of the signal received by the microphone exceeds a threshold analysed by a comparator it can wake up the processor.

Figure 1 – Core Independent Peripherals

Depending on the microcontroller part, CIPs provide a range of configurable intelligent peripherals that implement combinational logic, state and clocking functions that can be combined to implement motor control, power sequencing, data modulation and conditional signaling without direct interventions from the processor core. Devices such as the ATmega4809, which offer configurable custom logic (CCL) controllers, the on-chip ADC can be provided with programmable triggers and other state-driven functions that offload additional tasks from the processor core.
In the case of the ADC2 module found on a number of Microchip’s 8-bit microcontrollers, such as the PIC16F18446, the hardware can perform signal-processing functions on digitised signals, such as averaging and low-pass filtering. This prevents the system from reacting to short-term noise and audible glitches, as well as providing useful preprocessing for when the signal received by the ADC needs to be evaluated for speech content. Hardware features are also incorporated in the ADC2 to simplify capacitive sensing in touch panels, another application where traditionally a high degree of software processing has been required.

Figure 2 – PIC16F18446 Block Diagram

The overall impact of the programmable hardware peripherals is not just to save energy by allowing the processor core to stay longer in sleep mode. The additional processing helps cut BoM costs in standalone applications, such as alarms, without sacrificing functionality. The support for hardware-based filtering in the case of devices that contain an ADC2 module makes it possible to substitute an 8-bit microcontroller where, traditionally, a 16-bit part might initially seem the most appropriate choice. At typical resolutions for industrial and audio samples, the 16-bit architecture does not require that the sample data is split for processing in software in the way that an 8-bit pipeline would require. However, having functions such as filtering performed in hardware offloads the 8-bit processor core from a significant amount of signal-processing work, letting it focus on system-level management and control. The increased processing headroom can make it possible to specify lower-cost 8-bit devices for simpler end equipment.
Microcontrollers based on an 8-bit architecture are better matched to I/O-focused, event-driven applications in other ways. Many digital-I/O tasks operate at the bit and sub-byte level. Processors with wider word widths tend to be less efficient at handling these data types, requiring the movement of entire words of data to and from registers and the use of complex bit masks to manipulate the right contents. Designed for functions such as debouncing a button input or producing PWM signals to drive motors, lighting circuits and power supplies, 8-bit microcontrollers provide the right level of functionality for applications that do not require a large number of calculations to be made in between each step.
For I/O-focused tasks, 8-bit microcontrollers are generally more efficient in their use of both program and data memory and so require less compared to products that use processors based on other architectures. In more complex applications, a larger amount of memory may be required and would justify the migration of code to a 16-bit or 32-bit device, which will typically be made on more highly scaled process to support the larger memory macro. The 8-bit architecture allows for the manufacture of parts on process that also support highly robust analogue and I/O circuits, offering better power handling, headroom, signal quality and resilience compared to parts that need more highly scaled silicon processes. In many cases, it may make sense to take account of the advantages of cooperative processing and silicon-process choices and split the workload across an application-focused 8-bit device and a general-purpose 16-bit or 32-bit processor.
The use of cooperative processing potentially increases design complexity as the developer needs to take account of synchronisation between multiple cooperating processor cores and smart peripherals. However, tools such as Microchip’s MPLAB Code Configurator (MCC) take care of the firmware-level management that is required, providing solutions that cater for many classes of applications, such as connectivity, motor control and power handling.

Figure 3 – MPLAB Code Configurator

The 8-bit architecture has been successful for decades. Observers may assume their design has remained static. But the microcontrollers based around these cores have adapted to demands of each new generation of product designer, adding features such as smart peripherals and support for high-level languages that are needed in the modern environment of cooperative intelligence.

By Lucio di Jasio, MCU8 Business Development Europe, Microchip Technology Inc.

www.microchip.com