Educating Embedded Engineers

One of the biggest problems affecting the embedded systems industry is a shortage of properly skilled firmware developers. I spoke of this in a recent video interview.

Embedded software developers need some skills taught to Electrical Engineers and others taught to Computer Scientists. They also need practical hands-on experience. Unfortunately, even the best of the Computer Engineering programs at Universities fail to deliver the right mix for embedded work.

The demand for such skilled help is growing rapidly--with the latest estimates put at over 4 billion embedded products manufactured per year.

Fellow Embedded Guru Mike Anderson wrote a nice piece about all this for an IEEE-USA publication called "Today's Engineer." I happened across Mike's article in print, but you can find it online by the title "Help Wanted: Embedded Engineers."

Embedded C Quiz Results

When we redesigned the Netrino.com website late last year, we thought it'd be fun to challenge our more than 20,000 monthly visitors (mostly embedded software engineers) to a skills test. So we developed a ten question multiple-choice quiz (http://www.netrino.com/Embedded-Systems/Embedded-C-Quiz). And it has been a popular feature of the new site, with a couple hundred participants just in the first two months.

And now the results are starting to come in. We analyzed the early results a couple of ways and discovered something worth talking about: Quiz takers from India did about the same as quiz takers in the U.S. But the rest of the world lagged behind these two groups quite a bit.

There are ten questions in our quiz, and we consider a passing score to be 8 out of 10. A handful of quiz takers have scored 100%, but most score in the 30-90% range, with an overall average at 60.4%. (A little scary, huh?)

Statisically speaking, there were three significant groups of quiz takers by geography. The average score of those taking the quiz from the United States was just shy of 64%. The average for India was not far behind at about 61.2%. However, the rest of the world scored an average of just 55.9%.

What does this say about the state of the profession of embedded software development? Offshoring? The quiz itself?

Public Course on Multithreaded Programming

This coming January, I'll travel from chilly Baltimore to sunny Miami to teach an in-depth training course about the proper use of real-time operating systems to design multithreaded firmware. The aim of the class is to clarify the safe and correct use of RTOS primitives, such as mutexes, semaphores, and mailboxes.

The two-day course, called Multithreaded Programming with uC/OS-II, will be held January 22-23, 2008 at the Weston, Florida headquarters of RTOS vendor Micrium, just east of the Everglades. Registration is open to the public, but the total number of seats is limited.

The hands-on course involves a mix of lectures and a coordinated series of programming exercises. The target hardware is an ARM9 development board from STMicro. The increasingly popular uC/OS-II real-time operating system will serve as the reference API with compiler and debug tools from IAR Systems.

Full details, including registration instructions, are available at the Micrium website: http://www.micrium.com/support/training.html

Educating Engineers

Engineering is a fast-moving field. Even embedded systems design, which is known to use decades old tools, sees new processors and new peripherals and higher speeds and new languages and new techniques arrive continuously.

Unlike the medical profession, which requires continuing education to keep pace with changes in the knowledge base, engineers generally stop learning formally once they obtain a University degree. There is no such thing as Continuing Engineering Education credits.

Symptoms of the resulting intellectual stasis include not only a failure to keep up with evolving best practices, but also the perpetual desire of businesses to hire younger, freshly-educated engineers whether here or abroad.

If we as engineers are to continue to deliver value commensurate with our growing salaries, we must dedicate ourselves to the kind of perpetual learning required in other professions. Only then will the trend toward the use of more fresh-out and offshore engineers be slowed.

What do you think?

The Practice of Engineering

As another academic semester draws to a close this month, I feel compelled to share some thoughts about how traditional institutions of higher learning are failing to train engineers and computer scientists to become embedded programmers.  

Writing software for embedded—particularly safety-critical or real-time—systems is not easy. Many folks with a degree in computer science or engineering will never be qualified. A deep understanding of computer hardware and specific I/O interfaces and devices is one requirement. Knowledge of and experience with programming techniques that hold up under soft or hard real-time deadlines is another. Willingness—even eagerness—to debug difficult interactions between software and hardware with limited visibility into a system is an absolute must.

The subject I teach, operating system internals, deals with some of these issues. I expect the students in my course to gain an understanding of real-time scheduling, multithreaded programming and synchronization, and device driver writing. These skills would serve them well as embedded programmers—but one course is not enough to make them such.

