Go Down

Topic: Troubleshooting software – lost art ? (Read 8053 times) previous topic - next topic

Vaclav


I am an opinionated OF ( old fart)
After spending around a month on Arduino forums I am of an opinion that VAST majority of nice folks here are dreamers without a slight clue how to dissect their code to identify and CORRECT errors.
I spent years fiddling around pBasic and there is a nice fellow with 30000 plus posts and majority of them are "call customer service " and / or read "What is a microprocessor".
There are oodles of on-line information, books etc on Arduino - mostly with pictures of boards with colored wires on how to wire resistor and LED etc.

The field on how to debug code is pretty barren.

I would suggest to the Arduino "founders / administrators" a new forum

" Course 101 : How to troubleshoot your code "

I am sure many software gurus here would not mind coming up with their favorite methods to share.

Cheers
Vaclav

robtillaart

Quote
I am sure many software gurus here would not mind coming up with their favorite methods to share.

failing software => back to design => paper and pencil ;)
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

AWOL

Don't put any bugs in in the first place. Duh.

JimboZA


Quote
I am sure many software gurus here would not mind coming up with their favorite methods to share.

failing software => back to design => paper and pencil ;)


When I learned Fortran in 1974, we spent a huge part of the first term learning to draw flowcharts. Whatever system is used- and there are loads of different techniques- the key thing is to design the program first.

Seems thinking first has fallen by the wayside, yet who here would consider building a house without a set of plans?
Johannesburg hams call me: ZS6JMB on Highveld rep 145.7875 (-600 & 88.5 tone)
Dr Perry Cox: "Help me to help you, help me to help you...."
Your answer may already be here: https://forum.arduino.cc/index.php?topic=384198.0

AWOL

Quote
yet who here would consider building a house without a set of plans?

I have a hard time convincing people that even when they do start building, they need some scaffolding too.

JimboZA


Quote
yet who here would consider building a house without a set of plans?

I have a hard time convincing people that even when they do start building, they need some scaffolding too.


That's a Project Management issue, not Engineering's problem   :P
Johannesburg hams call me: ZS6JMB on Highveld rep 145.7875 (-600 & 88.5 tone)
Dr Perry Cox: "Help me to help you, help me to help you...."
Your answer may already be here: https://forum.arduino.cc/index.php?topic=384198.0

AWOL

Up to a point, but unless you use F(), it can bring about the collapse of your whole building project.

westfw

Troubleshooting a well designed program written by an experienced software engineer is a much different task than trying to figure out what is "wrong" with some jumble of code assembled from three of four online examples by an artist who isn't really sure (and can't describe) what they want to do in the first place, where the (hardware) pieces they're using are poorly documented modules shipped from who knows where that may or may not be working.

I mean, these were sort of fun, and I tried to include a bit of info on how I debugged the problems.
http://forum.arduino.cc/index.php?topic=196612
http://forum.arduino.cc/index.php?topic=201649

But I've really tried to stay out of the "direct port writes don't work inside a for loop" conversation.

It's like... The standard troubleshooting technique consists of poking around to see what is going on inside your program that disagrees with what you expect to be going on.  Which requires that you have a reasonable idea of "what to expect."  Which a lot of people don't have (and it's not REALLY an easy thing to get, either.  "It looks like your GPS code is never logging a location, because it's not seeing the checksums that are expected to be at the ends of NMEA sentences" is a lot to expect from someone who had a reasonably expectation that they could throw together a "GPS Shield" and "GPS Logging example code" and have a working logger...)

427v8

well you are on the arduino forums...
Deep into hobbiest space here.

And arduino doesn't even have a debugger, so it's all printf debuggnig.

My fave tool for debugging is the serial port. I print out state and values so I can see how the beast is running.
I do have tools that parse the output, but that is way over the top :)

Vaclav



Quote
yet who here would consider building a house without a set of plans?

I have a hard time convincing people that even when they do start building, they need some scaffolding too.


That's a Project Management issue, not Engineering's problem   :P


And here lies the root of the problem.

A hobbits MUST be both and some. I worked with a manager who was appalled that our group of "testers" actually knew and worked on both hardware and software.
I believe that anybody who wants to build a gizmo must have at least minimal knowledge of hardware ( and software).
Without that making the LED blink is a major challenge despite that there are, to my knowledge, two examples of such "project" in Arduino IDE.
Majority of folks in here are robot and robotic builders lacking taught or intuitive troubleshooting and managing , if you really insists on they term, skills.  Simple tracing of code flow seems to be major challenge.
Unfortunately until there is a "how to" cookbook, FAQ, stickies etc.  this Arduino forum will continue to have questions posted which can be answered by just finding similar ready to run code in examples.

I would like to know % of folks  posting "problems"  here with knowledge of "preprocessor"?
How many times have anybody seen  "#define DEBUG 1" in troubled codes posted here?

Cheers
Vaclav

Vaclav


well you are on the arduino forums...
Deep into hobbiest space here.

And arduino doesn't even have a debugger, so it's all printf debuggnig.

My fave tool for debugging is the serial port. I print out state and values so I can see how the beast is running.
I do have tools that parse the output, but that is way over the top :)

I am not sure, but one of my firts, if not the very first, post was about " where is debugger"?
I could not believe the answer i got - "you do not need one, it runs in loop" !

AWOL

Debuggers are tricky to implement in flash-only architectures.
For hobbyists the added cost isn't worth it.

Vaclav


Debuggers are tricky to implement in flash-only architectures.
For hobbyists the added cost isn't worth it.

Have you read "The inmates are running the asylum"?
One of the comments in the book - the  "software engineers"  will use the path of least resistance in development.

Cheers
Vaclav

retrolefty

The best troubleshooting tool is a good brain, the rest is just jewelry.


AWOL

#14
Nov 30, 2013, 08:31 pm Last Edit: Nov 30, 2013, 08:59 pm by AWOL Reason: 1
Quote
Have you read "The inmates are running the asylum"?

Nope, never heard of it.
Quote
One of the comments in the book - the  "software engineers"  will use the path of least resistance in development.

I have no idea what that means, nor what point you're trying to make, but then most noobs here tend not to be software engineers.

I'm a Linux systems engineer; mostly I work in kernel space (no safety net) with little more than printk to debug with.

Go Up