Priority Interrupt by Steve Ciarcia Back to Basics

These days too many technical professionals call themselves embedded-systems programmers. Unfortunately, this employment category has morphed to encompass virtually anyone who writes software for a controller that is subsequently “embedded” into a product design. If you are an engineer writing java code for the PC buried inside an airport luggage scanner, embedded-systems programmer is now on your resume. A guy who writes an entire real-time operating system for a portable EEG in assembly language so that it fits in 30 KB of flash memory calls himself an embedded-systems programmer too.

Call me prejudiced if you want, but as a guy who remembers when the whole software world could fit in 64 KB, I think the only real embedded-systems programmer is someone who has a fundamental knowledge of the low-level computer system operation for the device being programmed. I don’t mean only assembly language programmers, but surely that’s about as low-level as you can get.

In the beginning, engineers had to be very talented to fit everything necessary into a limited space. They had to have a detailed understanding of system architecture and even do things in assembly language if execution speed and program efficiency demanded it. Very few people had this expertise, and the number of technical professionals who called themselves embedded-systems programmers was limited.

As more memory and processing power have been added to controllers, less programming efficiency and less expertise on the part of the designer have been required. Instead of an expert programmer having to spend weeks optimizing assembly language code to digitize video on a 12-MHz 8051, a less experienced individual can now do it easily with a 40-MHz 8051-core SoC (about 10× performance increase) with a hundred times more memory and a dozen built-in peripherals. Today, programmers don’t have to worry about clock cycle times or memory access speeds, because the processing power and memory of modern CPUs and SoCs have increased so much that even an inefficient, poorly written C++ program can usually stumble along and perform its intended tasks. If a program won’t run and doesn’t quite hack it, programmers can always count on the next hardware iteration to have enough added performance to fill in for inefficient and disorganized code.

The problem is that Moore’s law will eventually run out of gas. While the internal complexity of processors still might be doubling every 12 to 18 months, clock frequency and processing efficiency are no longer doubling at the rate they were 10 years ago. In another decade, it will all stop.

Old codgers like me find it absurd that anyone would call himself an embedded-systems engineer without an understanding of hardware. In fact, the latest generation of software engineers has grown up using high-performance development tools that specifically avoid machine dependency. In essence, they were taught that all computers are the same. They were told that any computer has more than enough processing power and memory to accommodate using high-level language software, so they give little thought to efficiency. These inexperienced developers usually write code without considering its performance or the unique attributes of their target system.

Employers are starting to become savvy about the different experience levels within the embedded-systems jobs category. In an effort to separate computer-application-level software engineers from true embedded-systems designers, these days it is not uncommon to see job postings that include statements like, “must know assembly language programming and understand low-level hardware.” In all truth, I doubt any of these companies want someone to actually code processors in assembly language, but this is the terminology they use to draw the line in the sand in front of all the java programmers who like to call themselves embedded-systems engineers. 

This isn’t a sermon. I readily admit that I’m one of those people who counts on the next processor improvement to clean up inefficient code. My expertise was hardware at a time when there were choices about how much hardware and software you wanted to use in your system design. Today, there is little choice. True embedded-systems engineers have to know both hardware and software. I’ve never even hinted at the notion that I’m a “programmer,” system or otherwise. I make no apologies when I point out that programmers should broaden their expertise if they want to add the word “embedded” to their resumes. Everyone else is a brute-force coder and that’s as good as it gets, just like me. Good thing I don’t have to earn a living at it.