By Jack Ganssle

Published July 2008 in Embedded Systems Design

Resource Hunters

At least one bird species uses a twig to dig insects out of holes in trees. Some primates open hard shells with branches used as clubs. The Attini ant is quite literally a farmer, cultivating patches of fungus and exchanging fungi species with other ant colonies. Clearly Homo sapiens is not the only species that uses tools to manipulate the environment. Four billion years of evolution has produced creatures whose fitness for their place in an ecological niche must be augmented by using and building things.

Tools are surely one of the defining marks of our species. In 10,000 years we've gone from the wheel to the microprocessor, each invention a means to improve our lot in life.

We engineers are today's inventors, the creators of many of the products that improve and change the life of billions of our fellow Earth-dwellers. Most of the planet's population must now be aware of the microprocessor; surely billions of lives have been touched by embedded products in one form or another. Just last week I talked with a company building tiny 5 KW microprocessor-controlled generators for use in the smallest villages in Nepal. Spacecraft beam TV and other communications products to all but the most remote African communities. Cheap datacomm is propelling third world nations into the global exchange of trade and lifting some from abject poverty. Remoteness no longer isolate societies from the computer age.

In our rush to build products we forget to look on the impact of our creations. Do you make routers? That project might seem to be just a very sophisticated way of shoving packets around, but in fact it's much more. As a primary component of the Internet it quite literally puts food in hungry bellies. www.savethechildren.org and a hundred other aid groups solicit donations on-line and help current and potential donors see in near real-time how a few dollars quite literally saves lives.

Your company's webcam lets distant grandparents connect with their descendants, the NC milling machine reduces the cost of all sort of consumer products, a DVD player substitutes a tiny hunk of plastic for hundreds of feet of videotape built from the most toxic of chemicals. The amount of good done by our products far exceeds what we imagine, especially when we're caught up in the drama and frustration of getting the silly thing to market on schedule.

And yet there are only a half-million of us producing these smart products. A mere handful of engineers whose impact has been quite profound. Perhaps this has always been true of the engineering profession. When Roebling designed the Brooklyn Bridge cars didn't exist; could he have dreamed of the vast numbers of people who would use his concrete and steel edifice to earn a living, feed their children and pay the mortgage? Could De Lessups foresee the vast impact of hiss Suez Canal? Did Jack Kilby and Robert Noyce anticipate how integrating a few transistors onto a single chip meant devices could be smart, energy requirements reduced, emissions curtailed. and of course create good jobs for the 500,000 of us?

We're an odd and almost invisible breed. Mention computer and the average person thinks of a PC. Yet of the 6 billion processors made every year only 250 million go to the desktop market. The rest are for embedded systems. Tell your neighbor you're a computer designer and he'll immediately target you forever for answers about his problems with spreadsheet macros and sporadic system crashes. Embedded? Hey, is that why my car goes 100,000 miles between tune-ups? Ah, my new refrigerator uses half the energy of the older one. you mean there's a computer in there that manages temperature control, cuts my expensive electrical bill, and so helps me send the kids through college?

Resource Hunters

We embedded folks include quite a disparate range of people, with skill sets that range widely. In the early days of the business all developers were EEs, who both designed the hardware and wrote all of the code. Most worked in isolation; few projects required more than a couple of people. The high cost of memory at the time had a self-limiting effect on program size: 4k of code could easily be written by a single engineer in very little time.
Moore's Law drove, and continues to drive, the price of transistors practically to zero so the limits to program size have largely disappeared. Systems with over a million lines of code are not uncommon today. This technological change has created a corresponding one in us; now more and more developers have little to do with the hardware. Quite a few EEs leave college and embark in careers in firmware.

Computer Engineers, who have less exposure to the intricacies of electronic design, and pure computer scientists both bring more of a software-centric focus to projects. Though embedded systems are the last place where hardware and software intertwine to form a unified whole, there's quite a gulf between the people developing each component. The circuit design of systems in many cases is becoming more complex despite an ever-increasing suite of tools and off-the-shelf chips. In many cases hardware engineering now looks a lot like software development as the EEs struggle with VHDL equations and even SystemC code that compiles to a hardware description language.

But one characteristic that both disciplines combine is a continuous search for new tools to accelerate development, new ideas, time-saving products, and canned solutions to common problems. Wise developers are resource-hunters.

