Hi all
what are the debugging ways in arduino from the time the code was compiled and uploaded
to the board ?
Only leds are used or is there any software tool like simulator and/or debugger
that can be used like in keil compilers?
Eliaco
Emulators do exist, but I've never used any of them. I find that plain old print statements are the best debugging aid.
Print statements as a first line of defence. Even something simple like this:
void setup ()
{
Serial.begin (115200);
Serial.println ("Entering setup.");
// rest of setup
}
At least this shows if your program is restarting because you see "Entering setup" all the time.
Flashing LEDs if you have spare pins, and things are time-critical.
You can send debug information "over the wire" by I2C or SPI to another Arduino, which itself can show debugging. That way the device under test isn't slowed down too much:
Depends. If it's just software that I'm debugging then print statements work fine. If there is new external hardware to check out then simple testing software functions and my oscilloscope and digital meters usually fill the bill.
Lefty
I've always felt that the best debugging method was to not put bugs in in the first place.
Think like the computer. Think about what you are asking the computer to do with each thing that you type. Don't type stupid things.
Facetiousness aside, Serial.print() is the most useful tool in the toolbox, if used correctly. That is, one needs to print identifiers with numbers. Debugging from looking at nothing but a bunch of numbers will drive you crazy, and make us not want to help you. Knowing what the numbers mean makes debugging MUCH easier.
Debugging from looking at nothing but a bunch of numbers will drive you crazy
I suspect that has already happened to quite a few of us. EBCDIC dumps from COBOL/CICS on IBM S360/370 mainframes did it to me.
I suspect that has already happened to quite a few of us.
It's one thing when you have no control over the format of the output, as in a core dump. It's quite a different matter when the pain is self-inflicted.
And, yet, far too many people asking for help on the forum can't seem to grasp the fact that you CAN print text in front of a number.
It's quite a different matter when the pain is self-inflicted.
That's very true.
Slightly tangential, but the best debugging advice I can give is "test early, test often". Don't wait until you have a two hundred line sketch that doesn't work.
Slightly tangential, but the best debugging advice I can give is "test early, test often".
I don't think I have ever written more than 20 lines of code without thinking "I wonder of this will do what I think it will". I just get the urge to verify after each addition.
With the Arduino, that is so easy, I'm amazed at people that post 800 lines of code that they do not understand and that doesn't work, because it is fundamentally flawed.
"test early, test often"
Excellent advice. It was a bit of a pain when we still used card decks, but there's no excuse now.
You used a deck of cards! Luxury! We had to use paper tape! And the tape broke!
Aye, those were the days ...
wildbill:
Slightly tangential, but the best debugging advice I can give is "test early, test often". Don't wait until you have a two hundred line sketch that doesn't work.
Totally true. In fact, I have found that test-driven development has dropped my debugging time by 90% (no kidding). And debugging is 10x easier, because almost all bugs were just introduced 5 minutes ago so they're much easier to find.
And only add more functionality after all known bugs are fixed. Adding more functions will only make it harder to debug. If you do not fix it it will still be flawed.
Advice: add comments all over your code in order that: you can track your problems in your code (DEBUGGING it yourself), others can understand it (ie. on the forum), etc. Very helpful.
Yes, but it was fixable with scotch tape. Using plastic tape instead of paper meant you had fewer breaks, but you could get cut more with it.
Punch cards could be patched with tape, some spare card stock, and an exacto knife. Been there, done that.
I think it was posted here, if not some of the other places like slashdot, but somebody just recently used an arduino with a Canon camera that can take the hacked firmware to read 80 column cards, though most of the processing is done on the pc and not the arduino.
The good black punch tape didn't tear on me. That was the industrial stuff that ran the CNC machines and loaded programs in the NC machines. I swear, in years I never even heard of a tape break.
But the yellow tape they had in the HS to community college setup, that broke a lot!
Instead of cluttering everything with comments you might also consider version control (e.g. git). If you really insist on comments consider doxygen.
I use all three of the methods,, I document/comment everything special or really different. I use debug print statements (Great and easy to do on a graphics screen, there is a great deal of unused space to display the results of functions under construction)... and ANYTHING I make is modular in nature and the modules are extensively tested before I attempt to combine them into my Primary code. Since I am a total (almost) NOOB to C and C++ I assume nothing... because I at this point in time know almost nothing about C but I fortunately have the required DMM and a Good O'scope (Old Tek 2213) as well as various power supplies... Oh Yeah, I almost forgot... ASSUME NOTHING, TEST IT.
Doc
Unless your code is so simple it is obvious, you should comment the code at a high level (saying why you are doing something, not just echoing the code). This is extremely important in multi-person projects, but even in projects that you do alone, you might come back to after a period of time, and have no idea of what the program does without comments.
And yes, in larger projects source code control is important. In fact in my day job, today I came to the conclusion that the code I've been working on for the last day or two is somewhat broken, and I'm going to go back to the last checkpoint, and start over. But a source code control system doesn't replace the need for comments.
While I'm not in a management position in my current job, if you were my employee and didn't adequately comment your code, I would need to have a 1-on-1 talk about improving your coding style. I have done this in the past, when I was a manager. The idea isn't to come down hard, but to get the employee to the point that they are producing code that other people can understand as well.