The Graying of Embedded


  • Page 1 of 1
    Bookmark and Share

Embedded computing may be heading for some new territory. And success in that territory calls for new strategies and skills. Not that embedded will ever go away, of course. Once focused on unique application I/O and driven by desktop-derived or purpose-built processors, embedded was first swamped by commoditized x86 computing platforms and is now on the cusp of inundation by another consumer platform wave.

Production volumes for applied (a.k.a. embedded) computing are dominated today by long-lifecycle motherboards in kiosks, digital signage, point of sale terminals and the like. Simple adaptations of processor vendor reference designs fueled the Asian Invasion of embedded SBCs and modules at prices even below the bill of materials costs of small form factor (SFF) embedded computers from North American and European manufacturers. Hundreds of medical, industrial, transportation, energy and military system OEMs benefited from pervasive standards-based building blocks for their line-powered fixed always-on devices. Though the bulk of system implementation resources shifted toward software, validation and regulatory tasks, there are still a few unsung hardware heroes to give each system its unique application I/O capabilities.

Tablets and smartphones now threaten to claim a significant number of embedded system designs. We’ve become spoiled by the connectivity and convenience of these consumer and enterprise gadgets. Although still not suitable for applications requiring large-scale displays and high-end graphics, it’s hard to deny the economies of scale and overall utility of these lightweight ultra-portable gadgets for embedded applications. These rich open platforms are rapidly replacing purpose-built ruggedized user interface terminals for a variety of instruments and devices in all market segments. In other words, “there’s an app for that!”

How can the SFF supplier community capitalize on this trend? Clearly there is very little point in creating the design equivalent of a phone or tablet. Popular x86 and Intel Architecture processors are already available in every conceivable shape and size. So why not repurpose the same cookie cutter reference design recipe for ARM modules? There is already some momentum in this direction, although the breakout of hype versus substance is yet to be seen. Besides low power, if the salient point of using ARM is low cost, then why pay the overhead for COMs with baseboards when a college student can implement the reference design on a single board in a few weeks? The real challenge and cost lies with the software. It’s strange that x86 board vendors still need to learn what the RISC and microcontroller custom design community has known for decades.

Perhaps the SFF community is better off enhancing the connectivity of its x86 boards to these ARM-based consumer devices. Porting, testing and certifying operating systems and middleware stacks creates value in saving the system OEM time and money. Partnering or even merging with embedded software companies would lead to a differentiated value proposition. Multicore processors can run the GUI and OS on one core and real-time operating system (RTOS) on the other. System OEMs prefer suppliers who stand behind their offering rather than pointing the finger at a third party. Maybe the industry is ready for another wave of consolidation, this time involving hardware and software together rather than only one or the other. Is the term “solution” overused yet?

Before settling into a funk, keep in mind that there is still the core block of application-specific I/O functionality of the device to develop or upgrade. Just a few examples include controlling a laser or reading sensors, or capturing and compressing images, or taking a measurement, or monitoring a production process or other event-driven or real-time behavior. And for those design elements, system OEMs still need to rely upon the gray-haired or no-haired engineers among us. Those who remember that embedded development environments once consisted of scopes, logic analyzers, microprocessor emulators (with real bond-out silicon), assemblers and debuggers with disassemblers and instruction trace capability. Code had to be written efficiently to fit into kilobytes of RAM and mask ROM or EPROM. Fortunately, a few old-school designers and firmware engineers are still around who know how to use these tools when exception handlers or race conditions need to be debugged.

Of course, the job now is to hide the secret sauce behind pretty APIs for the young buck software engineers. Who knows, your medical surgery apparatus or weather balloon may have its own following on Facebook or Twitter soon. Every silver lining has a touch of gray.