Struggle continues to plug embedded programming gap

[johnbeetem]

There's an interesting article and comments at Geek Times on the subject of a how modern computer science programs are not preparing people for embedded programming.  It's similar to the problem RasPi is trying to address, but down at the bare metal instead of at the GNU/Linux level.

[JonB]

Hmmm. Well, if you want to get potential embedded programmers to go embedded, you have to start paying decent cash. Simple, really. Look at where the money is in programming – working for banks in the City (if we're talking about permanent employment). I've looked at embedded and real time developer positions before. I used to be a real time programmer, working on flight simulator system software (the proper ones with the 6DOF motion systems that airline pilots train on) and the pay was lousy. Was still true, last time I checked.

(Edit : Reading the article after posting, I see it is US-centric, and i am in the UK, where we have our own problems to do with failing education: Not "embedded programmer shortage looms", but "programmer shortage looms"... which is even worse!)

[jamesh]

We at Broadcom (UK) do find it very difficult to get decent embedded engineers in, and the pay here is pretty good. Not city standard (but then I don't live in the City), but keeps me in beer and skittles.

[walney]

JamesH said:


... but keeps me in beer and skittles.


As in "taste the rainbow" type Skittles?... you must eat a lot of them!

[MrBunsy]

Hmm, is it just me or does it seem like that article is barking up entirely the wrong tree?  I always thought of embedded programming as a far more Electronics/engineering area than compsci - certainly we (electronics guys) have done far more of it than the compscis at my uni.

[jamesh]

Depends. On the Videocore GPU we have mostly very clever people writing embedded code who come from CompSci backgrounds, not EE (not exclusive - we also have PhD's in maths etc). Mainly because at this level we are writing 3D graphics code, video codecs, camera code. But they still need to write code that interacts directly with the HW.

But then we are particular case.

[nick.mccloud]

JamesH said:


But then we are particular case.


Head or basket?

I didn't go to university to study EE (no money, no grant), ended up writing desktop project management applications (2/3rds of my time now), did some M2M work on the user interface side and got exposed (!) to embedded and then fell in to programming PICs & Atmel for the boss (wife).

I think a mixture of disciplines is a good thing.

[jamesh]

Indeed. I started (in '89) at high level, then to low level, then back to high level C++ (Windows Paint package called Satori), then back to low level until the present day.

I prefer mid level - just above the HW, but none of that PITA bit twiddling/oscilloscope tweaking on HW that doesn't work properly.

[Joefish]

I know what you mean.  When debugging comes down to writing out the 1s and the 0s on a piece of paper it"s a sign you"re getting a little too close to the metalwork.

Having learned assembly on a ZX Spectrum I like to think I"ve got a fair grounding in raw memory management, contention timing and the like, but it doesn"t necessarily mean (a) that I really do nor (b) that I want to do it all the time.  Though it"s always nice to see the occasional task that mentions "picoseconds".

[Lob0426]

Except for some messing around on Atmel (NerdKit), the last time I did any real programming you still had to type in line numbers. That was some 34 years ago in basic. Now I struggle to remember the proper order and syntax does not even look the same. lol. I found out the line numbers are actually still there if you want them.
Is there a good program out there that can help me learn C/C++ ?
Programming the Atmel seemed pretty straight forward. Of course it was already setup to use a USB (PL2303) cord. Right now basically using a notepad to edit and GCC to program.

I disassemble an Aero Garden and found a PIC controller, even the toaster I opened had a micro controller in it. They are everywhere.

It looks like the programming at all levels is suffering. Guess the next project for the foundation will be a Raspberry PIC! lol.

[riffraff]

... and the article begs the question: "What device(s) would a college level course in embedded programming standardize on?"

I could fill an entire dictionary with pejoratives and expletives I favor in describing prospective employers who are fond of the phrase "You don't get trained here, you get here trained".

If you pick some piece of crap device for your product that no one else uses, I'm damn sorry to disappoint you. No savior is going to walk through your front door with the perfect skill set to save your bacon.  It's your responsibility to select a good candidate who has some hardware background and turn them loose with datasheets and an eval device, or send them to a manufacturers seminar.

We have, or I should say have had, a handful of medical device manufacturers in my area who have in years gone by advertised for "specialists" in embedded device programming. It always seems to be an afterthought. It would seem that if you have an engineer capable of designing the rest of the device, that's the individual you need to send for training... oh, you don't have an engineer... oh, you don't have a prototype...  you have a block diagram of a concept... on a paper napkin... how nice.

@Lob0426

And I would suppose the toaster was Chinese?  You don't hear them whining about this, do you?

[Chromatix]

Worth noting that many microcontrollers these days outmatch the minicomputers of several decades ago, or the microcomputers of circa 1980.  The main difference might be that a rich programming environment (BASIC, libc, job control) is not automagically laid on for you.  When an ARM core can be squeezed into less than a square mm, on process nodes that are almost considered obsolete already, and can still achieve 100MIPS, you'd better believe it gets used for anything and everything.

At the same time, the term "embedded programming" encompasses a wide range of things, from directly manipulating hardware with 256 bytes of RAM in a microwave oven, up to a complete Linux environment with a multicore GHz-class RISC CPU and several GB of RAM and storage that just happens not to have a traditional desktop or input hardware.  Even realtime requirements are not ubiquitous, though they are common.

FWIW, games consoles are technically embedded systems.  The game industry therefore absorbs a lot of potential talent.  This might also be your main competition in terms of salary and job satisfaction.