There’s no doubt that we’re living in an exciting era for embedded systems developers. Readers like you that design and develop embedded systems no longer have to compromise. Most of you probably remember when the processor or microcontroller you chose dictated both the development tools and embedded operating system (OS) you had to use. Today more than ever, there are all kinds of resources available to help you develop prototypes—everything from tools to chips to information resources on-line. There’s inexpensive computing modules available aimed at makers and DIY experts that are also useful for professional engineers working on high-volume end products.
The embedded operating systems market is one particular area where customers no longer have to compromise. That wasn’t always the case. Most people identify the late 90s with the dot.com bubble … and that bubble bursting. But closer to our industry was the embedded Linux start-up bubble. The embedded operating systems market began to see numerous start-ups appearing as “embedded Linux” companies. Since Linux is a free, open-source OS, these companies didn’t sell Linux, but rather provided services to help customers create and support implementations of open-source Linux. But, as often happens with disruptive technology, the establishment then pushed back. The establishment in that case were the commercial “non-open” embedded OS vendors. I recall a lot of great spirited debates at the time—both in print and live during panel discussions at industry trade shows—arguing for and against the very idea of embedded Linux. For my part, I can’t help remembering, having both written some of those articles and having sat on those panels myself.
Coinciding with the dot-com bubble bursting, the embedded Linux bubble burst as well. That’s not to say that embedded Linux lost any luster. It continued its upward rise, and remains an incredibly important technology today. Case in point: The Android OS is based on the Linux kernel. What burst was the bubble of embedded Linux start-up companies, from which only a handful of firms survived. What’s interesting is that all the major embedded OS companies shifted to a “let’s not beat them, let’s join them” approach to Linux. In other words, they now provide support for users to develop systems that use Linux alongside their commercial embedded operating systems.
The freedom not to have to compromise in your choices of tools, OSes and systems architectures—all that is a positive evolution for embedded system developers like you. But in my opinion, I think it’s possible to misinterpret the user-centric model and perhaps declare victory too soon. When you’re developing an embedded system aimed at a professional, commercial application, not everything can be done in DIY mode. There’s value in having the support of sophisticated technology vendors to help you develop and integrate your system. Today’s embedded systems routinely use millions of lines of code, and in most systems these days software running on a processor is what provides most of the functionality. If you develop that software in-house, you need high quality tools to makes sure it’s running error free. And if you out-source some of that embedded software, you have to be sure the vendor of that embedded software is providing a product you can rely on.
The situation is similar on the embedded board-level computing side. Yes, there’s a huge crop of low-cost embedded computer modules available to purchase these days. But not all embedded computing modules are created equal. If you’re developing a system with a long shelf life, what happens when the DRAMs, processors or I/O chips go end-of-life? Is it your problem? Or does the board vendor take on that burden? Have the boards been tested for vibration or temperature so that they can be used in the environment your application requires? You have to weigh the costs versus the kinds of support a vendor provides.
All in all, the trend toward a ”no compromises” situation for embedded systems developers is a huge win. But when you get beyond the DIY project level of development, it’s important to keep in mind that the vendor-customer relationship is still a critical part of the system design process. With all that in mind, it’s cool that we can today make a declaration of independence for embedded systems technology. But I’d rather think of it as a declaration of interdependence.
This appears in the October (327) issue of Circuit Cellar magazine
Not a Circuit Cellar subscriber? Don’t be left out! Sign up today: