careers in embedded engineering

Hi - I'm a third year EE at UIUC. I've been involved in many personal and class projects involving embedded electronics. Most of my work has been with Atmel microcontrollers - both AVRs and ARMs. I have found this work to be much more interesting than most of the other EE material that I study (power systems, DSP, semiconductors, etc.)

How is the job field in embedded engineering? Do embedded jobs pay as well as other EE jobs? Also, what part of embedded work would an EE do? In my projects I do everything - I first figure out what is needed, then draw out a schematic for that purpose, then lay out the board, then have the board printed, assemble the board, then program it. But I expect in a real world environment I would not be involved in every step like this.

Lastly, are there any classes that would be very helpful for a career in embedded engineering? Next year I have space for a number of technical electives (essentially, any engineering class), so I'm looking to gain as much useful knowledge as possible.

Thanks,

-Mike Noone

Reply to
Mike Noone
Loading thread data ...

Oddly enough I just wrote a book on this topic (not released yet... but read the blurb )

Here are some short answers:

Slightly cyclical, like everything else - and there are occasionally localized catastrophes in specific industries. However overall the answer is "increasing".

Depends on experience and speciality, if any. A good embedded guy will earn substantially more than someone sitting there doing PCB layouts (which is technically an EE job - that surprised me).

Variable! If you're working at a large company, your job will be rather compartmentalized while you're in the larval stage, at least. Where it goes from there depends on your company's internal policies and how stellar you are. You'll probably graduate from being the "software guy" or the "RF guy" or the "digital guy" to being the cognizant engineer/engineering project lead/whatever your company's term for the position might be. In that role you'll supervise and review more of the project (possibly including mechanical design, analog, digital, PCB layout and software) - you may get to pick and choose and do some of the work yourself.

If you want to keep the broad-spectrum view then I advise a career in small businesses.

You might be in a small company, though the PCB layout and assembly stuff is borderline. In a large company, you definitely won't get involved in layout, etch and stuff except when problems come up; you'll need to provide support to manufacturing engineering.

It depends what you already have and where you're looking to move. RF-related engineering appears to be increasing in marketability at the moment. Everything is going wireless :)

What you learn at school isn't very important, though. It's what you practice once you get into the workforce that matters.

Reply to
larwe

If it's not too late -- get a position as an intern for this summer! Then do your best to do something real while you're there so you can get it on your resume! If you're lucky you'll be so useful that they'll hire you out of school.

If you can't or won't go the intern route, start doing hobby stuff. Going into an interview with stuff that you built is good proof that you can do real things. If you have something cool enough, you may even sidetrack the interview from all the hard technical questions they were going to ask, into a discussion of the cool thing you've built.

I don't know about any one else, but it kinda tweaks me out to see people talking about "embedded design" like it was a career. "Embedded" is something that has been done to a processor, it's not a career choice. Don't go wandering around with a processor in your hand looking for a problem to embed it in -- go looking for problems you can solve, with or without an embedded processor.

If you can pick out a consistent thread in what you're interested in now, learn as much as you can in it. Want to be useful for medium-small companies? Make sure that you can build _all_ of an embedded controller, from the power supply, through the microprocessor, to the amplifiers -- throw in the signal conditioning for the sensors, as well.

