I've been contemplating a shift in my career, going from a Windows desktop application developer to an embedded engineer. I've been developing desktop apps for nearly 20 years, almost exclusively in C/C++, so as far as languages, I've got that covered.
Does anyone have any advice to help make the switch? What are some good resources (books, web etc) that could help?
I will probably have to settle on book-learnin' until I can find a job that will take a chance on an embedded noob.
What kind of embedded ? If you just mean iPhone then it's simple.
For real embedded you need 'C', an ability to work with crappy toolchains without too much frustration, being able to program without relying on sophisticated debuggers and a knowledge of communications protocols. Knowing your way around a scope is handy too.
Buy some arduino boards and try it out.
The main problem is that most embedded stuff is in manufacturing/medical and they tend to hire people with N years experience and want an E-Eng qualification
ps,. One nice thing about embedded is that there is usually some organised engineering style plan! The hardware migth be changing as you are writing the code - but managers don't come along and tell you to add email into a Video editor or ask if your enterprise CAD app can run on that 'internet' they have heard about.
@mgb's answer is good. Especially the points about being able to program without sophisticated debuggers, a knowledge of communications protocols, and knowing your way around an oscilloscope.
To be really comfortable in the embedded world, you should also know how to read a schematic. You don't need to understand the entire circuit, but you do need to understand the digital pieces that you will be controlling.
Understanding protocols includes understanding both the common PHYs and the protocols you will have to write on top of them. You need to understand why you would put different protocols on different PHYs. You should have at least a conversational (and probably much higher) knowledge of SPI, UART, I2C, I2S, Ethernet, WiFi, BlueTooth, other 2.4 GHZ radio devices.
It helps to understand how the Linux kernel boots and some basics about the kernel and how to write drivers as well- As an embedded engineer, I see everything from 8 bit micros to CORTEX A8s cross my desk. In fact, it's helpful to have an idea of some of the different architectures out there and what the plusses and minuses are. Here are some of the one's I see a lot, (although different offices will re-use the chips they re-use over and over again when possible to save design time and library development): - TI MSP430 - ATMEL 8051 (ATMega, ATTiny, etc) - Cypress PSoC - PIC - Any ARM, including Cortex M3 and Cortex A8
What makes one architecture better than another for any given task? How do they compare in terms of power usage? What about in terms of processing capability. Which chips have decent tools? Which chips are better for prototyping and which for large scale factories and why? Which chips can you run a good OS on? What does a small RTOS offer over Linux and vice-versa? What about a small RTOS vs a bare metal application? In fact even with ARM, some manufacturers have amazing drivers and excellent mainlined kernels and others just don't. Starting to learn which are which can be the difference between a shipping product and one that never leaves the lab.
After working in embedded for a while you start to learn about how much processor, RAM and non-volatile memory you need to do certain projects. When you first get there you should be paying close attention to this.
Of course all the stuff I've listed here is too much to expect someone to learn before they ever start working in embedded, but a lot of it you can become familiar with in advance, and then enhance your knowledge. This is a short list of what it is important to know and pay attention to however to be a good embedded engineer. If you are a good programmer and know a bit about computer architecture and how machines work under the hood, most of this learning will come quickly.
What type of degree do you have? I work in defense with a lot of embedded stuff, and it seems like they like to mainly target electrical and computer engineers. There are only a few I've noticed with comp sci.
That said, if you are a strong programmer, that is all that should matter...however, it is a needed skill to understand the hardware and how it works to make you a successful embedded programmer. Nothing that you can't learn though!
Good luck!
I hesitate to suggest any reading material because the spectrum is so broad, you'd need to perhaps 'specialise' your goal a little more. However, www.embedded.com is a good place to start. From there you can subscribe to "Embedded Systems Design" print publication for free, as well as read the archive of articles, and enrol in Web-seminars and on-line courses. To get an overview of the kind to things you need to know as an embedded systems engineer, take a look at a syllabuses for appropriate courses; for example these courses, or if funds permit - get yourself on one of those (or similar local to you). It may be a quick 'conversion course' that will mitigate your lack of background as well as show a potential employer that you are serious. They are certainly quicker and more focussed than going back to college, though probably no less expensive, but then you don't need give up work for a year to take them.
"Embedded systems" covers a broad spectrum, from simple IR remotes to distributed process-control systems, telecomms switches, medical equipment, robotics, automotive, to name but a few. Either way it will help if you can read an electronic schematic or even have an electronics engineering background of some sort.
After 20 years, let's assume that your programming skills are up to scratch, but you have also to realise that often embedded systems are much more constrained that you are used to. Memories may be as small as a few hundred bytes of RAM and a couple of K-bytes of ROM, you may or may not have an operating system, or a file system, or network connection. And every system will be different, and customised for its intended purpose.
Some opinions expressed here on the quality of tools available are overstated (or stated by developers on very tight budgets). Many modern embedded processors have on-chip debug hardware that makes the debug hardware more cost effective. However don't expect the sophistication of Visual Studio, especially its debugger. The best you'll get often is Eclipse/CDT, with a GNU cross-compiler and GDB. There are more sophisticated tools from the likes of Green Hills, but those are for seriously big-budget projects. Tools for some 8 bit architectures can be highly constrained, but that is largely down to the hardware constraints, not the tools specifically. It is possible to use industrial PC hardware on high value projects, and then you are typically able to use much more sophisticated tools, or even the same tools you use for Desktop systems.
Couple of things to bear in mind:
If you've been using VisualStudio for much of those 20 years on Windows, I predict giving it up will be a real shock, especially if you lean heavily on the debugger. Try using just command-line gdb, say, for a while instead; if you can't deal with that as a way of life, stay well away from embedded!
20 years ago you were probably working on systems with less compute power and memory than all but the lowest end embedded systems today. Experience of working in those sorts of tightly constrained environments is valuable and an advantage you have over someone with only more recent desktop experience (if you can convince employers you haven't lost it all along the way).
Embedded is quite fun, you get to throw out most programming rules. Lots of freedom. You need to basically know assembler, not necessarily use it but understand what your code does at a lower than C level. Reading schematics is important as well. Go to sparkfun.com and look at the development boards, arm based or the arduino. Or get an ez340, or something from stellaris (now TI), and start playing.
Now defense is a whole other story, less than 1 percent of your time will be coding, the other 99% is procedure and paperwork. If you are into process, procedure, paperwork, and lower than average pay, then defense is for you.