Building Experience
Bill Gatliff describes the fundamental stumbling block for new embedded developers: "Everything must work for anything to work." All those familiar, modern programming and debugging conveniences depend on a vast infrastructure of stuff that we all take for granted, but which must work flawlessly before we can get anything done. Embedded systems development can start with bare silicon and work upward from there, a task that demands intimate familiarity with techniques and gadgetry far removed from the usual high-level language wars.
You may choose one of two paths that lead to a working system—buy or build. Your choice determines the required level of in-house expertise, has surprisingly little to do with the eventual cost or schedule, and interacts strongly with your personnel retention policies.
Conventional wisdom tells companies to concentrate on their core competency, those snippets of knowledge that distinguish whatever it is that they sell from their competitors' offerings. A biz should assemble the largest-possible hunks of generic hardware and software from folks who actually know how to make them work, add some Secret Stuff, and sell the result. This maximizes ROI by not wasting time fiddling with details.
Medium-scale embedded projects, those large enough to justify an OS and small enough to escape the per-unit cost stricture of mass-market gadgets, now tend to start with stock hardware including all the usual interfaces. Coupling such a board with the unique peripherals for your project eliminates the tedious hardware design required to get a microcontroller up and running, while not including too many extraneous parts. The second version may use a custom board that incorporates all the hardware in one lump, but it'll work remarkably like the original collection of parts.
You'll also get a Board Support Package for the OS of your choice; indeed, if the board doesn't come with such a BSP, then you have likely chosen the wrong board. The BSP includes, at a minimum, the boot loader and drivers required to get the OS up and running from power-on and may extend to a preconfigured, ready-to-boot OS upon which you can immediately begin building your application.
In the ideal case, you need never concern yourself with the details hidden in the BSP, drivers, and OS. In actual practice, you'll generally develop drivers for your unique hardware, at which point you must begin tracking down the usual assortment of errors.
Again ideally, those errors will reside entirely in your code and be subject to the same high-level debugging techniques and tools you deploy during desktop and server development. Many errors will be that well-behaved, but you'll surely trace at least one perplexing glitch right out of your code and into the infrastructure, at which point you're in trouble.
The upside of buying huge chunks of proprietary software is that you need not understand how it all works in order to use it. The downside, that you don't understand how it all works, only comes into play after things go wrong. When you cannot read and modify all the source code, you must depend on the vendor to resolve problems, track down errors, and supply patches.
That situation firmly affixes your product plans to your vendor's patch cycle. If your contract is good enough, perhaps even sporting a service-level guarantee, you're in fine shape. If it's not, then the ideal buy-build trade-off can look ugly, indeed.
That trade-off may also affect your future maintenance obligations. When (not if) your vendor discontinues support for the code in your product, you must either drop your support or upgrade the gadgets to whatever the new version requires. In the worst case, you cannot retrofit new software into old hardware, leaving you with orphan products.
This doesn't matter in the consumer electronics field with its near-zero product lifetimes: Phones are now on a 12-month cycle. Classic infrastructure-level embedded systems, however, run for decades and software lifetimes pose a significant long-term maintenance problem.
Worse, perhaps, is the situation where the vendor's key personnel, the ones who actually know what's going on inside that code, move on to other jobs. Not only do you not know what's happening inside, but the vendor doesn't, either. Scary thought, eh?
The alternative to buying proprietary infrastructure is assembling your own, which in this day and age means adopting FOSS: Free and Open-Source Software. In essence, you get big hunks of Other People's Code, source included, and take on the responsibility of integrating your Magic Ingredients.
This imposes significant up-front costs measured in time, money, and your own personnel. The advantage comes later, as your organization acquires a deep knowledge of the entire body of code inside your product, and need not depend on a vendor for critical fixes.
Several ESC speakers pointed out that you can regard the entire FOSS code corpus much as you would a vendor's offering by treating it as a black box with surprisingly good documentation. The difference, a lack of someone to call when it doesn't work, simply means your folks must develop the skills required to dig into the code and figure out what's broken.
Those debugging skills represent the other end of the buy-versus-build trade-off. Very often, it seems, proprietary (and always high-level) tools impose significant overhead that can obscure low-level problems. Developing the ability to use low-level, sometimes do-it-yourself tools, builds a deep knowledge of the inner workings of your system that can't be obtained any other way.
In any event, the consensus seems to be that a project's final cost and schedule don't depend on whether you buy or build, so any advantages represent, at best, specsmanship. In either case, a single showstopper error can torpedo your product, but there's at least anecdotal evidence suggesting such problems don't depend on where you get your infrastructure or who you call for support.
There are, of course, vendors who can help you understand and use FOSS code, get your staff up to speed, and generally get you over the initial hump where nothing works and everything is unfamiliar. Whether you get locked into their offerings or not depends on how much outsourcing you want.
