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
May 25, 2023
Register only once to get access to all Cadence on-demand webinars. Unstructured meshing can be automated for much of the mesh generation process, saving significant engineering time and cost. However, controlling numerical errors resulting from the discrete mesh requires ada...
May 24, 2023
Accelerate vision transformer models and convolutional neural networks for AI vision systems with the ARC NPX6 NPU IP, the best processor for edge AI devices. The post Designing Smarter Edge AI Devices with the Award-Winning Synopsys ARC NPX6 NPU IP appeared first on New Hor...
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

Synopsys Solution for RTL to Signoff Power Analysis

Sponsored by Synopsys

Synopsys’ industry-leading power analysis solution built on PrimePower technology that enables early RTL exploration, low power implementation and power signoff for design of energy-efficient SoCs.

Learn more about Synopsys’ Energy-Efficient SoCs Solutions

featured contest

Join the AI Generated Open-Source Silicon Design Challenge

Sponsored by Efabless

Get your AI-generated design manufactured ($9,750 value)! Enter the E-fabless open-source silicon design challenge. Use generative AI to create Verilog from natural language prompts, then implement your design using the Efabless chipIgnite platform - including an SoC template (Caravel) providing rapid chip-level integration, and an open-source RTL-to-GDS digital design flow (OpenLane). The winner gets their design manufactured by eFabless. Hurry, though - deadline is June 2!

Click here to enter!

featured chalk talk

Product Blocked by Supply Chain Woes? Digi XBee® RR to the Rescue!
Sponsored by Mouser Electronics and Digi
In this episode of Chalk Talk, Amelia Dalton and Quinn Jones from Digi investigate the benefits that the Digi XBee RR wireless modules can bring to your next design. We also take a closer look at the migration path from Digi XBee 3 to XBee RR, the design aspects you should keep in mind when moving from the Digi XBee 3 to the RR and how the Digi XBee Multi-programmer can help you get exactly the configuration you need in your next design.
Feb 1, 2023
14,854 views