To help, it would be nice if each line sent its line number out the port.
Yeah, not possible
Absolutely possible; use LINE.
The program to "remove" the lines is the C pre processor, and it actually leaves them in place but just treats them a little differently.
There are plenty of references to debug macros and conditional compilation.
You have to be careful that their presence doesn't cause your code to behave too differently.
From what I can gather about that command (term?) that is for when an error happens.
I don't really know what is happening, but when I am doing things, I see weird things happening.
What I am looking for is something to constantly send data out the serial monitor port telling me which lines are being executed.
That is a big task as the sketch is way longer than I would care to have to manually add each alternative line to send the data out the port.
So, granted there is/may be a "command", how do I get it included so each time a line is done, I see the number?
Doing a search with Mr Google and what was said is interesting, but beyond my understanding and though what I am reading as I said: I think that is more for what a big error happens and the sketch actually falls over.
I am rather wanting to track where it is going BEFORE it dies.
No, you misunderstand.
Predefines like FILEDATE and LINE can be used anywhere you like, it is just that they are perhaps most likely seen in released software when something really bad goes on, usually via an assert().
About the third Google hit I got for "debug macro" looks a useful starting point.
There's little or no point putting such trace points everywhere, only at points where the execution of the code takes a different route, like function calls or conditionals, so putting them in should not be too onerous.
And also to be able to remove said lines once I am happy
That's the clever bit; you don't ever take them out, you simply get the pre processor to ignore them.
if (j > 3)
Serial.print("2'");
{
lcd.print("hello");
Serial.print("3");
}
Your debugging code here alters the sense of the program. What it really is equivalent to is:
if (j > 3)
Serial.print("2");
lcd.print("hello");
Serial.print("3");
So your attempts to debug have changed program behaviour. Always a problem with debugging.
There is no magic bullet to debugging. A scattergun approach like putting a serial print every line is likely to just confuse you, and alter program behaviour. You need attention to detail, and to carefully examine your code, your output, what you expect to get, and what you actually get.
Can one of you guys explain how to use #ifdef
kind of thing so he can put in all the Serial prints he wants, and then change a value at the top of the sketch to have them enabled or disabled?
You mean like in the site I linked to above, starting at line 8 in the listing, and subsequently explained?
The important thing to remember about software is it is not malicious and it won't ever do anything "randomly" unless told to do so, or unless something very, very bad has gone wrong. Making sure bad things don't happen is the most important thing to do.
As has already been explained, Heisenberg's Principle applies here; observation may affect the observed, so be very, very careful.
If you have, as you say, several hundred lines of C, adding a trace print each and every one of them is going to be counterproductive; you ARE going to run out of RAM, and weird stuff WILL happen.
Even if you don't run out of RAM, you will swamped by the volume of output, as anyone who ever tried "TRACE ON" on a large BASIC program will attest.
So, pick where you think you need the detail, and be careful.
Don't pack consecutive traces into long tracts of linear code that cannot possibly branch.
Text debug macros are a very common debug technique, and I've used them on platforms from multi-processor, multi-core servers with gigabytes of RAM (with the ability to change the level-of-detail of the output dynamically in a running device driver) right down to tiny Arduinos.
BUT you have to recognise the limitations.
If you are that keen to see what your sketch is doing line-by-line, I suggest the effort would be better spent getting a simulator set up. Making your sketch print a message as every line of code executes is going to take a fair amount of work and the end result is unlikely to be useful.
