I'm currently a software developer/architect (of 14 years) and am considering a move into the embedded/real time programming arena. My question is this...how much electronics experience is actual needed for embedded programming (I have an electronics qualification...but have never done any commercially)? If there is little electronic requirements then what are companies expectations on experience...would the fact that I can program in a lot of languages (C, C++, java, vb etc) aid in getting my foot in the door or are companies only interested in people who have programmed within an embedded environment.
Disclaimer. I'm talking here from personal experience of candidates I've interviewed for jobs working on embedded systems (RTOS, networking) products largely in the automotive sector. Our working environment is almost entirely C with some target-specific assembly on target systems and C++ on Win32 and Posix systems for offline tools and middleware.
It varies, but certainly an appreciation of things like how clocks are generated, properties of things like PLLs, some knowledge of things like debouncing, sampling, etc. would always be beneficial. The ability to read and understand a circuit diagram and a datasheet for a mixed-signal or analogue part is useful.
In general, the more languages I see the less I'm impressed by a lot of candidates - often looks like CV inflation. From my point of view, VB might *very* occasionally be marginally useful for quick hosted hacks. Java.... feh. Cuts very little ice in my neck of the woods. Our experience of Java programmers is that they've been too shielded from 'the machine' to understand what's going on under the hood. We have historically looked for evidence of (or obvious potential for) Ultra-strong C, enough C++ do to offline tools work, and exposure to a couple of assembly languages on different processor families.
A good grasp of discrete mathematics helps too - certainly an appreciation of recurrence relations, set theory, propositional logic, and Boolean algebra.
Your architecture skills could be interesting to some employers, particularly if you can offer good UML and CASE experience.
It varies. Some candidates have impressed us so much that they've been offered positions based on obvious intellect and ability to pick things up quickly (one of our best embedded guys came from a formal methods/HCI background), but they're exceptional and in general for embedded roles we've looked for people who could demonstrate convincing experience and had the right attitude.
pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB
If your experience is mainly in HLLs and "ultra-HLLs" like VB and Java, you might find it most profitable to explore opportunities with extremely complex user interfaces; cellphones, POS terminals, multimedia kiosks, etc. Of course, it is up to you to decide just how different this job is from what you're doing already.
Embedded systems span everything from bit-banging in a 4-bit microcontroller with six nibbles of RAM up to all-singing-all-dancing systems running Linux or Windows - so there is definitely a place for someone with your skillset, it's just a question of focusing on the appropriate opportunities. You're not very likely to land a job writing cycle-exact machine control applications in an 8051 with the background you described; it's possible, but not likely.
Hi, I am in a similar situation as Dan except for the fact that I am just finishing my MS in CS and trying to enter embdded systems field. My question is are there areas of work where you would be given specifications and you are required to do just programming part? I mean without requiring to work with oscilloscope and waveforms. Is it enough to know the architecture of a processor to do programming using C/C++? How fierce is the competetion in this market as far as jobs go? Is it a stable job market? How does the future of embedded systems look with upcoming market of cell phones and Wi-Fi? Is it wise to enter this field at entry level? what are things to be considered?
I am sorry to ask too many questions. But these are unanswered quetsions in my mind. thankin you in anticipation. Abhi
There certainly are jobs out there where the hardware is a known entity, either because it's been in use already or is made from off-the-shelf boards/cards. I've had contracts where the firmware was being upgraded with more software features. You might be able to get started doing that.
I'd get some sort of hardware background though. When the project needs to add or modify or move to new hardware, you'll be that much more valuable to companies. Knowledge is a Good Thing.
Sure, maybe cellphone companies or PDA development but "just" programming will really limit you in the embedded field... It makes sense to get some hardware knowledge (at least know how to read a hardware schematic)... Embedded software engineers in my experience work very closely with the hardware engineers. If you only want to code, you are not going to be very helpful...
Sure, until you run into a problem.... what are you going to do when a someone tells you to check it on the scope...
Fierce is a term used for the dot com bunch... IMHO is you get a job in the embedded field it will be much stabler than other markets...
Cellphones and Wi-Fi are not upcoming... they are here...
I don't think that you will find an entry level position...
Good luck, my only advice is not to be afraid to pick up some electronics training...
I work with embedded systems for research instrumentation. In my field the timing of the system is everything... All measurement routines are initally tested on a scope, if there are bottle necks we analize them and sometimes do it smarter in assembly... If we were hiring we would not be looking for someone to only code...
Yes, but they are not the bulk of embedded work. At some point, there will be bugs involving the HW/SW interface and how the two affect the operation of the entire system, and everyone will be in your office asking why it's broken.
Yes, but for embedded work you will be interfacing with other parts on the system board, and other boards in the box, and other boxes; and these interfaces are rarely all networked (so you can just use socket programming).
I killed three guys today who wanted my job.
Only a matter of time before we all move to Bangalore to find $5/hr jobs doing exactly what we're doing now.
Upcoming? Those things have been part of the business for years.
Entry level is cheaper, so it's probably easier to get in. Hiring managers often care less about qualifications than budget.
Your input has really overwhelmed me and I am thinking of putting it together and making a document out of it. So that I can think over it and post it for any other neophyte looking for information. Thank you very much for all this information.
You could visit some trade shows like the embedded conference boston or whatever city its in (if your in the US), I usually get free exibit invites. There may well be others, see also the Xilinx fpga shows which bring in alot of interesting developers a bit more on the computing performance side. Its a way to get face to face with engineers and see if you can find common interest, or feel for whats out there.
But HW/rtOS/asm/real_math knowhow is definitely valuable, hide the VB/Java under "others". Cpus that are on the up n up are ARM ofcourse, MIPS, PPC and even x86. But any knowledge of one is transferable to others. Also note that cpus can also be soft cores and embedded in FPGAs at will or hardcore embedded like ARM/Altera or PPC/Xilinx. Also you can get entry level boards to learn more about cpus or fpga or both for very little ($100+), and the fpga tools can be free. But that India/China thing I wouldn't worry about yet even though its taking a toll.
While I suppose this is theoretically possible, I wouldn't give $0.02 for the reliability of the resulting software.
I have spent too much time, as a "hired gun", cleaning up messes created when embedded software was left to CS graduates, with no real understanding of the hardware. I have seen the comment, in code I reviewed, "Don't touch this-- changing anything breaks it, and I have no idea why!" [1]
Needless to say, this was the very code I had to redesign, from the ground up, to resolve a major performance bottleneck in the target system. This required a detailed analysis of instruction-to-bus timing relationships of the uC (an
8051 derivative, running in "paged" mode), and the timing requirements of a rather finicky piece of display hardware. The result was a software PLL driv- ing a uC timer, to ensure that transfers to the display device would occur in a very narrow timing window, without consuming too much CPU bandwidth.
The moral of the story is, if you can't understand the hardware, without an en- gineer holding your hand, stay away from embedded systems--or at least, away from anything remotely like "bare-metal" programming. Go play in a nice, safe, Java sandbox, where I (or someone like me) will not wind up cursing you, while cleaning up the mess you made!
Emphatically NOT! In fact, the processor architecture is often irrelevant, by comparison to the hardware constraints, except on those occasions when one has to connect to the outside world via a microprocessor bus (instead of discrete I/O's). In these cases, the bus protocols become important; but these are not a part of the programmer's model of the CPU architecture.
Moreover, it is necessary to know C/C++ well enough to predict what a compiler will generate, not in terms of specific instructions, so much as allocation of resources (stack/register/static storage, time/space tradeoffs, etc.). This is not generally covered in CS programs I have encountered. It is also necessary, in some cases (C++, especially), to know *exactly* when and how dynamic alloca- tion occurs, and the impact of class inheritance on RAM requirements (since it is generally a scarce resource, in most microcontrollers).
The competition seems to be very fierce, right now--at least in the USA. I am presently searching for new work, myself; and the pace of responses to my résu- mé submissions is down considerably from a few years ago (when I could general- ly find a new post within a week or two, through one of a handful of contract shops).
Sorry to be a "wet blanket"; but I believe that to encourage anyone unwilling to look at a waveform on a 'scope to pursue a career in embedded systems would be both foolish and unethical.
YMMV. Others will have their own opinions. HTH. HAND.
-----
[1] If I ever see it again, I will have to hunt down its author, and personal- ly strangle him or her with my very own, two, bare hands. Call me a BEEFH, if you like, but that's the way I feel about it. }>-{>
Sorry about the bad breaks! Didn't use the right "ruler" as I was com- posing, and my user agent neither breaks on-screen as I write, nor lets me post a replacement message. (Leave it to $WEBORGMAKEPCSOFTWARE to ig- nore MANKSA, let alone GNKSA "standards", completely.)
While I suppose this is theoretically possible, I wouldn't give $0.02 for the reliability of the resulting software.
I have spent too much time, as a "hired gun", cleaning up messes creat- ed when embedded software was left to CS graduates, with no real under- standing of the hardware. I have seen the comment, in code I reviewed, "Don't touch this--changing anything breaks it, and I have no idea why!" [1]
Needless to say, this was the very code I had to redesign, from the ground up, to resolve a major performance bottleneck in the target system. This required a detailed analysis of instruction-to-bus timing relationships of the uC (an 8051 derivative, running in "paged" mode), and the timing requirements of a rather finicky piece of display hard- ware. The result was a software PLL driving a uC timer, to ensure that transfers to the display device would occur in a very narrow timing win- dow, without consuming too much CPU bandwidth.
The moral of the story is, if you can't understand the hardware without an engineer holding your hand, stay away from embedded systems--or at least, away from anything remotely like "bare-metal" programming. Go play in a nice, safe, Java sandbox, where I (or someone like me) will not wind up cursing you, while cleaning up the mess you made!
Emphatically NOT! In fact, the processor architecture is often irrele- vant, by comparison to the hardware constraints, except on those occa- sions when one has to connect to the outside world via a microprocessor bus (instead of discrete I/O's). In these cases, the bus protocols be- come important; but these are not a part of the programmer's model of the CPU architecture.
Moreover, it is necessary to know C/C++ well enough to predict what a compiler will generate, not in terms of specific instructions, so much as allocation of resources (stack/register/static storage, time/space tradeoffs, etc.). This is not generally covered in CS programs I have encountered. It is also necessary, in some cases (C++, especially), to know *exactly* when and how dynamic allocation occurs, and the impact of class inheritance on RAM requirements (generally a scarce resource, in most microcontrollers).
The competition seems to be very fierce, right now--at least in the USA. I am presently searching for work, myself; and the pace of responses to my résumé submissions is down considerably from a few years ago (when I could generally find a new post within a week or two, through one of a handful of contract shops).
Sorry to be a "wet blanket"; but I believe that to encourage anyone un- willing to look at a waveform on a scope to pursue a career in embedded systems would be both foolish and unethical.
YMMV. Others will have their own opinions. HTH. HAND.
-----
[1] If I ever see it again, I will have to hunt down its author, and personally strangle him or her with my very own, two, bare hands.
Call me a BEEFH, if you like, but that's the way I feel about it.
I am a computer science graduate and new to embedded system. I want to know more about allocation of resources by compiler (as you mentioned) and memory management in embedded system. Is there any good web site?
I don't know if there are any good websites on the topic, in general; but looking over a few microcontroller databooks might be helpful, for giving an idea of the range of memory constraints.
For uC's with onboard code and data store, it is not uncommon to be limited to 64-512 bytes (on machines with 8-bit data paths) RAM, and
16-48kB ROM. I have seen uC's with 4-bit data paths, and a mere 16 digits of RAM--the code store was something like 128, 13-bit words deep. (As is commonly said, "I have slept since then".)
Dynamic allocation is generally avoided, if possible, because many (if not most) embedded applications have hard realtime requirements, and dynamic allocation algorithms tend to be nondeterministic (although a few are at least well-bounded). Moreover, dynamic allocation can fail, and to stop the systems and scream "Oh, my $DEITY, something is wrong!" is not an option.
In any case, I don't encourage CS grads to pursue embedded work, un- less they also have electronics experience, of some kind--not merely enough to read a schematic, but enough to be comfortable with only an oscilloscope or logic analyzer for debug tools; and enough to be able to recommend *specific* hardware changes to simplify software or to improve the ability to detect system faults.
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.