I just made a post worthy of Captain Obvious, suggesting some things that the OP could do to proceed with some debugging. Suggestions that I'd be mildly ticked to receive myself because they are well, so bleedin' obvious. But apparently they aren't.

Perhaps I've been writing software too long, but I consider debugging skills to be basic life skills; if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

How then do we see so many posts where folks haven't even taken a single step down the debugging path? Are they already overwhelmed with the complexities of the coding they've done? Does simply it not occur to them? Are they unaware of the tools (limited though they may be) that can be used?

I wonder if a section on the subject in Nick's sticky thread would be helpful.

billroy

This is an important question that I think about a lot, and I'm glad you asked it.

I think the emotional aspects of debugging are often overlooked. Discovering that the program you created is malfunctioning has an emotional dimension, right?

Consider the five stages of a bug:

1. Shock2. Denial3. Anger4. Bargaining5. Acceptance

The helpless ones you are describing are stuck in shock/denial. That is why it is so hard to direct their focus and attention.

The frustrated ones are stuck in the anger stage. We've all been there. Kind of hard to focus.

It's the ones who are past the anger and looking for answers/bargains that we can help with technical advice.

In my view, people stuck in stages 1-3 actually need emotional / social support more than technical support, until they can get back to the state of mind required to articulate the problem and accept guidance to focus back on it so they can solve it themselves.

if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

One day a few years back, my next-door-neighbour asked my wife if we knew when the power was coming back on. My wife replied that as far as she knew our power was on, but checked a light and yes it was. My neighbour had gone the whole day, literally, with no power and hadn't checked her breakers. She assumed a) it was a power company problem and b) that we would have reported it.

imho Debugging is the art - science? - of finding the errors in code (and/or hardware), the analysis of why the application is behaving other than expected / intended. The rest is fixing. Debugging and fixing is not always done by the same person. I see in complex cases you have pair/group debugging and single person fixing quite often.

I recognize the 5 stages billroy mentions, but there are more:- stage 0: Unaware (ignorant?) and..- stage 6: the ability to recognize and // after coding- stage 7: the ability to prevent and // while coding- stage 8: the ability to predict. // before coding

example of 8: I know that I make mistakes with complex boolean expressions, so I can predict that there will be (big chance) bugs in itmaybe 7 and 8 should be swapped?

if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

Because there just might be an oxide buildup on the contacts....I've actually done the same basic thing shoving connectors (sometimes on boards) in and out and gotten $#!+ to work.

I was in a truckstop the other day, there was a truck there that wouldn't start, I spoke to the driver and he was distraught because he needed to get into the city for whatever. It was clearly an electrical problem so I asked if he'd checked the fuses. No he hadn't and he was waiting for a $X00 callout from a mechanic who couldn't get there for a few hours.

You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

Power switches are nondeterministic, therefore the POPO approach often works!

So, if debugging is the art of finding and removing errors in code, that must mean programming is the art of putting errors in and we should refer to programming as "bugging".

If that is the case then we should end up with nothing after we find and eliminates all the bugs from our programs.

I think programming is expressing your idea in every necessary detail with bugs in them cause your idea is partly flawed and your execution is partly flawed. After debugging, you will have a working implementation of your modified idea with less bugs.

I think programming is expressing your idea in every necessary detail with bugs in them cause your idea is partly flawed and your execution is partly flawed. After debugging, you will have a working implementation of your modified idea with less bugs.

I like this definition. I marked the things that meet my experience in bold.I can think of 1 experience I had you do not explicitly mention. Adding that to the definition gives me.

Quote

Programming is expressing your idea in every necessary detail with bugs in them; cause your idea is partly flawed and your execution is partly flawed. After debugging, you may end up with a working implementation of your modified idea with less bugs.

best regardsJantje

Do not PM me a question unless you are prepared to pay for consultancy.Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

Thanks Jantje! Just my life experience. Just my most recent experience (not exactly debugging code): I plugged in an AC adapter and used it to power a motor shield for my project. I then ran some motor test code with "motor" (just two LEDs twisted back to back with a serial resistor so I can see green for forward motor and blue for reverse). For quite a few trials I can't find why the motor won't move. Out of frustration I unplugged USB and tried to power the thing with ac adapter, which is when I realized my board is not powered at all. Checked the power strip, I only had one conductor plugged in the socket and left the other one out (was fumbling with the adapter without enough lighting). Easy enough, when power is supplied, the motor starts to turn. I think if I have learned anything over my almost 3 decade programming experience, I learned to not trust myself but it is hard to do.

Not at all computer-related, but my f(l)avourite debugging story, ever.

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.Do not send technical questions via personal messaging - they will be ignored.I speak for myself, not Arduino.