Whatever else you do, make sure that when you come out you can not only design stuff, but also understand a bit about business processes, be able to write a cognizant document (your posts on the various groups indicate you'll do OK there), and know stuff outside of just EE.

That last -- know stuff outside of EE -- may be one of the most important. As I ranted, you don't embed processors for the sake of embedding them. You embed processors for the sake of solving a problem, and that problem is _not_ just that someone wants a processor! They want bank transactions made, or they want bread cooked, or they want toilets flushed, or they want engines managed -- all of these things require knowledge outside of pushing electrons around, and the more you can encompass that knowledge (and quickly) the better you'll be at solving the underlying problems.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

While I understand your point (I think), I am someone who has - consciously - made a career out of embedded design. To explain: I'm an electronics guy, not an IT guy. I got into microprocessors as electronic components, and then into software design. I have little interest in "computing" per se [1] - my speciality is the hardware/software interface.

[1] Although, to be fair, I've become a bit of a Unix nut over the last 10 years - mostly because of my other business (ecommerce for musicians). By "no interest" I mean that I would actively turn down a job which consisted purely of desktop development for e.g. Windows. OTOH I don't turn down jobs which involve hardware development with no s/w or CPU content.

Unless, of course, I've missed your point.

Steve

formatting link

Reply to
Steve at fivetrees

I too have made my carreer out of embedded systems design and I too have little interest in PC applications, aside from simply wanting to understand how to do it for personal reasons. I started for a small to medium sized company developing software. For many years, my career was focused on software for embedded systems. Eventually, I began to come full circle and started getting more involved in actual hardware development. The change was mostly out of necessity as the company I worked for was beginning to experience noise trouble with one of its products and it required a partial redesign to solve. In the process of doing so, I brought my skill set full circle going back to my EE education.

I think that developing for embedded systems requires a more robust skill set than developing for a PC in that it requires you to have a much deeper understanding of the underlying "nuts and bolts" that make up the system. Right now, I am a project manager for a small division of a large company. The design team consists of myself and a software developer who reports to me. This person's degree is in computer science. I used to watch at first how his eyes would glaze over at the concept of having to control hardware registers and deal with real time interrupts which was well beyond his schooling. From watching his reactions and helping him to understand the differences between the PC and Embedded worlds I realized the difference between two worlds.

Reply to
Noway2

This is usually true, but starts to break apart for large embedded applications. Remember that "embedded" also covers the case of a Windows PC inside a box, such as the self-service photo scan/print kiosks in pharmacies and department stores.

PC app-layer programming is much more of a commodity skill than lower-level embedded development. Lower wages, higher probability of short-term outsourcing. I wouldn't consider it as a career option, given the alternatives.

Reply to
larwe

Indeed. A while back this NG was host to many discussions as to the definition of "embedded". ISTR we agreed that "embedded systems" covered the embedded-PC approach, while "embedded product" covered (IMO) true embedded. Although I may be misremembering...

Also agreed. Furthermore, my experience has been that PC programmers have far less of a clue about the rigours of true embedded design, which includes such mantras as "Thou Shalt Not Crash", "Thou Shalt Eschew RunTime Errors", "Heap Fragmentation Is The Spawn Of The Devil", "Thy Resources Are Not Limitless", and "Blessed Be OO, But C++ Sucketh".

(Sorry - couldn't resist - teehee ;).)

Steve

formatting link

Reply to
Steve at fivetrees

God, yes. From section 4-1, in chapter 4 ("Teaching Yourself, Top-Down (Large Embedded Systems)"):

"The previous chapter dealt with people who have hardware experience and want to start learning about microcontroller programming, or a "bottom-up" approach to embedded engineering. At the other end of the spectrum, we find people who have considerable experience programming application software in high-level languages, and who now want to extend their reach into embedded systems. These people will typically have what I would describe as "IT" qualifications (database programming, HTML design, Java development and so forth), rather than engineering experience. Computer science majors quite frequently fall into this category.

There is an immediate difficulty in adapting these people to embedded environments, and this is that pure software projects for mass-market operating systems (Windows, MacOS and so forth) are typically designed with an acceptance of enormous variations in performance margins due to variations in customer hardware. Furthermore, PC hardware is sufficiently expandable and inexpensive that it is realistic for an application software developer to require that the user provide special hardware features such as additional memory, 3D accelerated graphics, and so on. Neither of these two assumptions are remotely acceptable in embedded environments.

The embedded software developer must be able to:

a) characterize and control the resource utilization of the software exactly. This includes being able to specify how much RAM and secondary storage space the software will require under all conceivable execution conditions, with explicit safeguards in place to prevent the software from overrunning those limits under unusual input circumstances. In most cases, it is also necessary to provide some guarantee of real-time performance (though the limits here are often quite loose enough that people don't take explicit notice of them). b) develop the software in such a way that it utilizes available system resources efficiently, and c) design the software to perform deterministically under specified input conditions.

None of these skills are apparently in great demand in modern consumer applications software development(1); hence, they are not well taught in computer science degree programs. Also observe that the scope of the word "software" in this context explicitly includes the operating system running on the target device; it isn't normal for application developers on PCs to have to guarantee the behavior of the underlying operating system.

(1) - Engineers generally have a very special view of the deplorable state of consumer software development. This is one reason why you'll find a disproportionately high number of engineers running open-source operating systems. They've got bugs, just like commercial software, but at least there's the opportunity for a user to fix the bugs (even though most engineers would never have enough free time to start tinkering with that code)."

Reply to
larwe

[rest of interesting quote snipped

Larwe,

Thanks, nice quote. I generally agree but before we engage in too much self gratulation I'd like to add that:

a) Good CS programs do teach about wise resource usage, just maybe in terms that are too abstract b) The distinction between embedded and "other", while never very crisp, is quickly disappearing completely. Anyone entering the embedded arena would be well advised to know basic software engineering skills and high-level SW development skills on top of being able to write a working interrupt handler. c) Really competent embedded engineers can write efficient, beautiful C++ programs that run on an 8051, heh, heh.

Andrew

Reply to
andrew queisser

Hmmmm.

Yeah - mostly by avoiding all the C++ (mis)features ;).

Steve

formatting link

Reply to
Steve at fivetrees

Footnote: at the start of this chapter, and in numerous other parts of the book, I warn that engineers are a contentious lot only too happy to debate how many angels can dance on the head of a pin ;)

I can't agree with this. Consumer applications development is simply not performed the same way as embedded development, nor does it have the same goals. Consumer apps are designed to run on widely disparate hardware, and the end-user is expected to judge if the performance is adequate (and he's expected to upgrade the hardware if performance is not satisfactory). Embedded applications [done properly] are developed in parallel with, or at least tightly coupled to, the hardware. Consumer applications cannot be specified to the level of clarity that embedded applications can be.

