Hacker News Reader

Comment by Paul_S | Hacker News Reader

Why doesn't real embedded development work this way?! This is awesome and I want it to be real.

This is the distilled greatest moments of embedded development because in reality I spent today ~2 hours doing a code merge, ~2 hours of work logging and other bureaucracy, ~1 hour of helping testers and ~2 hours of reading schematics and hunting down hardware issues with an oscilloscope and spectrograph.

View on HN

I am about to spend the next four hours repetitively power-cycling my device.

You poor soul, I hope you have a power button. I eventually bought a power brick with a built-in switch.

Yes. But actually the fix I'm testing didn't work, so I've spent the past 5 hours trying different things. I'm now on what I think is my final solution, so here goes another four hours of fun.

There's no romance in embedded development.

Ok but for real that last bit sounds fun to someone not in the field :)

I can see why it sounds fun. 40 pages later of dense schematics that you're desperately trying to match to what you have on your desk you'd realise it's 90% frustration and 10% headache. It's like navigating a city with a map showing cracks in the pavement split into 1000 individual one page puzzle pieces and written in Chinese (sometimes literally). God forbid someone made some modifications along the way at which point you might as well call it a day and bugger off to the pub. Now THAT last bit is actually good.

Hang on, are you describing work or the game?

Work, I gather, though the game also includes a bunch of (to laymen) dense schematics, one of which is indeed in (what looks like) chinese. So.

All of this talk about how miserable embedded development is makes it sound like these guys need more automated tools. Is there not a fuzz testing machine for embedded electronics prototypes?

I'm with you.

I once spent days trying to figure out why a 10 hour timer on a battery charger chip was going off hours too early, leading to the device draining its battery instead of charging it. Turned out the manufacturing partner had substituted another part, functionally equivalent except for the one feature we were relying on...

I can't remember what it was that made me actually look at the chip to check the part number.

As a fellow embedded guy, my problems are usually something stupid simple that I assumed was true, but wasn't.

An example, 'why won't this chip work!?', 5 hours later and a full driver written, 'oh, I just didn't turn on this one pin. now it works great!'.

Also, in relation to your last sentence, assuming that the hardware you have (resistor and capacitor values) are the same as what is in the schematic.

Reply on news.ycombinator.com