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.
