low-level programming geekiness

[cjsmith]

I don't talk about work details much, 'cause either they're so minor they're meaningless, or they're something my company wants to talk about before I talk about it. But every so often there's a tidbit I can share for my geeky friends.

You know you're a real Embedded Systems Programmer when...

...you find and fix a bug that involves changing this code

var--;

to this:

disable_interrupts();
var--;
reenable_interrupts();

Extra bonus geek points if it doesn't happen reliably, doesn't happen in the debugger, and/or takes a long time to reproduce. More extra bonus geek points for not having been the one to put that bug in there in the first place.

That was late last week, and I was pretty proud of it, actually.

Comments

[lesliepear.livejournal.com]

That looks like a nasty bug to track down.

What language is that - C or C++ or something else?

[cjsmith.livejournal.com]

C. It was indeed nasty to track down. Adding breakpoints would, as you might imagine, change the timing of the entire thing, and the bug wouldn't occur. So no traditional debugging. I was glad when I found that one!

[wispfox.livejournal.com]

*shakes head* Damn interrupts!

I hated interrupts when I was in CS in school. Exactly because of how thoroughly it kills debugging!

(I note that I am not a programmer now)

[cjsmith.livejournal.com]

Amen! Either you've got a debugger carefully customized for your system, aware of interrupts and able to "backtrace" out of them by reading the right weird registers... nah, even that wouldn't have helped for this one. We simply didn't give it the capability to halt all involved hardware within one clock cycle. When your processor's talking to (or listening to) something else, debugging is challenging.