#224 STOP using Serial.print in your Arduino code! THIS is better.

Great explanation! new follower here!

For the esp32 there is already a library included from espressif called esp_log.h then you can use e.g. ESP_LOGD() for debugging prints

I believe you know your add 1 never changed the value of counter!
I do have an ESP32, I may go get the log lib. Will it have issues if I add the printf for the arduino or do you know?
Lee

Thank you. It's very helpful!

Confusing

I've watched so many videos with demos that show the serial output on a separate window, but I can never find anything showing how it is done. My output always shows at the bottom of the IDE 2.0 sketch. Will you please explain how to set this up?

Can I use printf with serial software?

thz a looooooooooot, no more // in // back in the code kkkkk

Genius idea! I'm pretty picky about my code but every once in a while I forget to take out one of these statements. This is a far better idea. I can even use multiple debug variables to turn different sections on and off as needed. Thank you, sir and my you have a great and prosperous day.

Very nice Ralph. I've watched this a couple of times, and picked up things each time, as I'm new to this stuff. I really like the way you explain things. Effective and entertaining as well.
Personal thought: When you change the code during the video, you use a Screen Transition. It sometimes causes me to get lost and I have to "find my place" again on the screen of code. I know you do this to save time and not show backspacing the code and rewriting it, but since you are explaining it anyway, I think I would rather follow along as you do so. Just my personal thoughts. Thanks. Regards

I am a mech engineering student and I am doing a 99% electrical project for my research dissertation. I spent weeks trying to figure out why my sketch has been printing data every 0,033 seconds (30 Hz) instead of 1kHz+ as it should with timer interrupt. Now I know why........
I really appreciate the video Mr. Bacon. Highly informative and needed!

This looked very informative, unfortunately the content is just too long and I just got bored with it. However, it led me to Google a solution which could've been covered in 5 minutes so for that I'm grateful.

Just Brilliant!

Brilliant and very entertaining thaks

Thank you very much, Ralph! That was exactly what I was looking for!

Brilliant video Ralph

This code demonstrates why I have always maintained that case sensitivity is poor programming language design. In this code we have two keywords that differentiate solely by case significance (i.e. DEBUG vs. debug). This generates poor legibility in the code because of possible confusion reading the code. Well, I've heard, one simply places guidelines on coders not to do this. WHAT!? Guidelines? I much prefer to force compliance to avoid mistakes. This also has the benefit of not having to remember if it is printLn, println, PrintLn or PrintLN, or any other such silliness. Simply type println and move on. The other argument I've heard is about interfacing with other code in languages that do have case significance. One is going to have to declare the interface in some sort of definition, the compiler simply uses the declared case for the link tables and ignores it for internal code. My philosophy has always been to make things easier rather than more difficult and case significance just makes things more difficult for everyone but the compiler programmers.

Great video, BUT...... I find it strange that no one commented on the fact that your code is wrong, it never updated the 'counter' since it is defined as "0" at the beginning of the loop. LOL But that wasn't the point of the video.

Or you can just remove them? I work with a moderate 50k lines project and we never leave the logs when we merge something. I can't possibly think of a situation where you leave 50 of those things around in a microcontroller project.

Lovely explanation of text substitution macros! I've understood them for years, but still enjoyed following along and seeing how they were explained. I'd link this if someone was struggling with them.

On another note entirely, one of the little yellow messages sent me down a rabbit hole of memory and hypotheses. :) "We'll talk about single-step debugging another time... for larger processors that support it." Single-stepping has been around the whole time I've been interested in coding, so that I'm almost sure I've seen it on the 6502! :) But I could be wrong, it's been a long time. I guess an in-system debugger (which was the only kind most of us BASIC kids could have in the 80s) could implement single-stepping without hardware support by copying each instruction in turn into a special subroutine within the debugger. But I don't know, I'm hypothesizing. :) Besides, this was all for assembly language. A source-level debugger for a high-level language is a bit harder for me to conceptualize. Perhaps it could single-step by automatically placing breakpoints. I know we had breakpoints without processor support. I think they were implemented by writing jump or call instructions into the code, saving what was originally there.

Really helpful trick with define debug :) Many thanks!

Thanks you very much! Excellent explanations and very useful ! will use it and promote it in our association ;)

Cool!
I plead guilty of writing and leaving a Serial.print at every other real code line and figured that those wasted storage space and execution time, but since I have only toyed with simple programs and have not hit space / speed problems, I have left that in the "to be addressed eventually" bin.

Nothing like the present:
- I opened a new empty sketch and added the compiler substitutions you suggested, but using "avisar(x)" in spanish so it would be obvious that that was not native keywords,
- saved "nuevo.ino" (also in spanish) in my syncthing-ed arduino projects directory, and
- pointed arduino.sketch.inoBlueprint to the full path of the modified file.
Then I remoted to my linux machine at home, started the IDE there, opened a new empty sketch and bingo! There it was with the added lines!

One less problem ...!

printf is working on my esp32 without adding any libraries. Have not tried it on a atmega.

Maybe some useful information well hidden under WAY TOO MUCH verbage.

Very interesting and useful thanks

I had defined a debug() function as a wrapper for Serial.print() and it checked a DEBUG constant whenever it was called, but it was compiled in the program and at each call to this function, the µC had to evaluate this constant. Your solution is so much better! Thank you!

if you would define the debug functions as regular C functions, and have a boolean that can turn them off (make the functions do nothing), shouldn't the compiler detect that all that and actually optimize the code such that the debug functions are not even encoded to any processor instructions.

The "solution" is to just use regular JTAG hardware debugging. The microcontroller has all the debugging features you could possibly want. It can automatically halt at a specific line of code and let you step through line by line while vieweing the contents of it's memory. It's the standard way of debugging microcontrollers and has been since like the 90's. There's really no need for some primitive debugging techniques like printing serial messages.

So close but it works. If there is an error your doing something wrong.
I wish people understood what Arduino is, this takes it outside/beyond the architecture of Arduino, that's why printf is not included.
Call it "C" or "C++"

Very useful topic but man! You waffle way too much.

varargs lol

hi sir.. what is the name of your serial monitor software..it seems so good.
thankyou very much.

I needed that for such a long time! Thanks!

And if i need to pass 2 argument like : Serial.println(rtc.getAddress(), HEX); ?

thank you. I had something similar, where i had a bool and always put the Serial.print inside an if statement.

Well done Ralph, I like it!