Engineering embedded systems is an increasingly interesting, disruptive — and lucrative — field for designs ranging from bicycles to firearms to airplanes and beyond.
In the following interview, “Making Embedded Systems” author Elecia White (@logicalelegance) describes how she came to write a defining book on the subject, how she came to learn the practice, and why she came to realize that the future is just around the corner.
Why are embedded systems important right now?
Elecia White: Embedded systems are where the software meets the physical world. As we put tiny computers into all sorts of systems (door locks, airplanes, pacemakers), how we implement the software is truly, terrifyingly important. Writing software for these things is more difficult than computer software because the systems have so few resources. Instead of building better software, the trend has been to allow a cowboy mentality of just getting it done. We can do better than that. We must do better than that.
What made you write the book?
Elecia White: Years ago at a conference, I sat with several academics as they discussed how to draw more women into advanced computer science (CS) degrees. As I was the only non-Ph.D at the table, they tried out their ideas on me. However, nothing could stand up to the education (and fun) I’d had in my career: making a gunshot location, building DNA scanners, seeing my toys on Target’s shelves, and working on race cars. I had seen how projects worked, done some hard math, published some neat papers, and written a few patents. When I said all of this, one of the professors said it sounded like I had a Ph.D. and all I needed was to write a dissertation. My book represents the things I’ve discovered on my path through embedded systems.
Can you expand on some of your past projects?
Elecia White: People often think that writing software means staring at a computer screen all day. I’ve seldom found that to be the case with embedded software. Sure, I do get to program code. But there is also hardware, so I get to spend time making the software work on the board as it senses and/or changes its environment. The system is typically in something else (like an inertial measurement device in a race car), so I often get to see how application meets the road.
As an embedded software engineer, I am often in the middle of the system, working closely with both application software and hardware engineers. I get a unique perspective of the whole product. I work with electrical, mechanical, and application software engineers to create a complete system. It makes for a fun, interactive job.
One of my favorite jobs was at Leapfrog, making educational toys. There is more to it than writing software that says, “C is for cat.” The software controls the game play, getting inputs from buttons and playing the correct audio. However, if the same responses happen to the same inputs each time, the interaction is awkward. Then we got to add touchpads, motors, screens, and RFID tags to make each toy an interesting, unique product. There — and in the book — I have enjoyed thinking about how to make something fun as well as educational.
Was being an embedded software engineer even a job when you began?
Elecia White: My degree was a combination of applied CS and theoretical systems engineering. I was just shy of double majoring and designed my degree because those two seemingly different fields interested me. It ended up being the perfect embedded systems major, giving me plenty of software engineering experience as well as a little bit of electrical engineering.
I started my career doing pure software. It was a job, and it paid well. I was kind of bored, but I kept getting deeper into the operating system, writing drivers and getting closer to the hardware. Then I was hired to work on a DNA scanner at Hewlett-Packard (at a division that is now part of Agilent). The manager there was so excited to introduce me to his embedded software team, and he was right. The first time a motor moved because of my software, I was completely hooked. My software could touch the physical world.
However, I was ignorant of electrical engineering. I had no common sense where handling boards was concerned. I could barely read a schematic and then only the analog parts, laboriously working out equations I hadn’t used since college (and didn’t really need to write the software). I didn’t understand how to read a datasheet without getting buried in minutiae. And despite my enjoyment of pyrotechnics, there is something quite horrifying about destroying valuable equipment. (Always know where the fire extinguisher is!) I was extremely fortunate to have some hardware engineers who were willing to be patient with the new kid. Without their support and friendship, it would have been far easier to return to pure software and into the very interesting biomedical software the company was also working on.
Without naming names, can you give some examples of bad embedded systems?
Elecia White: Embedded system software is a cross-disciplinary field, requiring an engineer to have the attributes of both a hardware engineer and a software engineer. However, most of us come at it from computer science or electrical engineering, so we have to learn the other half of the job on the fly. It makes for some interesting compromises.
I was at a company with really smart people who could do amazing things with their algorithm. But they didn’t know how to use version control, copying the code to a new directory each time it was modified, proliferating different code bases for various clients. As a software engineer, that memory makes me cringe, but I’ve seen it more than once.
At one neat little company, when the hardware came back, they couldn’t figure out why it didn’t work. The board had noise in the data acquisition system. But nothing was built into the software (or hardware) to let them see the data directly. Weeks were spent trying to figure out how the algorithms were broken when they were correct; it was just a simple error on the board. A little bit of good embedded software would have verified the peripherals as soon as the board came back. A better design would have let them record the acquired data so they could see the errors.
The real world is a harsh place. Often, systems will work in a lab, but when they get into the wild, things go wrong. But for one outdoor system, the salt fogs of Boston ate away the electromechanics, leaving only a rusted shell. Needless to say, the software didn’t perform as well as it had in sunny, dry Los Angeles.
What’s on the horizon for embedded systems?
Elecia White: Jewelry that monitors vital signs. Credit cards that only work when we touch them. Smart dust and nanobots. Personalized learning. Self-driving cars. Science fiction isn’t so far away from fact.
Imagine 1991, 20 years ago: almost no one had a cell phone; we used Walkmans (and cassettes!) to listen to music; the Internet was tiny and text-based. A lucky few had big desktop computers, game-playing consoles, or electric typewriters.
No one can deny that computers — and the Internet — have changed the world. But there are lots of things we don’t have: flying cars, robot butlers, faster-than-light travel, transporter beams, and cities on the moon. This doesn’t feel like the future I signed up for! But if you are one of the more than 100 million people with an iPhone, you have more computing power in your pocket than any 1991-era computer, at a 10th of the cost.
If this is progress, what will 2031 be like? The very goal of embedded systems is to distribute the intelligence from a centralized computer to a smaller widget that can live in your home, on a satellite, in a car, or in your pocket. If a big desktop computer from 2011 can fit in our 2031 pockets, does that mean our smartphones will fit into an earring or disposable microdot?
We may not have our cities on the moon yet, but what we have is amazing. And it just keeps getting better. Who really needs a robot butler to make coffee when you can already buy one that does the far more useful job of cleaning the floors?
This piece was assembled from two separate interviews. The Q&A was condensed and edited.