Feature Creep
Only recently have embedded systems sported operating systems, if only because low-end hardware has grown large enough to support such overhead. That ESD survey showed 29 percent of embedded systems still have no OS, with consumer electronics hitting 40 percent. Although it's not explicitly stated, I assume the survey was aimed at developers of systems capable of running an OS, rather than PIC-class microcontrollers.
Kavitha Shanmuga Sundaram presented a fascinating (if you're that kind of techie) talk on "Migrating from 8- and 16-bit to 32-bit: Lessons Learned the Hard Way." Her experience in the textile industry, where intricate machines produce uniform products in huge volumes at incredible speeds, includes process control and monitoring devices. Many of those gadgets started out as mechanical linkages, used electronics when the cost advantages became compelling, and have since migrated into the RTOS and Linux arena.
One of her projects jumped from an 8-bit microcontroller to a 32-bit ARM, not so much due to feature creep as the fact that a single-chip ARM7 costs less than the high-end PIC microcontroller they'd been considering. The application involved a set of spindle status indicator lights on a cloth loom, a task implemented with mechanical switches and parallel high-voltage wiring back in the Good Old Days of cast iron machinery.
By the time they switched to the ARM, the features included maintaining a lamp's state across power failures and serial communication to microcontrollers at each lamp. But the overall complexity remained at an 8-bit level and didn't require any 32-bit OS features.
She pointed out that many bare-metal programming techniques simply don't transfer well to the strictures of an operating system and, in particular, to the Linux kernel's isolated and well-protected memory and I/O. Rewriting an existing application may not be practical for what's seen as a small upgrade, even if you're switching CPUs in the process.
She suggests simply continuing bare-metal programming in such a situation, at least until feature creep demands support for complex devices that simply can't be handled by your staff. For example, hammering out your own networking, graphic displays, and USB device support just doesn't make sense, so that's when you accept the overhead of an OS and rewrite the app.
Her talk was, by my informal tally, more lightly attended than I expected, particularly given the number of low-end microcontrollers sold each year. Perhaps there's a mismatch between the relatively high-end ESC audience and the preponderance of low-end apps? It may be that the majority of folks in the low end of the market don't need any of the fancy offerings found at ESC, perhaps because there's no money in the budget for such frills.
