Embedded development covers a lot of technology areas - everything from microcontrollers to microprocessors, FPGAs, embedded operating systems (e.g. Linux), C/C++, Java, various wired and wireless physical layers (cellular, WiFi/802.11, Zigbee/802.15.4, Ethernet/802.3).
Embedded development typically stays close to the hardware and in order to be effective, a strong understanding of the underlying hardware is key, whether you are doing hardware development (board-level design, FPGA) or doing embedded firmware. For that reason, I would say a focus in Computer Engineering (or Electrical Engineering with some latitude to pick up digital classes and C/C++) would be best - I may be a little biased here since I have a BS-CompEngr and an MS-EE (digital signal processing focus).
Computer Science is a worthy endeavor as well, but a graduate with this type of background will tend to stay at the application layer (think Windows .NET/C# or Linux application programming) and doesn't typically talk directly to the hardware, but through a device driver (which likely was written by an embedded developer). I've done hardware, firmware, and software development and (no matter what others may say) they are all similar if you consider them at a high level = you have/create implementations of functional blocks and have/create interfaces to those blocks which you have to put together to do something useful.
To stand out in the embedded design field, I would recommend the following:
Lastly, the final trade-off: a student can be a generalist or a specialist. Often, with an undergrad degree (BS) you tend to be more of a generalist. There are exceptions, mind you - like someone who just loves FPGAs or control theory and wants to focus on that particular area undergrad. With a grad degree (MS) you tend to be more specialized in one area but do have some depth in others (i.e. specialist with generalist tendencies).
As a generalist, you'll be able to apply for more positions due to the broad background, but (in my opinion) your probability of landing a particular position is lower. As a specialist, you won't be able to apply for as many positions (due to your more focused background), but the probability of landing the position is higher - just a rough guideline based on my experiences.
Embedded development covers a lot of technology areas - everything from microcontrollers to microprocessors, FPGAs, embedded operating systems (e.g. Linux), C/C++, Java, various wired and wireless physical layers (cellular, WiFi/802.11, Zigbee/802.15.4, Ethernet/802.3).
Embedded development typically stays close to the hardware and in order to be effective, a strong understanding of the underlying hardware is key, whether you are doing hardware development (board-level design, FPGA) or doing embedded firmware. For that reason, I would say a focus in Computer Engineering (or Electrical Engineering with some latitude to pick up digital classes and C/C++) would be best - I may be a little biased here since I have a BS-CompEngr and an MS-EE (digital signal processing focus).
Computer Science is a worthy endeavor as well, but a graduate with this type of background will tend to stay at the application layer (think Windows .NET/C# or Linux application programming) and doesn't typically talk directly to the hardware, but through a device driver (which likely was written by an embedded developer). I've done hardware, firmware, and software development and (no matter what others may say) they are all similar if you consider them at a high level = you have/create implementations of functional blocks and have/create interfaces to those blocks which you have to put together to do something useful.
To stand out in the embedded design field, I would recommend the following:
Lastly, the final trade-off: a student can be a generalist or a specialist. Often, with an undergrad degree (BS) you tend to be more of a generalist. There are exceptions, mind you - like someone who just loves FPGAs or control theory and wants to focus on that particular area undergrad. With a grad degree (MS) you tend to be more specialized in one area but do have some depth in others (i.e. specialist with generalist tendencies).
As a generalist, you'll be able to apply for more positions due to the broad background, but (in my opinion) your probability of landing a particular position is lower. As a specialist, you won't be able to apply for as many positions (due to your more focused background), but the probability of landing the position is higher - just a rough guideline based on my experiences.
I think Michael nailed it, especially in the present tense.
What I would add is that we also need to look to the future, how will embedded design look in 10 - 20 years. Embedded processors are getting more powerful, look at ARM and Intel Atom powered netbooks available now. These are the same or similar processors to those use in embedded applications. In my opinion the main difference between embedded systems and computer systems is the overheads available. With 32-bit ARM MCUs available for under a dollar and memory very cheap, the resource argument doesn't hold as much water as it used to.
In the future I can see the hardware/sofware breakdown taking place later in the design cycle, with FPGAs playing a much lager part. I also think a lot of programming will be done at a higher layer of abstraction using graphical and modelling tools and code generated automatically. This code may even include the drivers and middleware Michael mentions. I've seen a lot of these tools demonstrated at exhibitions, and I think their day is coming. I've also talked a lot to pure IT companies like MKS who are trying to break into the embedded market with project management/versioning tools. When code is no longer limited to what can fit in a 32-bit ROM, it tends to expand to fit the memory available and these IT companies are looking to expand into the embedded market.
Of course many embedded applications will continue as they are today, even at under a dollar, nobody needs a 32-bit processor and 1 million lines of code in a kettle.
In summary, I think there will be a smaller embedded market doing much the same as today, and also a large "middle" market that sits between traditional embedded and IT.
Michael,
Computer engineering is a good option. It wasn't a prevalent option when I was in school, but staying in the higher level of design seems to be the direction everyone is going. With the modular design of products, it only seems reasonable. However, I've noticed a very disappointing aspect of that trend; few students know what it's like to design and program at a most basic of level. For example, few recent grads I've encountered have programming is Assembly let alone anything even more base than that. And also, they may know some electrical basics, if there is a problem like an op-amp feedback issue, the new grads are at a complete loss. Usually they suggest getting a new "whatever module it is," because it may be faulty.
Perhaps Computer Engineering is best, and I will suggest taking some Assembly programming classes.
I am still on the fence though....
Cabe
Cabe,
I agree with your assessment about skills lacking in new grads. I cut my teeth on Intel-based assembly (8051, 80x86) because the C compilers for those devices were just starting to become available. Now, I have hardly used these skills in the last 20+ years, but when tricky or intermittent problems occur in firmware, those skills give me another way I can investigate the problem.
To further substantiate the fact that a low-level understanding is important, especially during troubleshooting: a couple of years ago, I remember having a discussion with an engineer that had roughly 5 years of experience in FPGA design. The engineer was having problems with a particular state machine and after some investigation, found that his state machine was going to a state that was not defined in his FPGA code (a term I endearingly refer to as "jumping off into La-La land"). He stood firm on the fact that "this is just impossible!" I tried to explain to him that he defined the predictable input patterns that he assumed to occur during normal operation, not all of the potential input patterns that could reasonably occur. Some exceptional input pattern was causing the combinatorial logic and D-flip/flops (or look up table) to jump into an unknown state, often causing jumps into other unknown states. It took a long time for me to explain why his problem was happening because he (1) didn't think about the low level implementation that his code was being compiled down into, (2) had strong trust in the tool.
I also find that some of the basic analog skills are extremely weak or non-existent in new grads (except with those that specialized in analog). These analog skills are becoming more and more critical, especially an understanding in transmission lines which is needed for high-speed PCB layout and for the rapid serial transceivers (SerDes).
Now (for a little fence straddling on my part), I have to admit, that the amount of technology and information for an engineer to assimilate these days to stay current is an extremely daunting task, as is the ability for colleges and universities to prioritize which information students get and which they don't (in the interest of time since students typically are in school 4 years for an undergrad degree). Like everything in life, there are trade-offs.