Skip to content

Why Take an Embedded Systems Course?

Embedded systems are special-purpose computers that users don’t think of as computers. Examples include cell phones, traffic light controllers, and programmable thermostats. In earlier posts I argued why any computer scientist should take a compilers course and an operating systems course. These were easy arguments to make since these areas are core CS: all graduates are expected to understand them. Embedded systems, on the other hand, often get little respect from mainstream computer scientists. So why should you take a course on them?

Most Computers are Embedded

Around 99% of all processors manufactured go into embedded systems.  In 2007 alone, 2.9 billion chips based on the ARM processor architecture were manufactured; essentially all of these were used in embedded applications. These processors live in your car, appliances, and toys; they are scattered throughout our buildings; they are critical to efficient operation of the infrastructure providing transportation, water, and power. More and more the world depends on embedded systems; as a technical expert, it’s useful to understand how they work. The market for desktop computers is pretty much saturated; the embedded world is growing and looks to continue to do so as long as people continue to find it valuable to place computation close to the world.

Embedded Programming Can Be Fun and Accessible

Make Magazine has done a fantastic job popularizing embedded systems projects. Lego Mindstorms, Arduinos, and the like are not that expensive and can be used to get a feel for embedded programming.  Controlling the physical world is addictive and fun; head over to Hack A Day and search for “paintball sentry,” I defy any nerd to tell me with a straight face that this stuff is not totally cool. This spring I heard a fantastic talk by Sebastian Thrun about his team’s winning effort in the DARPA Grand Challenge (some of his presentation materials are online).

Embedded is Different

Monitoring and controlling the physical world is very different from other kinds of programming. For example, instead of nice clean discrete inputs, you may find yourself dealing with a stream of noisy accelerometer data. When controlling a motor, your code suddenly has to take the momentum of an actual piece of metal into account; if you’re not careful, you might break the hardware or burn out the driver chip. Similarly, robots live in a bewildering world of noisy, conflicting sensor inputs; they never go quite in a straight line or return to the angle they started at. Solving all of these problems requires robust methods that are very different from the algorithmically-flavored problems we often solve in CS.

Embedded Makes You Solve Hard Problems

Difficult embedded programming problems force you to create highly reliable systems on constrained platforms. The software is concurrent (often using both interrupts and threads), must respect timing constraints from hardware devices and from the outside world, and must gracefully deal with a variety of error conditions. In summary, many of the hardest programming problems are encountered all at once.

Debugging facilities may be lacking. In the worst case, even the humble printf() is not available and you’ll be debugging using a logic analyzer and perhaps some LEDs. It brings me joy every year to sit a collection of CS students down in a lab full of logic analyzers; at first most of them are greatly confused, but by the end of the semester people are addicted to (or at least accustomed to) the ability to look at a real waveform or measure a pulse that lasts well under a microsecond.

Modern high-level programming environments are great, but they provide an awful lot of insulation from the kinds of bare-metal details that embedded programmers deal with all the time. People like me who learned to program during the 1980s have a reasonable intuition for what you can accomplish in 1 KB of RAM. On the other hand, programmers raised on Java do not. I’ve helped students working on a research project in sensor networks where their program didn’t work because it allocated more than a thousand times more RAM than was available on the platform they were trying to run on. Many years ago I spent far too long debugging problems that came from calling a printf() variant that allocated about 8 KB of stack memory from a thread that had 4 KB of stack.

All of these difficulties can be surmounted through careful design, careful implementation, and other techniques. By learning these things, students acquire valuable skills and thought processes that can also be applied to everyday programming.

Embedded is in Demand

I don’t have good data supporting this, but anecdotally the kind of student who does well in an embedded systems course is in high demand. A lot of CS graduates understand only software; a lot of EE and ME graduates can’t program their way out of a paper bag. Students who combine these skill sets — regardless of what department gives them a degree — are really valuable.

{ 5 } Comments

  1. Sam | June 29, 2010 at 6:10 am | Permalink

    Also if you want to get into games programming, take an embedded course! Consoles can be thought of as embedded environments. They’re not like a PC at all! Fixed memory, fixed CPU, no virtual memory. The various console manufacturers require you to write pretty solid code. You are often working close to the hardware. Even if you’re not writing assembly code, you still need to think about things like memory usage, disc and RAM access speeds, cache coherency.

  2. regehr | June 29, 2010 at 3:54 pm | Permalink

    Good point Sam!

  3. PRAKASH W DANDEKAR | July 2, 2010 at 2:16 am | Permalink

    I teach embedded systems to CS and EE undergrad students.

    I find your article very useful and mailing to them.

    I also teach in the local University MSEE classes and they will also get a copy of this.

    Very recently I came across ARDUINO, SANGUINO, SEVERINO and now busy designing shields for them so that my students can do lots of projects on it. Most luckily, these are manufactured in India at incrediby low cost-, starting from US$10 each.

    I propose to upload all my shield designs designs including code on website for sharing with others. Current passion among student community here is making robotic vehicles for DARPA kind of applications, soccer playing and wrestling robots.


    KCBTA Technical Academy
    Umaria, Rau, Indore
    INDIA 452009
    +91-96300- 42954

  4. Srivatsav Venkatesan | December 8, 2010 at 12:44 am | Permalink

    Good one professor…Usually I perform context switching:) when I read blogs. The RTOS in me puts my reading in blocking state when I read blogs but there was no blocking when I read this article…

  5. DEV | December 8, 2010 at 9:59 pm | Permalink

    i compltd my be in 2010.please guide me wt 2 do.i m thinking abt advanced embeded system.pleas guide me n please reply