[pocoloco]

I'm currently working on a set of SOAP web services using tomcat, cxf, mysql, and hibernate among others.

I decided to do a switch from embedded to web development about a year and a half ago after being laid off. My paycheck is smaller but I now work on a whole new set of problems. After working about 10 years in embedded and everything around it, I felt that I needed a change. It was as if I was solving the same problems over and over. And don't get me started in the state of the tools. I remember thanking the heavens when we switched platforms to PowerPC and ELDK.

At first I did not know were to start in web development. But I did decide to concentrate on the back end quite early. At first I approached each technology separately, mostly because of my ignorance. For example, I saw that tomcat was very popular, so I decided to take a look into it. But I quickly realized that I needed a birds eye view of the whole web service stack and not its individual components. At least not yet.

I started to look into frameworks. After realizing that there are lots of those and that I learn about a new one almost every week, I had to narrow my search. I've been working and learning Groovy on Grails which is all based on the JVM since then. What sold it to me was the fact that Groovy is a language very similar to Python, which I know, and that Grails is a web framework that integrates all the necessary technologies to get a decent site up and running thanks in big part to the amount of plugins available for it.

Like grayhairmomma says, it's a humbling experience.

[mgkimsal]

Interesting approach to getting in to Grails. I came at Grails after about 12 years with PHP (and some Perl and other stuff too). There are a number of things I like about Grails (GORM, domain-first approach, etc). But there are still some things which bely the Java-ness of it, and I'm convinced most of the Java community doesn't "get" the web. Hard to put in to words, but an example might be:

http://jira.codehaus.org/browse/GRAILS-3364

The default in the Java world up to that point (and possibly still is) is to put a session ID in the URL. That's been frowned on and not default behaviour in the PHP world for... well since almost always. It's just asking for trouble (intentional or accidental). But the default for Grails was to have this on, because that's just how Java people think.

And the answers? Configure yet some other aspect of your system ("just change jetty's config"-type answers). Why not give more control to the framework instead of forcing people to have to learn/manage yet more systems and components. That particular issue is 'fixed' now, but there's so many moving parts that I wouldn't be surprised if it is broken again in some configurations (hasn't been for me though).

As much as I love Grails, Java as a base platform was not written with the web in mind, and makes basic stuff harder than it should be.

[pocoloco]

I did suspect that an experienced web developer will feel some heaviness when using a framework such as Grails. I'm simply too new at this to have an idea of all the little issues that arise when using the JVM.

Thanks for the link.

[weej]

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.

[pocoloco]

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

I hope this gives you an idea.

[1] http://www.denx.de/wiki/DULG/ELDK [2] http://www.freertos.org/ [3] http://www.uclinux.org/ [4] http://micrium.com/page/home [5] http://www.arduino.cc/ [6] http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=9... [7] http://focus.ti.com/docs/toolsw/folders/print/ez430-chronos.... [8] http://makeprojects.com/

[weej]

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.

Cheers!

[pocoloco]

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.

[9] http://www.digi.com/products/wireless/point-multipoint/xbee-...

[10] http://en.wikipedia.org/wiki/Wireless_mesh_network

[weej]

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.

[r0h4n]

what kind of a career path does a embedded programmer has? what is expected at senior positions in such jobs?

how to get a foot into a entry level job? I am not a EE guy. doing a BSCS.

[pocoloco]

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.

[11] http://en.wikipedia.org/wiki/Field-programmable_gate_array