feature article
Subscribe Now

How To Succeed in the MCU Business Without Really Trying

Success Factors Aren’t Always Obvious

What does it take to be a successful microcontroller vendor? It’s a fair question—after all, big chip companies have billions of dollars riding on the outcome. Freescale, Microchip, Renesas, and a dozen other firms work very hard to make their MCUs more attractive than the other guy’s.

As an MCU user, what does it take to get your attention? Why do you choose one MCU over another, and why do you stay with that MCU (or abandon it for a competing chip) on the next project?

I recently had a conversation with an MCU vendor (which shall remain anonymous) that asked those very questions. Here’s what I told them, based on my own experience as a programmer and engineering manager, and what I’ve gleaned from years of research, surveys, questionnaires, and focus groups.

For starters, most MCU customers (i.e., programmers or hardware engineers) are looking for longevity. They want to know that the chip they pick out will be in production for years and years. That’s a sharp contrast from the high-profile world of PC or workstation processors, where it’s important to always have the latest thing. In MCU-land, age and treachery beat youth and enthusiasm.

That’s why so many MCU vendors have enormous product catalogs with hundreds or even thousands of SKUs. Old chips never die, they just move to the back of the catalog. In reality, not all of those chips are actually in production, and, if you tried to buy 10,000 units of some obscure MCU, the vendor would likely tell you that the lead-time is six months or more. That’s code for, “please select a different part.”

As an MCU vendor, long-life parts are a double-edged sword. On one hand, you’ll have a steady source of income for years to come. Once a customer chooses MCU part #123-456, they’ll probably stick with it. As long as you don’t piss them off too badly, the customer will keep buying the same chip for years.

On the other hand, you can never discontinue any of your old chips. You can’t kill them off—or even update them significantly—without annoying your delightfully loyal customer base. That makes it tough to manage your production or inventory. The more new chips you design and build, the more you complicate your own business.

Another important factor for success is to have a long and clear upgrade path. Customers want to know that the chip, and the chip family, that they’ve chosen has plenty of headroom for growth. Nobody wants to buy the fastest chip in the product line; they want the slowest one, knowing they can upgrade down the road. Thus, it’s important to offer a few “overkill chips,” that are more powerful (and likely more expensive) than necessary, even if few customers will actually buy them. They prove that your MCU product line has room to grow.

The most important factor of all, however, has nothing to do with chips. It’s software. More and more each year, engineers and programmers are choosing MCUs based on the amount of software that comes with the chip. Features and functions and instruction sets are all secondary; middleware, drivers, and development tools are the key. The sizzle sells the steak, and the software is what sells the hardware.

As recently as a few years ago, the most important part of an MCU was the MCU. That’s changed. Now it’s the software that comes first. Developers choose their compiler (typically), and then choose an MCU that’s supported by the compiler. Or they’ll choose an RTOS, followed by a tool chain and then the MCU. The point is, the MCU no longer drives the choice of software. It’s the other way around. And the MCU with the “right” collection of software support will get the business. Of course, the definition of right changes with each customer.

For some, it’ll be the right middleware, like TCP/IP stacks, encryption algorithms, and network drivers. For others, slick user-interface software, real-time kernels, and in-memory databases will be important. Whatever chips offer these get fast-tracked to the top of the shopping list. Price, performance, peripherals, and pinout are all fading in importance.

Even instruction sets (that is, chip architectures) are less important these days. Few programmers write code in assembly language any more, even for low-cost MCUs. Every year that I surveyed programmers, the number of them still writing assembly-language code dwindled by another few percent, probably because they were reaching retirement age (or dying). In their place, new programmers use C or C++ almost exclusively, even for low-level code. Instruction sets are an abstraction to most of today’s MCU programmers. They’re “multilingual” and simply don’t care what instruction set their chip uses. C source code looks the same either way.

Paradoxically, this has made the popular MCU instruction sets even more popular. ARM and MIPS, for example, have both made inroads into the 16-bit and low-end 32-bit MCU markets and are getting more popular by the minute. Why would this happen if programmers don’t care about chip architecture? Because even if they don’t, third-party software companies do. The more software that’s available for ARM- or MIPS-based chips, the more popular those chips become. And that popularity breeds more popularity, and so on. It’s not the instruction set, per se, that developers care about. It’s the wealth of third-party tools, middleware, and operating systems that drives the attraction. Those MCUs could be powered by a hamster in a treadmill for all most developers care. The chip is just a means to an end.

So for a budding MCU vendor, building a better mousetrap means focusing on the cheese. No matter how clever or efficient your MCU chips, nobody will buy them unless they come baited with a tasty selection of third-party software offerings. You can develop that code in-house, outsource it to contract programmers, or pay subsidies to independent third-party software companies—it doesn’t matter, just as long as you do it. Mostly likely, you’ll need to do all three, and then be prepared to wait 2–5 years for that largesse to bear fruit. In a very real sense, the fate of every MCU maker is in the hands of its software partners. Be nice to your programmers. You may need them some day. 

Leave a Reply

featured blogs
Nov 24, 2020
In our last Knowledge Booster Blog , we introduced you to some tips and tricks for the optimal use of the Virtuoso ADE Product Suite . W e are now happy to present you with some further news from our... [[ Click on the title to access the full blog on the Cadence Community s...
Nov 23, 2020
It'€™s been a long time since I performed Karnaugh map minimizations by hand. As a result, on my first pass, I missed a couple of obvious optimizations....
Nov 23, 2020
Readers of the Samtec blog know we are always talking about next-gen speed. Current channels rates are running at 56 Gbps PAM4. However, system designers are starting to look at 112 Gbps PAM4 data rates. Intuition would say that bleeding edge data rates like 112 Gbps PAM4 onl...
Nov 20, 2020
[From the last episode: We looked at neuromorphic machine learning, which is intended to act more like the brain does.] Our last topic to cover on learning (ML) is about training. We talked about supervised learning, which means we'€™re training a model based on a bunch of ...

featured video

AI SoC Chats: Protecting Data with Security IP

Sponsored by Synopsys

Understand the threat profiles and security trends for AI SoC applications, including how laws and regulations are changing to protect the private information and data of users. Secure boot, secure debug, and secure communication for neural network engines is critical. Learn how DesignWare Security IP and Hardware Root of Trust can help designers create a secure enclave on the SoC and update software remotely.

Click here for more information about Security IP

featured paper

Reducing Radiated EMI

Sponsored by Maxim Integrated

This application note explains how to reduce the radiated EMI emission in the MAX38643 nanopower buck converter. It also explains the sources of EMI noise, and provides a few simple methods to reduce the radiated EMI and make the MAX38643 buck converter compliant to the CISPR32 standard Class B limit.

Click here to download the whitepaper

Featured Chalk Talk

Digi Remote Manager

Sponsored by Mouser Electronics and Digi

With the complexity of today’s networks, the proliferation of IoT, and the increase in remote access requirements, remote management is going from “nice to have” to “critical” in network design and deployment. In this episode of Chalk Talk, Amelia Dalton chats with Stefan Budricks of Digi International about how Digi Remote Manager can address your remote management and security needs.

Click here for more information about DIGI XBee® Tools