Future Electronics – Why the best choice for upgrading an 8-bit MCU might be… another 8-bit MCU

pg22_TV

By Ian Fosberry
Field Applications Engineer, Future Electronics

The upgrade path for the user of a conventional 8-bit microcontroller which has reached the limit of its capabilities, and which cannot support the application’s requirement for more features and better performance, is in most cases assumed to be a 32-bit MCU. The 32-bit device will execute more complex code faster, enabling the designer to implement more sophisticated features and to improve performance. With 32-bit MCUs available at unit prices as low as $0.50, there might even be only a negligible impact on the system’s bill-of-materials cost in upgrading from an 8-bit MCU.

So obvious is the apparent superiority of the 32-bit MCU in terms of speed and performance that market watchers have, for some years, been predicting that sales of 8-bit MCUs will go into terminal decline and that most new designs will opt for the greater potential offered by 32-bit devices.

Those market watchers are still waiting for their prediction to come true. In fact, users of 8-bit MCUs are now as likely to discover scope for increased processor throughput and higher system performance in the latest generation of 8-bit MCUs as they are in low-cost 32-bit alternatives. And by sticking with an 8-bit processing platform, design engineers benefit from the use of familiar development tools and instruction sets and the potential to re-use existing application code, as well as the high-current capability and superior robustness of 8-bit devices.

This article describes the latest architecture of the market-leading family of 8-bit PIC® MCUs from Microchip, showing how it provides the effect of increasing CPU bandwidth without requiring an increase in bit width.

Architectural breakthrough in new-generation 8-bit MCUs
When a design engineer is considering upgrading a design from an 8-bit MCU to a 32-bit MCU, it is normally at least in part because the 8-bit MCU’s CPU is acting as a bottleneck, slowing down the running of application code and impairing the system’s ability to run real-time applications deterministically.

By implementing the design on an MCU with a 32-bit processor such as an Arm® Cortex®-M series core, this bottleneck is immediately removed, although the enhanced processing capability comes at the cost of higher power consumption and code complexity.

Migration to 32-bit computing, then, solves the bottleneck problem by dramatically widening the neck of the bottle: many more instructions are then able to pass through the CPU.

A different solution to the same problem is to create additional, parallel computing resources, dramatically reducing the number of instructions which have to pass through the 8-bit CPU bottleneck, while still supporting additional and more sophisticated functions and providing higher system performance. This is the solution now being offered by Microchip in its latest range of 8-bit PIC® MCUs.

The way it has achieved this is by creating an architecture consisting, as before, of a single 8-bit CPU, but now supplemented by a wide range of Core-Independent Peripherals (CIPs). Each CIP is a hardware resource which supports a fixed function. The functions that Microchip has chosen to support with CIPs are well matched to the typical 8-bit user’s requirements. They include an array of analogue capabilities, PWM and waveform generators, timers including an angular timer and charge time measurement, logic and math functions, monitoring functions, wired and wireless communication peripherals, touch sensing and display controller modules, and power-management peripherals.

Clearly, there will be some among the 8-bit user community who are implementing functions not provided by CIPs, and who will not be helped by the new architecture. But most mainstream 8-bit designs are catered for by the selection of CIPs available in new PIC® MCUs.

By ‘core-independent peripherals’, Microchip means hardware resources which run autonomously in the background, without needing to continually transmit interrupt signals to the CPU. By offloading functions to CIPs, the designer can reduce the processing burden on the CPU.

The way that CIPs might be used in practice can be illustrated through the example of a toaster – a classic 8-bit application. First, the components of the toaster’s switch-mode power supply can be assembled from CIPs, including:
• programmable switch-mode controller
• 10-bit or 16-bit PWM drivers
• high-speed comparators
• a DAC
• slope compensation

Since a toaster’s heating elements draw a high current, there is a risk of generating EMI, of causing clicks and pops, and of stressing system components when the toaster is turned on. An 8-bit PIC® MCU can eliminate this risk by implementing zero-voltage switching. Again the CIP components are available to implement this function: an analogue zero-crossing detection function is provided, and an angular timer can measure the intervals between zero-voltage points. This allows the designer to time the turn-on of the heating elements at a zero-crossing point, or at any chosen point between zero-voltage events.