Most of my students arrive with only a limited understanding of computer architecture! It’s unbelievable, unless you’ve seen it first hand, that the bulk of a group of graduate and senior undergraduate students studying computer engineering don’t understand basic concepts like stack frames, interrupts, DMA, and cache. It’s not that they haven’t heard those words before; rather, they don’t have any first-hand knowledge and, therefore, lack understanding of these extremely important concepts.
This is symptomatic of a larger problem with engineering education in general. Engineering students are not currently challenged in the right ways. They’re challenged to understand computer architecture without designing a computer. They’re challenged to understand operating systems without writing one. And they’re challenged to understand (and write, in my class) multithreaded programs with only one freshman course in basic C programming behind them.

Why aren’t engineering departments challenging their students to be engineers? Engineering is the practice of science. Students are taught the basic science well: math, physics, chemistry, etc. But they’re not taught the practice. By the time they get to their junior year, and throughout grad school, all students should be required to work on real projects—every semester, in every course. A little assembly and C programming here, a CPU design there, and some hands-on DSP work could go a long way toward preparing them for the world of work.

Without that first-hand experience—and I know that’s not just lacking at the University of Maryland because my graduate students are mostly from other schools—these folks just plain aren’t useful as engineers. Among the poor and outdated requirements for accreditation of engineering degree programs is a recent innovation that seeks to address this problem. In their senior year, all undergraduate students are now required to work on a “capstone project”. This involves working on a small team, with the assistance of an advisor, on a project of their own choosing.

While the capstone project is certainly a good idea, it’s also too little, too late. Because students working on these projects haven’t had any practical experiences before, they rarely succeed in achieving much of anything. The capstone should be part of the end of the program, but it should also be the last in a long string of practical projects—in all manner of courses along the way.

EE vs. CS: The Digital Divide

This fall, I’ve had the pleasure and privilege of teaching a course on operating system internals at my alma mater, the University of Maryland. In so doing, I’ve come to see that the current university-based system of training engineers to do embedded systems work is severely flawed.

At most colleges and universities, the job of educating engineers is split along hardware/software lines. This educational system has its basis in the separate history and evolution of the two fields. The faculty of an Electrical Engineering department generally educates future hardware designers, while an unrelated group of faculty in a separate Computer Science department educates future programmers. There is rarely any cooperation between the two departments, nor are students in one program encouraged or required to take courses in the other. A few crossover courses, like the operating system class I’m teaching to EE majors and the computer architecture class most CS majors are required to take, are insufficient preparation for the world of work.

The fact is that the largest demand for engineers these days is for those who can think and work on both sides of the hardware/software boundary. (Even the boundary itself has begun to disappear.) This is true nowhere more so than in the embedded systems industry. Companies designing embedded systems need programmers who can port operating systems, write device drivers and board support packages, and help debug prototype hardware. They also need hardware designers who can write software for the systems they create, and, increasingly, the job of developing digital hardware looks like programming. Even if an individual engineer won’t need to both write software and design hardware, he or she will probably be part of an engineering team that does both. And teams need to be able to think collectively and communicate easily about issues that affect both sides of a system’s design and implementation.

It is clear that what is needed at our colleges and universities as we go forward is a proper system for training embedded software professionals. To fulfill the needs of industry, universities need to graduate a large number of software engineers who are capable of understanding hardware and interfacing directly to it, and hardware engineers who can apply valuable software engineering techniques to their digital designs.

Many schools have already merged the two departments into a single EE-CS department, or borrowed faculty and courses from each curriculum to create a hybrid Computer Engineering degree program. But is either approach really working? Without a focus on the actual skill-sets and integrated knowledge required by industry, these new degree programs are too often simply “six-from-column-A and six-from-column-B” quick fixes.

Bringing together two departments full of people who have long segregated themselves is easier said than done. Just imagine the Democratic and Republican parties coming together to agree that a more centrist third party is essential for the future of democracy in this country. Then imagine them trying to somehow jointly fashion that new political party from amongst their own members. That’s not unlike the challenge now facing the administrators of Electrical Engineering and Computer Science departments at colleges and universities everywhere. But it’s about time that challenge is taken up.