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
Aug 15, 2018
https://youtu.be/6a0znbVfFJk \ Coming from the Cadence parking lot (camera Sean) Monday: Jobs: Farmer, Baker Tuesday: Jobs: Printer, Chocolate Maker Wednesday: Jobs: Programmer, Caver Thursday: Jobs: Some Lessons Learned Friday: Jobs: Five Lessons www.breakfastbytes.com Sign ...
Aug 15, 2018
VITA 57.4 FMC+ Standard As an ANSI/VITA member, Samtec supports the release of the new ANSI/VITA 57.4-2018 FPGA Mezzanine Card Plus Standard. VITA 57.4, also referred to as FMC+, expands upon the I/O capabilities defined in ANSI/VITA 57.1 FMC by adding two new connectors that...
Aug 15, 2018
The world recognizes the American healthcare system for its innovation in precision medicine, surgical techniques, medical devices, and drug development. But they'€™ve been slow to adopt 21st century t...
Aug 14, 2018
I worked at HP in Ft. Collins, Colorado back in the 1970s. It was a heady experience. We were designing and building early, pre-PC desktop computers and we owned the market back then. The division I worked for eventually migrated to 32-bit workstations, chased from the deskto...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...