Printf debugging when you don't have a console

| 8 Comments

There's a nice story over on "Bug Babble" about debugging a problem with a robot by using various sounds coming out of a speaker to determine where in the code the problem occurred: "Now the robot sounded like a modem trying to connect. We would repro the hang and based on the pitch at 'flatline' we knew the point of the last successful call to the sound driver."

Via Google Translate and Radium Software, which also suggests using the CapsLock key, or changing display colours to debug gnarly problems in a printf style when you don't have a console to use for output. As you know, I'm not a fan of trace logging, but sometimes, needs must.

Hmm, so is the next killer blog tool automatic language translation on the RSS feeds that you subscribe to?

8 Comments

Reminds me of the days when I used to write computer games on the likes of the ZX Spectrum, and we used to change the border colour as various routines were hit in the code... Looked a bit like the tape loading screen, but with more steady bars that were sized according to the amount of processing taking place... One could tell whether 'the green' routine was in need of some careful optimisation as it grew too large etc. ;)

It's always nice to have an output method of last resort. Back when I was working on the Series 91 at Encore over a decade ago, the lowest level "can't ever fail" form of output was the back-panel LEDs. I noticed that there happened to be eight of them. It wasn't much later that I started adding low-level debug info using those eight LEDs and delay loops to flash ASCII. It sounds ugly, I know, but it really did save my bacon a few times. You can't exactly step through an SMP scheduler or paging subsystem in a debugger, so you take what you can get.

You'll be happy to hear we did not leave our tracing in the robot. Perhaps if all asserts emitted a high pitched screeching noise devs would remove them? I agree with your stated goals for removing asserts and tracing, however I'd attack the problem differently. Asserts and tracing should be a part of the design, and active in the retail builds.

Your blog looks to be a gem.

Steve

I agree that error handling and tracing should be part of the design and "first class" code. For applications where tracing is a requirement for support it should be designed in the same way as the other parts of the app. There's a world of difference between proper logging/tracing for use by support staff and what usually passes for 'debug tracing' in most applications.

My "default" position of the standard approach being "evil" is intended to limit the use of the "easy" option and encourage a little more thought being put into the actual problem at hand.

I have no idea what you mean by "what usually passes for 'debug tracing'" and "the standard approach".

VJ, go read the original postings; here and here for my views on how many people use debug traces and why it's wrong (we've had this discussion before in the comments of the first linked post). The standard approach, based on my experience seeing lots of people's code as a consultant, is that often developers create trace logs which are just a mess of debug information that may once have helped solve a particular bug, perhaps. What the people who need to support the application want and need is often very very different. Application logging for support purposes should be designed in to the application, if required, and is as important as any other part of the application. Debug traces are not application logs; generally. Assuming that they are just leads to unhappy support people.

I recall on slashdot that the ipod linux folks actually output the ipod ROM via its piezo speaker, recorded and decoded the sound. Here's the link: http://hardware.slashdot.org/article.pl?sid=05/01/29/2017244&tid=222&tid=176.

That's very cool :) Thanks for sharing.

Leave a comment