Question

I’ve started learning embedded and its 2 main languages (c and c++). But I’m starting to realize that despite the simple learning requirements, embedded is a whole world in and of itself. And once you deal with real projects, you start to realize that you need to learn more “stuff” specific to the hardware used in the device you’re working on. This is an issue that rarely came up with the software-only projects I currently work on.

Is it possible to fragment this field into sub-fields? I’m thinking that those with experience in the field may have noticed that some types of projects are different from other types, which has led them to maybe maybe come up with their own categories. For example, when you run into a project, you may think to yourself that it’s “outside your field”? Does that happen to you? and if so, what would you call your sub-field or what other sub-fields have you encountered?

Answer 1

Here are a few sub-specialities I can think of:

Assembly Language Specialist

• Yep. You need to know C and C++. But some people also specialize in assembly. These are the experts that are called up to port a RTOS to a new chip, or to squeeze every drop of performance from a highly constrained embedded system (usually to save $$ per unit).
  This person probably is not needed that much these days… but.. yet still critical from time to time.

Device Driver Specialist

• comfortable living between a real OS or RTOS and a piece of hardware. This person is usually comfortable with lab tools like o-scopes or logic analyzers, thinking in “hex”, and understanding the critical nature of timing with HW. This person reads device data sheets for fun at night, and gets excited about creating the perfect porting driver for some new device.

DSP Specialist

• Digital Signal Processing seems to be its own sub-specialty of embedded, although perhaps a software engineer may not know the exact algorithm details, and may only be implementing what a system or electrical engineer requires. However, understanding sampling rate theory, FFTs, and some foundational elements from “DSP” is handy and maybe required. And you still generally must be very aware of timing and your target hardware’s restrictions ( sampling rate, noise, bits per sample, etc).

Control Theory Specialist

• Perhaps the same issue as with DSP: a system or electrical engineer may provide the detailed specs. But, then again, familiarity with various motors, sensors, and other controllers handled by a microcontroller, would be great. Throw in a Bode plot, some Laplace transforms or two and some higher math skills… that couldn’t hurt too much!

Networking Specialist

• basically the same as the PC world “networking”. Many embedded devices are adding networking connectivity features these days. TCP/IP sockets, http, etc good to know and understand how to use in a resource constrained device. Throw in USB and Bluetooth for good measure.

UI Specialist

• more and more embedded devices include 2D graphics, and now more include 3D graphics thanks to the influence of iPhones, etc. Even though these are still “fat” systems by other embedded device standards, they are still limited. Just read a bit in the Android Development Guide, and you will realize that you still must consider responsiveness, performance, etc, even in a high end cell phone.
  http://developer.android.com/guide/practices/design/performance.html

And then, of course, every industry is a specialization unto itself. Consumer Electronics, Military, Avionics, Robotics, Industrial Machines, Medical Devices, etc…

Have fun and good luck!