Poll: Would You Be Interesting in an ESSENTIALS on Debugging?

Some thirty years ago I developed the knowledge to understand and apply the "half split method" for troubleshooting electric circuit. Since that time, I have tried to apply the knowledge to help me debug. My formal background is electronics but my career path has taken me to computers and designing systems. It would be nice to have someone that has developed effective debugging techniques share their secrets. Sure would make my coding less arduous.

'Dancing blue robot debugging' ?

Rubber duck debugging

https://en.wikipedia.org/wiki/Rubber_duck_debugging

Ganssle now makes a living out of proposing the absurd.

Even in his opening phrases on debugging he's into the nonsense; suggesting that software is unique in the proportion of time spent debugging.

It isn't, most significant human endeavor involves multiple attempts, prototyping, testing, debugging etc.

I'm not suggesting that it isn't a good idea to try to get things as right as is reasonable, first time - of course it is.

But pretending that proving that some code does what it's specification says it does will solve all software problems (or all problems that can be fixed by software) is just plain daft.

The biggest problem is not addressed by Spark, Ada or much else - and that is getting the specification right.

Look at Boeing's problem with the MAX737, as far as we know the code did what they meant it to do, the problem was that the single sensor was duff.

No amount of proving the code was correct to spec would make any difference. (Other issues noted.)

In the real world people do ask me to make box A talk to box B with no detailed specs of either. We make stuff to do the connecting and debug it.

Just the same as if you asked a builder to put a porch up over your front door, a bit like the one at number 7.

I wouldn't recommend that you use my box interface specced as it was to control a nuke, or the porch as a bomb shelter.

Ganssle's failure is not to grasp that, for an awful lot of stuff, "Good enough" is good enough - but he gets paid for his rants.

That's my rant (nearly) over - debugging is your friend - cherish it !

MK

Debugging might be useful. However, I can't resist posting a link to an Embedded.fm episode with Jack Ganssle: https://embedded.fm/episodes/2014/5/27/53-being-a-grownup-engineer

If you want to his opinion about debugging, head to 22:20 . I recommend hearing the whole episode (and also some others with James Grenning with test driven development approach, to get different opinion).

Yes, a LED is so useful, it can be left blinking occasionally via a long period timer ISR just to show the system hasn't locked up and to confirm it is still powered - very handy when there are no other visible peripherals like an LCD. Many of my microcontroller projects start with a 'splashscreen' which may as simple as to flash the main LED's a couple of times using a delay function I made, this confirms I/O is setup correctly and that critical timing is good i.e. the clock rate is now known.

Good point.

Every micro design needs, iff possible, an LED, a test pin connected to an IO pin and access to the UART as well as access to the on chip debugging pins.

The LED can let you do some kind of debugging without any tools at all.

The pin is needed for timing -  can be incredibly useful.

The UART for proper messages from the code.

And the on chip debugger makes everything 10x easier if its available.

MK

That LED technique has been so useful over the years, it is worth adding an LED to new designs just for this purpose.

LEDs are everywhere, what would we do without LEDs?

Maybe an essentials just on LEDs would be appropriate.

I'm going to own up here: When I don't understand an IDE's debug capability I revert to other approaches -  using infinite loops or delays to blink an LED, message the screen or UART to signify the code has successfully reached a certain place. I think it is always a good investment of time to understand the debug function in any software IDE, being able to check values are as expected and the code flows to where it should (e.g. great for picking up errors in C when = and == are used incorrectly and the code piles on through regardless ! )

Looking forward to this Essentials

I'm always interested in debugging - I spend a lot of time doing it.

If you commission a series then please:

1) If at all possible make it vendor neutral - to my mind several of the "Essentials" have been far too vendor specific. Consider two or more authors with different vendor expertise.

2) Get a couple (at least) of Top Members or other experts to review it before it's posted.

3) Pick an area - the subject is too wide for one article to cover everything, maybe best to start with micro-controllers:interfaces, because nearly everyone goes there.

MK

I am also interested in avoiding them in the first place :-)