Few 8-bit microcontroller (MCU) users actively want to go through the experience of migrating a design to a 32-bit processing platform. The drawbacks of migration are, by general consensus, painful.

But the pain can be borne because a 32-bit MCU offers so much scope to add features and value to an end product, and to improve its performance.

A 32-bit MCU will offer a higher operating frequency and a more powerful instruction set, resulting in a huge increase in processing throughput and the capability to address much more memory.

However attached a design team is to its 8-bit MCU, when it reaches the limit of its capabilities, there is no choice but to implement next-generation designs on a wholly new platform.

In the migration to a conventional 32-bit MCU, most 8-bit users will encounter at least four types of pain.

But what if a designer chooses not to follow the conventional route? This article describes the four most common types of pain and proposes a way to mitigate them using a different type of MCU – a programmable system-on-chip device, such as the PSoC range from Cypress Semiconductor.

 

Pain 1: pin assignment and board layout

Some chip manufacturers which have both 8-bit and 32-bit MCUs in their product line-up have gone to great lengths to try to match the pin-out of their low-end 32-bit devices to that of their high-end 8-bit devices.

Additionally, legacy 8-bit MCUs did not always maintain a consistent approach to pinning, so a 32-bit MCU pin-out compatible with one 8-bit part might well be incompatible with the pin-outs of other 8-bit parts.

In practice, the attempt to match one set of fixed-function pin-outs with another set of fixed-function pin-outs has enjoyed only partial success at best. Changing the output pins also creates an extensive amount of additional work, making it far less attractive for customers to embark on the migration process.

Alternatively, a programmable interconnect scheme and programmable pin-out is entirely flexible. Its overall layout can be capped, as the pin-outs are not fixed and can be configured by the user to match key signals from any legacy pin-out. This can offer an advantage in design projects in which a part of a legacy board layout is to be re-used.

For instance, a system design team might have made a habit of routing sensitive signal lines on the left-hand side of the board and power-supply lines on the right-hand side. The fixed-function pin-out of a conventional MCU might make it impossible to sustain this habit in the migration to a 32-bit controller, but a programmable pin assignments enable existing design rules to be followed.

 

Pain 2: coding, timing and debugging

A design engineer will often choose to migrate to a 32-bit platform to take advantage of the power, providing more features and, in return, the ability to run more complex application software.

At the same time, this is one of the biggest sources of pain in the migration process. Complex software can be hard and time-consuming to write, particularly if it requires the use of a new development tool suite. What’s more, the conventional model of 32-bit MCU operation calls for multiple dumb peripherals – sensors, user input devices, communications interface, pulse width modulators (PWMs) and so on – to route their signals through a single processor core, which processes them in sequence at very high speed, makes a decision and fires out an instruction or signal to another dumb peripheral.

The more inputs that are funnelled through the central processing unit (CPU), the harder it becomes to guarantee timing and determinism, and the more vulnerable the system’s operation is to bugs, so more time and effort have to be devoted to detailed debugging.

The operation of a PSoC device follows a fundamentally different model. Instead of multiple dumb peripherals fighting for a share of a single processor’s time, the device’s smart peripherals can operate independently of the CPU.
This applies to many functional blocks. Bit-banging functions, such as  custom communication interfaces or encodings, for example, can be implemented this way with no intervention necessary on the part of the CPU.

Programmable analogue blocks and an analogue multiplexer capability also enable entire applications to be built without calling on the CPU.

 

Pain 3: power consumption

Operating at higher clock frequencies and supporting larger memories and more peripherals, 32-bit MCUs inevitably consume more power than 8-bit MCUs. In MCUs based on an ARM Cortex-M core, the biggest single power consumer is the ARM Cortex-M core.

As described above, functions in a conventional 32-bit MCU require the operation of the core. By contrast, the core is a resource which is only used when it is most appropriate to do so in a PSoC device. When functions are implemented in the UDBs or programmable analogue blocks, the core may be left in power-down mode, enabling low power consumption while retaining essential functionality.

 

Pain 4: hardware complexity

The fixed architecture of conventional 32-bit MCUs imposes a strict set of rules and conditions governing the operation of the many peripheral devices that they support. The application of these rules entails the detailed study of the device’s datasheet, which typically runs hundreds of pages.

By contrast, PSoC devices implement a modular design approach using graphical design tool. An application may be constructed by dragging and dropping components such as PWMs, clocks, DACs and ADCs on to the tool’s virtual ‘whiteboard,’ connecting them by drawing wires between them and then assigning them to user-defined pins.

Raul Hernandez Arthur, Product Marketing Manager, Cypress Semiconductor