Interesting. I'm considering doing the exact opposite (10 years web/server-side development - switching to embedded). Currently, I'm taking some extension engineering classes at UC Irvine while still working full-time.
Any ideas on where to start to get my foot in the door in the embedded world? I was thinking newbie kernel bugs and eventually Linux drivers.
The linux drivers idea is good particularly if you want to learn about communication with embedded system. But there are other approaches too.
You'll need to ask yourself how low-level do you want to go. For example:
Do you want to work on a system that has an OS, utilities, filesystem, etc such as the ELDK[1]?
Or a little more stripped down with only the OS such as FreeRTOS[2], uClinux[3], or uC/OS[4]?
Or even lower and use no OS at all. Use instead a foreground-background system--basically a forever loop.
Another way of doing this is to select the hardware first according to what you would like to do. You must keep in mind that you will most likely not have access to all the debugging tools that you're used to. This translates into very expensive compilers and debuggers for the high end hardware. But these days it seems that there is something for every taste and wallet.
Two particular development kits that come to mind are Arduino boards [5] and TI's MSP430 development kits [6]. I find the wireless watch development kit [7] particular interesting. I haven't used either.
If you see something that you like, try to find the corresponding development kit that comes with a development board, cables, and software.
A good place to start is by checking DIY or hacker magazines such as Make[8].
In most of my course work to-date it's been with no OS and just a while (forever loop) driven by interrupt service routines.
Currently, I use an AMTEL AVR 2560; however, I've heard good things about the TI ones.
I honestly don't know where I want to focus yet. I figured I'll continue to take some more classes to get some breadth on the subject. Once I have a better idea of what peaks my interest I'll jump into the depth for a more specialized approach when I can make a better educated decision.
Good call on Make. I've been meaning to check it out, but haven't gotten around to it.
Thank you for all the resource links. I really appreciate your response.
I'm glad that you like the info. I see that you're working on very low level stuff. Can you go even lower and deal with sensors, resistors, capacitors, opamps, and the like? These days there is a reference design in white papers somewhere so you don't need to be and expert in electronics to get away with something that works. You just need access to the tools such as multimeters and oscilloscopes.
I'm thinking sensor networks. If you can, then I would recommend to try something using the MSP430 for example, given its low power requirements. Take the microcontrollers and pair them with different sensors (eg., IR, temperature, etc) and an RF module such as xbee [9] in order to create a mesh network [10]. You'll need to work on the protocol and management side too-- a linux box somewhere with a database but that should not be a problem for you. But I realize that is more of a team project given the amount of work.
I mention this because I see some activity in this field and lately I've seen several articles, mostly in The Economist, that talk extensively on how sensor networks and the system that manage them will encroach our daily life. So if you can't figth them, might as well join them.
I'll be taking a DSP and RF class soon - so, yes, I'll be able to go lower eventually :-) My background is in CS with the bare minimum of EE. For the most part, this is all new to me.
I'll take a look at the sensor networks. Thanks again.
Sorry for taking this long to reply. Lots of errands to do.
An embedded programmer is a catch-all adjective I think. One could be working on very low level programming of microcontrollers (e.g., PIC32, MSP430) and FPGAs [11].
On the other end of the spectrum, you can find embedded programmers working on embedded devices that hosts complete systems with OS, filesystems and utilities such as the ELDK (referred in previous posts). The duties for such programmers include creating device drivers for the specific devices that the product has. I have for example, modified an existing application developed originally for a system with no OS into a Linux application running on a PowerPC board. For example, some of my duties were to modify the original application's absolute FLASH memory references to a method compatible with what the Linux based system offers (hint: I used mmap).
I would guess that someone like yourself with limited exposure to electronics would be guided toward the latter type of jobs. From my limited experience in my local area I believe that this type of jobs offers the best balance. Latter on you can move deeply into low-level development once you have beefed-up your resume if you so desire.
The trick here is to be identified by a competent manager that can match your education and experience to his needs. And you`ll be surprised how little managers need to know, technically speaking, to get a product going which means that you need to sell yourself well.
Senior positions depend heavily into the nature of the company. I find that importance given to hierarchy between employees is proportional to the amount of bureaucracy present. This translates into defined roles, which will need to be created (i.e., company is growing) or the position becomes available (i.e., because of retirement or lay-off). So for example, if you want to become an architect where you actually design a product or part of it; it will be harder in a big company. Smaller companies suffer less from hierarchy and give more chances to hold important and challenging positions but the pay usually lags far behind the bigger companies.
The best ways to get a job depend largely on the type of jobs available which are dictated by the companies implanted there. Where I am, there were several small companies that needed someone that could wear lots of hats. That`s how I started back 10 years ago. I had to manage a small network, program an 8-bit HC11 microcontroller, design the PCB, select the electronic components, do some soldering, do some mechanical design, and train the client and fix the bugs once the product was out the door. This path has led me to be a generalist rather than a specialist.
But I talked no long ago to the guy that was my boss back then, and he said that these days is cheaper to contract out the small jobs to specialized shops which wasn't the case back then or at least he wasn't aware of competent companies that offered a reasonable cost. So things do change. Be prepared to turn on a dime.
I think that you should not have too many problems going the embedded way. But you'll need to help the hiring person to match your skills to their needs. They may just assume that they need an EE just because they're working very close to the hardware. I think that you have a bright future. One of the most competent embedded programmers that I've met did a BSCS.
I hope I did not go ramble too much and loose you in the middle. Just one more thing. Remember that your worst enemy is yourself. Don't let self-doubt and/or laziness to get in the way. Control those and you'll have a good future.
Any ideas on where to start to get my foot in the door in the embedded world? I was thinking newbie kernel bugs and eventually Linux drivers.