What is more, the CIP line-up includes a high-current I/O, which is connected to a single pin protected by current-balancing circuitry. Providing an output of as much as 100mA, this high-current I/O is sufficient to fire an external triac to switch on the heating elements. Both the built-in zero-crossing detection function and the high-current I/O enable the designer to eliminate external components which would be required by other MCUs.

Implemented via a CIP, the zero-crossing detection function requires no optocoupler for isolation from the high mains voltage. And the high-current I/O eliminates the normal need for an external power transistor. This reduction in component requirements saves bill-of-material cost, assembly cost and board space.

In fact, the whole of the power-control circuit may be implemented inside an 8-bit PIC® MCU, and without any call on the CPU. All of these functions can be configured with an easy-to-use tool, the MPLAB® Code Configurator, a plug-in to Microchip’s MPLAB® X integrated development environment for PIC® MCUs. This tool is a graphical programming environment which generates C code for insertion into a product design’s code base. It greatly reduces the requirement for the designer to refer to the MCU’s datasheet, and reduces the time and effort involved in implementing peripherals in an 8-bit design.

Motor control is another application that is well served by CIPs. For instance, the math accelerator is a hardware version of a multiplier; it can implement in eight CPU cycles a function that would require 520 cycles when implemented conventionally in software.

Another example of the way that CIPs can offload software-intensive tasks which would be implemented by the CPU in a conventional 8-bit MCU is the automatic adjustment of an LCD display’s brightness in response to the intensity of ambient light. In a conventional MCU architecture, this task reads the input from an external ambient light sensor, calculates the appropriate pixel brightness, and then refreshes the pixel-control signal with an updated current value. This approach requires the execution of a complex control routine in the CPU, as shown in Figure 1.

pg22_TV-fig1

Fig. 1: A complex state machine implemented in software requires intensive processor operation

In the new 8-bit PIC® MCU architecture, however, much of this work can instead be implemented by a type of CIP called a ‘configurable logic cell’, as shown in Figure 2. Again the MPLAB Code Configurator is used to configure this peripheral as any of a limited selection of logic functions such as AND, OR, NAND and NOR gates and flip-flops. A serial peripheral interface – another CIP – connects the CPU to the configurable logic cell, and a PWM driver – a third CIP – provides for current regulation, as shown in Figure 3.

pg22_TV-fig2

Fig. 2: A simple pixel control circuit based on a configurable logic cell replaces a function which would typically be implemented in firmware in a conventional MCU design

Implemented conventionally in software, as illustrated in Figure 1, this circuit consumes the entire bandwidth of a processor operating at a high clock speed, and is likely to exceed the capability even of a microcontroller based on the 32-bit Arm® Cortex®-M0+ core. Using CIPs, the burden on the CPU is almost entirely eliminated, leaving it free to perform other system tasks, and allowing operation at a low core clock speed with a slower oscillator, resulting in reduced power and cost.

Fig. 3: This simple implementation reduces the burden on the CPU to just a single instruction for each refresh cycle

Fig. 3: This simple implementation reduces the burden on the CPU to just a single instruction for each refresh cycle

Opportunity to adopt a new approach to system implementation
The examples described above show that a dramatic reduction in CPU overhead can be achieved by implementing substantial elements of an application in CIP hardware, rather than as software routines running in the CPU. This in effect produces an increase in the CPU’s bandwidth, but without the need to migrate the entire design to a new 32-bit platform.

Clearly this calls for a new approach to the implementation of system designs, requiring the designer to work out those elements of the application which can best be implemented in CIPs, with the least possible call on the CPU. This new method of implementing typical 8-bit functions is made considerably easier than it might be by the availability of the MPLAB Code Configurator, which is intuitive and provides great time savings in practice.

Designers who are prepared to adopt this new approach will be able to introduce new features into existing end-product designs and to improve their performance without the upheaval entailed in moving to a 32-bit device. They will also enjoy consequent savings in power consumption and cost.

Once again, the 8-bit MCU shows that it has plenty of life left in it.