4 Replies Latest reply on May 19, 2010 6:39 AM by mikef@signalscape.com

    School  to career path suggestions?

    Cabe Atwell

      What would be the best degree to obtain if you wanted to start a career in embedded design, Electrical Engineering, Computer Science, or something else all together? A student recently asked me this question, and as far as a current perspective is concerned, I was unable to help guide them. Since most everything is modular now, off the shelf parts, I am thinking embedded programming or computer science would be the best option. But on the other hand, one should never be in the dark about the hardware driving the system, so perhaps Electrical Engineering is the best degree.

      The current job climate demands years of experience, but what if one can't get experience, or an internship, what is a good alternative? So you have to assume this student leaves college with no real world experience, what would the best degree that will give them their best chance in getting a job?

      Your advice will be passed on to this student, and they will greatly appreciate it. You just may change a life.


        • Re: School  to career path suggestions?

          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:

          • Computer Engineering curriculum, with classes in:
            • computer architecture (caches, virtual/physical memory).
            • microcontroller and microprocessor based systems, including peripherals
            • digital control theory - not a strong requirement, but would make someone stand-out in the eyes of a potential employer.
            • C/C++.  I would say 2 semesters at a minimum.
            • embedded operating systems, like Linux and other RTOSs (real-time operating systems) - understanding of threads, processes, memory management.
            • networking (TCP/IP, Ethernet, routing, bridging, network components).
          • "Extra" stuff - can be done by self-study or potentially by classes if offered.
            • other physical layers (USB, UART, SPI, I2C, wireless such as 802.11/WiFi, 802.15.4/Zigbee, PCI-Express, 802.3/Ethernet).
            • communication theory - There is a lot of wireless in the world these days .  Understanding of basic concepts (bit error rate, amplitude, phase, signal-to-noise, Eb/N0, Nyquist, Shannon limit, etc.) as well as modulation techniquest (FSK, PSK, QAM, OFDM).
            • Get some development boards and "play around" with them after the student has a few classes completed.  Great learning experience (Arduino, Microchip, Beagle board, Gumstix).
            • Master's Degree - not a necessity, but will help a student stand out from others.


          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.

          1 of 1 people found this helpful
            • Re: School  to career path suggestions?
              Alistair Winning

              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.

              1 of 1 people found this helpful
              • Re: School  to career path suggestions?
                Cabe Atwell



                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....



                  • Re: School  to career path suggestions?



                    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.