My two-cents about embedded MCU evolution - Embedded.com

My two-cents about embedded MCU evolution

In the debate on Embedded.com in recent weeks over the future of 8-, 16-, and 32-bit MCUs too much attention has been focused on practical bottom-line and profit margin considerations and not enough on intangible issues such as the continuing contribution of 8- and 16-bit devices in new market segments and their role in introducing beginning engineering and programming students to embedded systems design.

For now, as recent white papers, webinars and design articles on Embedded.com indicate, MCU opportunities in all bit widths – 8-, 16- and 32-bit – are still thriving.. Some recent submissions that demonstrate the current dynamic nature of the MCU market are:

A standard peripherals approach to adding flexibility to 32-bit MCU designs
KESO: A Java VM an MCU developer could love?
Microchip’s new analog-ish part

But, in his recent column Is 8 bits dying? ”, Jack Ganssle comments that there are indications that a shakeout is coming, but that it will not be as soon as Michael Barr asserts in “Trends in embedded Software . ” While admitting that 8-bit devices might be eventually be replaced, Jack raises a number of solid technical reasons why that might not be happening soon. If anything, according to Atmel’s Andreas Eieland in “8- to 32-bit MCUs: app use is removing the In-Between ,” it is the 16-bit MCU that may be first to go.

Given the nature of the connected environment within which embedded devices must operate, 8- and 16-bit MCUs should not be counted out, despite the naysayers. 32-bit MCU vendors are focused on the here-and-now commercial opportunities in markets such as industrial and machine control, automotive, and white goods appliances.

Not as much attention is being paid to the more leading edge, still to be commercialized apps that represent the future, such as the 6LoWPAN and wireless Internet of Things. In an informal survey I did recently of about 100 IoT papers, 8- and 16-bit MCUs outnumbered 32-bit designs by a ratio of at least 10 to 1. A few of the more interesting are:

Internet-of-things in remote-controlled laboratories (PDF)
Using and operating wireless sensor network testbeds (PDF)
Internet protocol over wireless sensor networks (PDF)

I also do not think the 32-bit takeover enthusiasts take into account what is going on in the universities and technical institutes around the world, where as a recent paper titled “Improving the effectiveness of microcontroller education (PDF),“ recounts, the mainstay of many introductory classes in embedded systems still remains 8-bit platforms. The reason is not just lower cost. Instructors also find that an 8-bit platform is the best way to get their engineering and computer science students quickly into the guts of embedded development on projects that can be completed within a semester or two and go on to create projects in a wide range of leading edge applications. Some specific recent illustrations include:

A platform for teaching embedded programming (PDF)
A microcontroller course for a mixed student body (PDF)
Teaching platforms for lessons in embedded systems programming (PDF)

From a practical business point of view, declining profit margins on 8- and 16-bit devices are forcing some MCU vendors to withdraw from the market, leading Jack to be concerned about – – and Barr to predict – their demise.

While shifting efforts to higher margin 32-bit designs makes short term business sense, it is killing the goose that lays the golden eggs, because it cuts vendors off from a segment of the market where the innovation in some leading edge applications is growing. One only need look at the popularity of platforms such as the Atmel AVR-based Aurdino 8-bit MCU development boards i n the do-it-yourself electronics and university communities to see some examples of this:

Providing user support in web-of-things enabled smart spaces (PDF)
Middleware for intelligent environments and the internet of things (PDF)
A generic sensor platform for the web of things (PDF)

The popularity of 8-bit devices on platforms such as Arduino is due in part to their low cost and building block approach. Currently the Atmel 8-bit AVR/ATMega MCU based Arduino platform has about a dozen basic board level components built around a common set of standardized connectors, as well as another dozen or so boards that are Arduino-compatible. This makes it possible for an engineering student, a domain/ algorithm specialist who does not want to get stuck for months in implementation details, or a DIY “domain enthusiast” to translate his ideas as quickly into a working – or almost working – prototype.

Numerous MCU vendors have recognized this, and in addition to coming up with their own standardized development platforms, have also tried to ride on the popularity of the Arduino platforms in the form of various “duino” look-a-likes for 8- and 16-bit MCUs from Microchip and Freescale, among others.

Hoping to take advantage of the popularity of the platform amongst DIYers, university students and their teachers, a number of 32-bit MCU “duino” boards are also available. I do not expect these efforts to be successful, for while the well-thought out modular construction of the Arduino platform allows a relatively inexperienced developer to get a hardware prototype ready quickly, it is the programming of the MCUs that is the key to success.

Speaking from personal experience with 8 bit CISC MCUs such as the 8008, 8048, and 6800,  at a time when assembly level programming and limited tool support was the norm, and later with more regularized RISC designs that supported C programming, 8-bit devices do not require the level of education, time, and effort to develop and debug that more complex 32-bit processors do.

32-bit MCUs have been aggressively promoted for the range of functions they provide and the variety of high level design tools that allow a developer to create the code and debug it. But with larger instruction sets, more choices and more flexibility comes complexity and with complexity come more chances to make mistakes and more effort – and investment in tools – to debug a design and get it right.

By their very design 8-bit MCUs have instruction sets that are more limited but much more comprehensible and more debugable, especially with the shift to RISC architectures and a variety of low cost testing and debugging tools. If an eager “domain enthusiast” has the motivation of an idea that excites him or her, coming up with a proof of concept design is achievable.

But what if the design is such that it requires more than the resources of a single 8-bit MCU? From some of the DIY and student applications I have seen, nothing has prevented them from partitioning the design such that it can be built with multiple 8-bit MCUs.

Before you object that this is not practical in commercial designs, if it achieves the design goals, how is this different from the dilemma faced by developers when making up their minds about whether to shift from designs with multiple CPUs to ones based on a single chip, multiple processor core architecture? For the last several years, the annual UBM Electronics Embedded Market survey has indicated that the majority of respondents – about 62-67 percent – use two or more discrete MCUs in a typical design, but only 11-15% have committed to designs with multiple processors on a single chip.

If 32-bit architectures such as ARM are successful in killing off commercial 8- and 16-bit MCUs, Jack Ganssle’s prediction is that “ARM’s biggest competitor is the one that doesn’t exist yet: a royalty-free open-source CPU supplied with all of the design support ARM provides. ” I think that something similar will happen in the 8- and 16-bit market: if not a new open source RISC design, maybe the rebirth of one of those abandoned low-margin 8-bit or 16-bit MCUs as an open platform. For the sake of the innovation that 8 bit – and 16-bit – developers bring to embedded systems design, I think we had better hope that is the case.

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.

See more articles and column like this one on Embedded.com.Sign up for s ubscriptions and newsletters . Copyright © 2012 UBM–All rights reserved.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.