What you wrote implies that at some time in the future it will be impossible to take a software project and decide whether it is "embedded" or "consumer". The consumer software industry is going to have to shift to fixed hardware (Xbox, anyone?) and develop a hell of a lot more design rigor before this is even slightly true.

If you really meant that embedded apps are growing to the point where what was formerly a little 8-bit asm program now requires a 32-bit micro with MMU and an RTOS (e.g. 1990-vintage AMPS vs. 2006-vintage GSM cellphones!) I don't argue with that, but I still insist that the design rigor is much greater in the embedded instance.

I use such a program to control the door on my unicorn trap.

Reply to
larwe

Exactly. In fact, you can replace "C++" in the above quote with _any_ language, from assembly on up. You can teach a good embedded engineer C++ (even larwe, but the effort would be to get him to consider using the language) but I have serious doubts about teaching a desktop C++ programmer embedded.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Oooh, mreeow! ~scratching motions~

C++ has a place in high-end embedded applications where the operating system's SDK is designed around a C++ assumption. I've used C++, of course, but I'm not proud of it.

My original main contention, as you'll recall, is that C++ saves nothing in maintenance effort over good C. Bad C++ (i.e. most of it) is worse than good C. It's also worse than bad C.

I'm in good company. Plenty of people far more reputable than myself have made cogent arguments against the use of C++ in embedded applications, especially small applications.

I think I deal with this kind of posting best when I'm slightly sauced, which means I'm out of the running right now as the strongest thing I can drink is coffee.

Reply to
larwe

Nicely put, and exactly my perception.

Steve

formatting link

Reply to
Steve at fivetrees

I used to work at a place where the demands of the product meant that all the software engineers had to be Really Good Embedded People, regardless of the language used. We used C++ without serious problems, and found that it increased our overall productivity.

If you buy a copy of my book you'll notice that all of the sample code is written in C, _not_ C++.

Perhaps that calibrates where _I_ stand, at least a little bit.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Sorry, sloppy writing. What I meant was that there are a lot of applications for which the distinction between "embedded" and "consumer" isn't clear. There still are a lot of applications on either end of the spectrum that clearly fall into a category like "embedded", "consumer", "scientific/engineering", "IT", etc.

On the other hand, I see a rising number of applications in the gray between the extremes. To work successfully in that gray area requires skills from both high-level software engineering and low-level hardware oriented programming. Bridging the gap can be difficult sometimes: aside from the fact that you have to learn new skills you need to teach the embedded folks revision control is not the same as copying your project to a folder called TempOld_Bak_Version1.bak.bak.worked_with_HWRev0.9 and you have to teach the XP-enamored software engineers that "design review" is not a four-letter word.

Andrew

Reply to
andrew queisser

At a former place of employment, a woman with a Masters in CS informed me that a software set on the product (an automotive engine controller) was "engineering" and she wouldn't have anything to do with it. The same software set on a Sun workstation (running on an instruction set emulator) was "computer science" and evidently acceptable to her. Hmmm.

At an even more former employer, the embedded SW group was under the hardware group and there was a separate software group. The rule of thumb there was that an embedded programmer could move to the software group and be successful, but a software person couldn't make it in the embedded SW group. The software group was even using the same processor (68K) as the embedded group for some of its work. In over 10 years there, one person did finally make the switch from SW to embedded SW. To even further defy the odds, the person was a woman.

~Dave~

Reply to
Dave

If we agree, then why are we fighting?

(To appreciate this posting in full context, understand that immediately before visiting c.a.e this second, I had JUST finished watching Child's Play 5 - Seed of Chucky).

Reply to
larwe

Embedded is just a specialization of EE. I think the key things to remember:

1)If you have any experince doing a complete project from concept to working that is a huge plus for a new graduate. At interview time I'd much rather hear about your Robot than your GPA.

2)If you want to cover a broader swath of the project stay in a small company.

3)The only reason a company hires you is to solve a business issue. So if you understand the business and your place in that business you are farther ahead than many.

4))You should get paid in proportion to the value you add to the business case. This is less true in a larger organization.

5)Any truely life changing income will not come from a traditional job, it will be from bussiness ownership in some form, start your own, stock options etc....

6)You are young, unless you've already accumulated responsibilities like, spouse, kids, house, now is the time to take risks in your carrer

7)Embedded design is a tool, Just like any tool it can be used for many things. you need to have an understanding of the area where you want to use that tool.

Want to work in San Diego?, send me a Resume. snipped-for-privacy@netburner.com

For the lurkers out there if you have 0 to 4 years of embedded experience and have built something from concept to working, on your own, then feel free to send resumes as well. (hobby projects are not just ok, they are a plus it shows buildingthings is more than just a paycheck.)

Paul Breed CTO Netburner

Reply to
pbreed

Depends on the software content/complexity. For very low SW content/complexity, I could go along with this. However, as the SW content/complexity increases, it becomes a specialization of CS.

My three rules for newbies:

  1. Don't get married. 2. Don't have children. 3. Go with a startup.

Ignored, so far. :-/

How nice, another door slammed shut to someone with 5+ years of experience.

~Dave~

Reply to
Dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.