Engineering is the art of solving problems, not producing products. Products result from our problem-solving. Engineering doesn't demand we invent everything. The most efficient engineers are those who seek out and use solutions that already exist, saving their employers money and speeding the product to market.

In Print

Even as far back as 1890 "The Electrical Engineer" was a weekly publication engineers read to stay on top of the latest technology. Obviously, the headlines didn't scream about cool new FPGAs; "breaking news" back then included exciting coverage of new forms of wire insulation. But for 100+ years there's been an EE tradition of keeping up, noting resources, and finding useful commercial products.

This is much less common in the software world, particularly for firmware. After all, this is a very new business. The one publication targeted specifically at the industry - Embedded Systems Design - is but two decades old. Its subscribers include only 10% of the engineers working in the field, so clearly a lot of people aren't tuned into new developments.

It's our responsibility to keep up and to pursue new sources of information as aggressively as we build products. This publication and its on-line version are the world's most complete collection of embedded resources extant, both in the ads and in the editorial. Need an RTOS? A compiler? An embedded Cobol compiler? Keil ran an ad in these pages for just that product a couple of years ago. On April Fools Day.

Once engineers strove to acquire and save all relevant knowledge. In fact, a system called the "EEM File" helped catalog the data in file cabinets. This is no longer possible due to the sheer proliferation of information and the move to electronic repositories. But plenty of other venues, in print and on-line, exist.

It's hard to remember life before Google. Maybe it's the old fart in me, but I feel Internet searches have one huge problem: they lack serendipity. Put a magazine in my hands and I have to flip through the pages, looking for interesting stuff. Paging through an initially-uninteresting article maybe a odd graph gets claims one's attention, revealing a pretty intriguing facet of the field never previously considered.

Then there are the ads. BigDogFirmware just went from their usual quarter-pager to a full color, full page spread? They must be doing well; maybe their product is worth a little deeper examination. Only by reading the ads can we keep up with commercial product offerings that may help or even save a future project.

Magazines are a push technology; they place unexpected contents in your hands. The Internet is much more a pull venue that delivers exactly what you're looking for. That's incredibly useful but terribly narrow. I was recently building a control circuit and found a number of useful high-power drive chips on-line. None quite fit my application. Then a friend sent a scan of an old article that gave me a canned solution.

Yet print publishing has been in decline for a number of years. Even newspapers, a cultural part of the landscape for centuries, struggle in the face of electronic competition. That's a shame. Regardless, there are still a lot of valuable print resources for embedded developers, which I've covered here: http://www.embedded.com/columns/breakpoint/175007088

On-Line

Though I prefer a hardcopy magazine over an e-version, there are a lot of fabulous resources on the `net for developers who wish to stay connected to this field. I'm thankful to Dave Kellogg for finding many of them. He's a big believer in using podcasts while driving and exercising for self-improvement. Here are some recommended podcasts and webinars:

  • Agile Toolkit - http://agiletoolkit.libsyn.com
  • Developer Works (IBM) http://www-128.ibm.com/developerworks/podcast
  • Manager Tools (highly recommended) - http://www.manager-tools.com
  • Lean Enterprise Institute - http://www.lean.org/Events/WebinarHome.cfm
  • IEEE Spectrum Radio Online -http://www.spectrum.ieee.org
  • Software Quality Engineering - http://www.stickyminds.com/podcasts/
  • Agile Project Management - http://community.featureplan.com/community/webinar_archive
  • IT Measurement and Productivity Institute - http://www.itmpi.org/webinars

Though there are a number of embedded blogs, these two seem the most interesting and are regularly updated:

  • Embedded Gurus, a collection of blogs from Mike Barr, Niall Murphy, Larry Mittag and others - http://www.embeddedgurus.net
  • Atomic Object - http://spin.atomicobject.com/embedded-corner

USENET and other groups continue to provide useful forums for us. Some of the better ones include:

  • Lean Software Development - http://tech.groups.yahoo.com/group/leandevelopment
  • Lean Software Development and Scrum - http://tech.groups.yahoo.com/group/leanagilescrum
  • Agile Embedded - http://tech.groups.yahoo.com/group/AgileEmbedded
  • comp.arch.embedded
  • comp.realtime

As professionals we have a responsibility to both our employers and our careers to be on top of the latest thinking about embedded systems, and the latest resources that are available. We have to be like doctors, who spend more than a little time reading professional journals to stay current. For after all, stasis is death.