As I decided to have an argument with a very sharp craft knife, my typing has slowed down considerably. It may take longer to respond to your comments. Sigh. github.com/RalphBacon/224-Superior-Serial.print-statements/blob/main/Thumb%20Argument%20With%20Craft%20Knife.jpg

@flemmingchristiansen2462

2 жыл бұрын

It would seem that you lost that argument. 🤦‍♂️

@gg-gn3re

2 жыл бұрын

hey at least you can't miss the space bar anymore

@RalphBacon

2 жыл бұрын

Yeah, space bar, b, m, n, comma all in one go!

@bbowling4979

2 жыл бұрын

Ouch! Sorry to hear that. Hopefully it wasn't too bad and didn't hit anything important.

@RalphBacon

2 жыл бұрын

My thumb _is_ important. Well, to me. And my soldering iron.

STOP using "STOP this and that" clickbaits!!!

@RalphBacon

4 ай бұрын

So WHY is this click bait? EXPLAIN!

@joelincz8314

4 ай бұрын

Sadly KZread requires every title to have a little bit of clickbait into it or your video won't be recommended to people. When I saw the title I was intrigued but never did I think I could never ever use Serial.print. It was on topic. So clickbait percentage was low, usefulness high for a lot of people. @RalpBacon: Thank you for the title or I would have never seen this. And thank you for the video. My 13 teen your old daughter loved it as well (we are learning about the Arduino environment together).

@SeaTurtle1122

4 ай бұрын

It’s entirely truthful, and it makes more people click on the video completely for free. Why on earth would he stop?

@BeardyMike

4 ай бұрын

​@@RalphBacon 100% it's a clickbait video title.... But as a newbie programmer this kind of information is incredibly useful, and I wouldn't have found it without your clickbait. I think this video is a great use case for clickbait. Experienced Devs will know what you're going to do within a minute or two, and everyone else can stay for the explanation and demos.

@DaveBuildsThings

4 ай бұрын

@@BeardyMikeI totally agree. Took the bait and enjoyed every bite. I've never seen #define used in Serial.print statements before and found this video extremely useful and informative. Just as a side note, you can also use #define debugbegin(x) Serial.begin(x) to remove the serial begin statement as well. Initializing serial takes up memory as well. Thanks for the great video! 👍👍👍

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!

@RalphBacon

10 ай бұрын

Glad it helped you!

Hi Ralph, Just want to say that I enjoy watching your videos. The content is interesting and your presentation style is entertaining. Thank you!

@RalphBacon

2 жыл бұрын

Thank you very much! Glad you're enjoying them.

Thank you so much Ralph, not just for this video but your channel in general. You've taught me so much, and you have a very pleasant way of teaching things. Keep up the good work :)

@RalphBacon

2 жыл бұрын

I appreciate that! Sharing is caring, as they say!

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.

@RalphBacon

10 ай бұрын

Glad it was helpful!

I have to say that this "simple" method of deactivating debug statements has to be a winner for all the reasons you highlighted. I will be using it big time. thank you for such a bright shining light on a very simple way round the problem. Even simpler than having all the debug Serial.print statements inside IF debug on THEN.

@thorbjrnhellehaven5766

2 жыл бұрын

one reason for IF debug on THEN, would be to be possible to enable/disable by input. you would save time, but not size.

@joselepage7572

2 жыл бұрын

0

@RalphBacon

2 жыл бұрын

Indeed, I dislike wrapping all my Serial.print statements inside #if...#else...#endif as it destroys the layout of my code. I find this a neater solution!

@thorbjrnhellehaven5766

2 жыл бұрын

@@RalphBacon the precompiler approach is realy nice to save size, where size is not an issue, comiled if-statements can be nice to enable/disable debuging on the fly, for troubleshooting without recompiling and loading new binary.

Thanks @Ralph for this video. It's one of many differences between a beginner person and more advanced /experienced person. Pre processor directives is amazing.

@RalphBacon

2 жыл бұрын

Glad it was helpful!

Interesting topic! But, imho you shouldn't blame the Serial.print statements for slowing down your program when you are not doing the house keeping after debugging by removing those print commands.

@RalphBacon

2 жыл бұрын

Well, yes, it's always the responsibility of the developer to "tidy up" after coding is finished; I'm hoping this will make it so simple that they will do it. And learn something about pre-processing whilst they're at it!

@makers_lab

2 жыл бұрын

Yes, however it can also be beneficial to have certain debug / trace logic kept in place so it's ready to be used when adding future enhancements, and testing at release level performance can be necessary while still developing and needing debug code. So for both scenarios, a way to knock out debug code while it's still present in the source is useful.

@forbiddenera

2 жыл бұрын

Uh but what if your code is timing sensitive? Doesn't necessarily matter about cleaning up after. Also, sometimes serial is used for communication and often s.p is used for that too

@billferner6741

2 жыл бұрын

@@forbiddenera the topic was serl.print for debugging, not project messages. Those time need to be considered in a project.

@haroldfinz4863

2 жыл бұрын

Deleting debugging statements after debugging is like throwing away the sponge after the dishes are washed. Complex programs are rarely, if ever, completed and bug-free. And most programs are susceptible to changes in their environment -- e.g., libraries, or 3rd-party connectivity policy changes. It's helpful to build in a way of retracing your steps without having to "re-do from start"

#Define calls the pre-compiler and does a ‘find & replace’ before compiling the code. As a computer science student, a loooong time ago (1985), I had to write a C pre-compiler as an assignment. It wasn’t very difficult but I’ll never forget the use of pre-compilers.

@RalphBacon

2 жыл бұрын

Quite so. The modern IDE (not Arduino classic) does have some intelligence regarding precompiler directives which makes it even more useful.

Very informative Ralph! I'll be incorporating the printf and your preprocessing into my future work. Thanks Very much!

@RalphBacon

2 жыл бұрын

Good stuff, Gord, glad it helped.

@gpTeacher

2 жыл бұрын

@@RalphBacon As you folks on the Island say, "Works a treat! Thank you! I'm learning to fly RC airplanes and need a countdown timer for the battery life. My new project. This trick is working nicely. Sorry to hear about the knife wound. I've been redoing the back deck and my hands are full of slivers. I hear ya.

Great solution and great explanation. Will use this in future. Subscribed

@RalphBacon

4 ай бұрын

Awesome, thank you!

great tip! just wondering what happens to the semicolon when the debug statements are replaced with nothingness. i assume it stays, but empty lines are not compiled into the final program. or would it be useful to include the semicolon in the define statement?

@RalphBacon

2 жыл бұрын

Extra semicolons get ignored; you can include them as part of the define but that might upset the syntax on the rest of the line that you're using the define. Best to keep it as part of the code, the compiler will remove it anyway.

@bwimtg

2 жыл бұрын

@@RalphBacon great, thank you for the clarification!

I had no idea you could #define a function in this way. That's amazing. I was using a bunch of if statements around the serial stuff, but this is much better!

@RalphBacon

2 жыл бұрын

That's what drove me to doing this, John. I was sick of all the #if...#else...#endif statements everywhere, destroying the layout of my beautiful (ahem!) code.

@JohnDlugosz

2 жыл бұрын

That's a good indication for reading through "The C Programming Language" or other reference material once a year or so, to remind you of things you may have forgotten or overlooked before.

@mikepennington8088

2 жыл бұрын

@@JohnDlugosz There is a book by Henry F. Ledgard called Programming Proverbs (short title). It was one of our textbooks in school. It contains a lot of good advice. One of the best pieces is Re-read the Manual. The point is that a lot of what you encountered on previous readings may not have been well absorbed because it had no good relevance or contextual framework within your needs and experiences. As you progress, you encounter new situations which make the relevant and re-reading the manual will allow you to now see how things previously glossed over are now of use.

@i8BBQ4Lunch

2 жыл бұрын

@@JohnDlugosz I remember that4 book. Now retired, during my career I used C occasionally and every time it kicked my but. POINTERS!!! What are they pointing to, addresses, variables, names of variables! Pull my hair out. ;-(

I consider myself a beginner and i have never considered this before. I was wondering how there can be almost 30 minutes of video on this topic. But im so glad i took the time to watch it. It was very eye opening to me and informative!

@RalphBacon

5 ай бұрын

Glad it was helpful!

@MakerMike-bx5ms

5 ай бұрын

@@RalphBacon most definitely! Thanks so much for taking the time to put together this video!!! Merry Christmas!

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

@RalphBacon

Жыл бұрын

Glad it was helpful!

#if DEBUG_FLAG == 1 #define debug(x) Serial.print(x) #define debugln(x) Serial.println(x) #else #define debug(x) #define debugln(x) #endif This code snippet adds a great value for this video thank you very much , can make your mic little clear so audio is perfectly audible

@RalphBacon

11 ай бұрын

Thanks for sharing 👍

The initial statement was that Serial.print slows down the microprocessor (and it does) and that's why you will propose a better solution. In fact, the solution doesn't offer an alternative. I just shows a way to enable/disable all the Serial.print lines :( Not quite a solution!

@therfnoob7697

Жыл бұрын

yeah, no real solution and too much ads at the beginning...

@RalphBacon

Жыл бұрын

I believe it shows a _better_ (and more efficient way) of tailoring your Serial output.

@gutrali

Жыл бұрын

​@@RalphBacon How would one use the optional second parameter which specifies the base (format) to use; i.e. Serial.print(0x61, HEX); ?

Hey there Ralph. Another great video; informative and entertaining. I'm going to add this to every sketch I develop from now on. It is just to simple and easy not to do.

@RalphBacon

2 жыл бұрын

Fantastic! I'm using it right now in my current sketch, Adrian, and it works very well! It can be tweaked as required too, or the Advanced version can be used (in my GitHub).

👍👍👍👍👍 Thank you, thank you,, I had just come to the realisation of why my code and memory usage was changing and realised I needed to take out all the boating "print" statements. But now you have given me a way to manage debugging in a nice convenient way, so thank you for your video and your help. ...!! Very much appreciate learning how to write better code. ...!

@RalphBacon

Жыл бұрын

You're welcome! Glad you are finding it useful, Philip.

Removing Serial.print() statements from your code is as simple as a Ctrl-F to find them to delete them. Doing so is the same as cleaning up after any job; doing the dishes, putting away tools, or using toilet paper. Cleaning up (or "linting") software code is what any good programmer does. It involves deleting commented-out lines, unnecessary blank lines, excessive comments, etc. Though your #define debug(x) and its associated conditional compiler directive will keep those lines from being compiled in the final version, the debug(x) lines will still be littering the code, impairing long-term readability (even for you after time passes), and adding lines (and associated scrolling) that have no value in the future. Let me just add that there's a click-baitiness to the video title: STOP using something everybody uses. It's a tactic similar to videos that say, "You're Doing {something} Wrong." The current video has been cluttering up my feed for a long time, and I've been ignoring it because it looked like click bait. But I finally thought, "Fine, I'll just see what he says." And I was right: click bait and nothing I think is very useful. You don't even actually advocate stopping the use of Serial.print() debugging. You just show a way of globally deactivating it when it's served its purpose. I understand, of course, that you got credit for my view anyway, and the algorithm is giving you credit for my "viewer interaction." You got what you want, and by complaining about it now so have I. You win, I win.

@RalphBacon

3 ай бұрын

Not at all. Removing the Serial.print statement removes a level of documentation from your code that you might well need when (if?) it goes wrong. You put it there originally for a reason, right? Using the method described here keeps it in place but removes it, conditionally, from the compile process, thus putting away the dishes after washing up. 🤣 But allowing you to instantly (well, after a recompile) to reinstate them. After a few decades as a pro developer I've valued decent comments and print statement in code (not just mine). By the way, this was not click bait of any kind. I thought it described my video perfectly as I believe we should indeed STOP using standard Serial.print statements (in the ESP32 world I never use them, using the built-in conditional debugging levels instead). You didn't find it useful, fine. But don't tell me that I'm into sucking you in to watching a video you don't find value in. That's what the STOP 😁 or BACK button is for.

@MattRiddell

3 ай бұрын

@@RalphBacon 🤣 100% agree. You even covered it in your video. "Crap, it's broken again - let me put them back in for a sec". This is real world programming. It's not the same as academic programming. Sometimes you have 1 day for a turnaround POC. DRY isn't the best way to do things. Obviously he's right once you move into a final production product that will never change again, but how often does that happen? We're always iterating

@davidhawley1132

3 ай бұрын

You should rationalize your debugging code and only leave in what is likely to help in the future (because now you know what helped), review what remains to make sure it has no side-effects that would break your code if it was removed, and then use C# preprocessor directives to control whether you include the debugging code in your executable. A more sophisticated version of the above is to define a set of debugging levels, again which you control by preprocessor directives. Finally, if it is possible in your environment and seems warranted, add some kind of logging, using the same levels strategy as for debugging.

Thanks for the information; a useful reference. I have got into the habit of using a DEBUG definition and then wrapping each of my debugging Serial.Print commands in an #if....#endif block, but this way you showed is a much more elegant method that I hadn't thought of before. I am by no means a beginner, but never ignore information like this aimed at beginners, as sometimes I find I've been set in my ways and they aren't necessarily the best!

@billglass5160

2 жыл бұрын

I was ready to say exactly the same. This method avoids my adding all those #ifdef's. I always start my programs saying I'll only need 1 print so I don't bother with the #define debug. Finally I end up with many more prints and many more #ifdef's.

@RalphBacon

2 жыл бұрын

I'm sure everyone experiences the same as you, Bill! Me included. I mean, the next sketch will be so simple what could possibly go wrong? Oh.

@billglass5160

2 жыл бұрын

@@RalphBacone

@billglass5160

2 жыл бұрын

yes!!!

@janikarkkainen3904

2 жыл бұрын

My thoughts exactly. While watching the start all I kept thinking was "well, just conditional compile them by wrapping them it #ifdef DEBUG's", but it never occured to me I could alias/macro it all in/out that way. And I mean, I'm not really a beginner either, and I've used both conditional compiling with #ifdef's and macros, but it just never occured to me I could shorthand all of this this way. This is one more confirmation to the idea that it's never wrong to re-review basics even if you are "an expert" - there's always a possibility you've missed or forgotten something useful.

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

@RalphBacon

Жыл бұрын

Glad it helped you, John!

Nicely done. Stumbled across your channel, while stumbling along relearning coding after over a couple decades. I'll be checking out some of your other videos, I see some very interesting topics which may be useful on my planned projects. Thankyou, RH 😁😁

@RalphBacon

Жыл бұрын

Welcome aboard! There is always a link to a pdf in each video description that contains a list of all my videos, so you can search for keywords. Happy viewing!

@RelentlessHomesteading

Жыл бұрын

@@RalphBacon Thankyou. I've already loaded a number of those videos to my watchlist. Appreciated your nRF24L01 video - implementing that on a current project here. Seems you've 'been in the game' for some time - as one who started programming by punching holes in cards I can appreciate that. My first 'development system' was one I had to DIY as my University did not have any way to load programs. 🎵🎶 ...Oh that was a long time ago - LOL Thankyou.

You can do a proper inline debugging with a JTAG programmer on the ESP32

@RalphBacon

4 ай бұрын

Yes you can, and I covered this in video #261. Works well enough.

@NicksStuff

4 ай бұрын

@@RalphBaconGreat

This was very long winded about a standard programming method.

@RalphBacon

2 жыл бұрын

It's not "standard" if you've never done it before, is it?

@bknesheim

2 жыл бұрын

@@RalphBacon Even if you have never used a metric unit to measure something, it is still a standard. The same can be applied for programming techniques in C, C++ or other languages.

@Invatator

2 жыл бұрын

I wonder what "standard programming" you are referring to. IoT is a different beast and an entirely different ecosystem for the hobbyist. Not everybody knows this...like Ralph said...its not standard if they don't know about it or never read it, experienced it, and no tutorial or documentation I've read the past 3years mentions it. 😉 That being said, try and be considerate of hobbyists. Thank you

@bknesheim

2 жыл бұрын

@@Invatator The information is important because the use of #ifdef in C and C++ do make it a lot easier to remove/include debug code. It was the time to get there i criticized because I think that many that could have need for this will fall of and watch something else before he gets to the point. Close to 30 minutes is long bit long. "and no tutorial or documentation". It is "funny" how often that can be a problem since the programmer that write it can so easily forget that even very basic techniques most be learned and #ifdef is something you learn early. It is not perfect and have problems, but it is a simple and easy way to control your debug code.

@Invatator

2 жыл бұрын

@@bknesheim that's what I mean, ...I don't think I have "proper basic" introduction to C or C++, and used it last time before Arduino like 10-15 years ago, and Arduino feels a bit different. Ifdef define and other "optimizations" don't seem properly introduced to Arduino hobbyists...just "how to get fast through the door". Anyhow...are those concepts you talked about in the C/C++ basics? I can dig out old books if any...as I'm really interested in making my microcontrollers performant and improve myself

Great tools Thanks for sharing your experience with all of us 👍😀

@RalphBacon

2 жыл бұрын

No problem 👍

Thanks! Really nice explanation of how to do functions using the preprocessor.

@RalphBacon

2 жыл бұрын

Glad you enjoyed it!

When I first saw this video being suggested to me, I thought this was an advisement against using Serial.print commands for passing information between microcontrollers and computers, so this was a bit of a surprise. On the other hand, I guess this is down to personal code style preferences, as I'd much, /much/ rather NOT use custom-defined preprocessor "functions", as that severely limits what you can pass into them. Given the fact that I've been using C and C++ for years, along with the preprocessor's very powerful replacement system, I'd rather use "#ifdef DEBUG" blocks around the code specifically handling debugging. Plus, this practice highlights your debugging code more strongly than yet another apparent function call that doesn't get coloured as such by the syntax highlighting.

@RalphBacon

2 жыл бұрын

It's a case of horses for courses, Daryl. Use whatever works for you. I personally hate the #if...#else...#endif construct for debugging statements, but if you don't mind the strange formatting this brings it's not a big deal. I just thought I'd share something I use myself. I think it's useful for hobbyists and beginners rather than professional C++ programmers, but that's just my take on things!

@vasiliynkudryavtsev

2 жыл бұрын

Nowadays, good compilers will eliminate dead code. Thus, I usually use simple VERBOSE adjective before the Serial.print/printf or blocks doing debug prints, which I defined before as "#define VERBOSE if(0)" or "if (1)". For the different levels of verbosity (e.g. -v -vv -vvv flags) can be done by "#define VERBOSE2 if(verbose_level >= 2)", etc. #ifdef #if look quite ugly, but I also use them in some cases, it's good alternative to have commented out section of old/different code.

@alexstone691

2 жыл бұрын

@@vasiliynkudryavtsev i love that, im gonna use that from now on for debugging

@vasiliynkudryavtsev

2 жыл бұрын

@@alexstone691 I'm glad, my experience helps.

#define DEBUG 0 #if DEBUG == 1 #define DebugBegin(x) Serial.begin(x) #define Debug(x) Serial.print(x) #define Debugln(x) Serial.println(x) #else #define DebugBegin(x) #define Debug(x) #define Debugln(x) #endif

@RalphBacon

11 ай бұрын

If it works for you then it works! I haven't tested this but I might give it a try in my next sketch!

@GermanMythbuster

10 ай бұрын

@@RalphBacon Yes it works very well

@simontillson482

5 ай бұрын

Making a DebugIf(condition, x) is good too. This allows you to have other debug symbols, such as DEBUG_SERIAL, DEBUG_PWM etc. Having DEBUG=0 to switch all debug printing off is useful for a production build, but having all of the prints running when DEBUG=1 can be very tiresome to read, and obviously makes your code very much slower. This more fine-grained approach allows you to just show the debug prints that are relevant to the part you’re working on / testing.

hello Ralph A few weeks ago I just learnt what #if meant and now thank to you I have an application for it, thank you Ralph.

@RalphBacon

2 жыл бұрын

I knew you were learning this, Robert (obviously) and thought you might benefit. Glad it was helpful!

Definitely going o use this, thank you!

@RalphBacon

4 ай бұрын

Great!

A slightly better, more correct way of defining your debug() macros to do nothing is #define debug(x) ((void)0) instead of really nothing. Please remember that these macros in the actual code are followed by semicolons. So now when they expand to nothing, you have lonely semicolons left in your code. This might sometimes lead to compilation errors and even logic errors. The macros expanding to ((void)0) avoid the empty semicolon problem.

@RalphBacon

Жыл бұрын

Hmm, you may be right but empty semicolons are not a syntax error: while (1) { ; } is perfectly legal (and what my IDE insists on converting an empty while(1); to!

@StateMachineCOM

Жыл бұрын

@@RalphBacon One example where the empty debug() macro will cause a compilation error is: a ? foo() : debug(...); This will become a ? foo() : ; and that won't compile. I understand that this is a contrived example, but you'd be surprised how "creative" people might be in using your stuff. (For example, people might create their own macros based on yours, which might use something like that.) My point is that it does not cost you anything to define debug() as ((void)0), which will prevent all (or at least most) such corner cases. I like your presentation. I just wanted to help...

@RalphBacon

Жыл бұрын

Yes, your suggestion is a good one, and the, er, ingenuity 🤔 of developers cannot be underestimated 😜. So, to prevent potential problems your suggestion is good and I hope others read this comment thread in case they are having some weird compilation errors when using my alternate use of debug.

@GkTheodore

Жыл бұрын

@@StateMachineCOM Thanks for pointing out a question I had. I tried your suggestion though and it does not compile. Just leaving the thing empty it does. Mind you, I am using Wokwi's emulator and not the real thing. Nevertheless I would like to thank ALL the people who make helpful videos like Ralph and those who make constructive comments and suggestions like Quantum.

Click bait. Stop using Serial.print but still uses it as a #define. You are still using Serial.print and makin it more complicated then it needs to be.

@RalphBacon

2 жыл бұрын

Thanks for the feedback.

I needed that for such a long time! Thanks!

@RalphBacon

Жыл бұрын

No problem! 👍

This was extremely helpful. Thanks a lot and keep up the good work.

@RalphBacon

Жыл бұрын

Glad it helped!

#define DEBUG #ifdef DEBUG Serial.begin(9600); Serial.print(debug message); #endif if you comment out //#define DEBUG and then compile it, all your serial functions should be removed in the compiled bin, well as far as i understand it anyways. just using an if debug == 1 is not enough as your still doing that check. Also #ifdef is already part of the sdk and you wont need a lib for it.

@thomasrichter3635

2 жыл бұрын

I would also recommend such an approach👍I always define myself a function that wraps around the serial.print function. Inside of this wrapper function i will have the #if ... statement. With this you can keep your code a little cleaner, as you don't need precompiler statements in every print call, you just call the wrapper function☺️

@RalphBacon

2 жыл бұрын

Yes, removing the Serial.begin is very doable and ensures the entire library is removed by the linking process.

Blimey....15 minutes to get to the point...... Still it was actually quite a nice idea, eventually :-)

@RalphBacon

4 ай бұрын

Just 15 minutes, Jack? I must remember to pad it out a bit more! But seriously, setting the scene for beginners is essential. Glad you (eventually) liked it though!

Thank you so much. I never realized you can do that type of define outside of a header file or such. You need more of these videos haha. Add a member button to your screen too. I don't expect anything in return but you work hard and deserve for the community to pay you back if they want.

@RalphBacon

Жыл бұрын

You're very welcome!

Very nice! I am implementing this idea immediately!

@RalphBacon

2 жыл бұрын

Go for it!

Normally I love your videos but I have stopped watching anything entitled, "STOP doing !" So please stop doing that.

@RalphBacon

5 ай бұрын

The irony of you stopping watching videos that tell you to stop doing something is not lost on me! Anyway, you missed a good video, and have perpetuated the use of Serial.print in your sketches. Deffo worth watching!

I recently came across your videos and have found them very informative. Subscribed

@RalphBacon

2 жыл бұрын

Welcome aboard! Always appreciated when viewers become subscribers 👍🏻

Hi Ralph, thanks again for a video that solves a problem that I/we have been having for some time, I like the new video timeline chapters

@RalphBacon

2 жыл бұрын

Glad it was helpful!

I have been using FOR AGES bool debug = true; if (debug) { Serial.print("my text here or whatever") } and thats it... Okay thank you. And I am sure a lot of people are actually doing it this way. Why do I think its better? Because you can fast an easy create differen Serial debugs for different tasks. like add another one that shouldnt be run with another. bool debug2 = true; if (debug2) { Serial.print("my text here or whatever") } And so on.. makes it even better and faster

@RalphBacon

2 жыл бұрын

Having granularity with debugging is a good idea; if you look at the Advanced example in my GitHub you will see a variant of this, where I have Verbose, Debugging, Warnings & Errors selectable as debugging level too. But now I'm thinking that having some descriptive debugging names like you suggest - good idea, thanks for sharing!

@jamess1787

2 жыл бұрын

function debug(text){ if (debug){ serial.print(text); } } 😁 + Indentation //I wonder if there's a way to detect if the potential of the tx pin changes....... Could enable debug when something is plugged in.... 🤠

Use capital letters for defines and constants. Video could be 5 minutes to explain such simple method.

@RalphBacon

2 жыл бұрын

Not really. Beginners need a detailed, step-by-step approach and an explanation of _why_ we do things - no sudden jumping to conclusions or they get lost and switch off. Yes, I use CAPS for constants but I'm not always a fan for #define names.

A word of warning: If you define a symbol to be an expression, put parentheses around the expression to make sure that they evaluate the way that you wish. Example: #define ratio( x, y ) x / y if you use ratio in the following, you will not get what you intended float a = 5.0; float b = 10.0; float c = ratio( a, b ) ** 2; The expected result would be 0.25 (= 0.5 **2 ). UNFORTUNATELY, the compiler was presented with x / y ** 2 The operator precedence of C/C++ will perform the exponentiation first and the the division. This means that c will be 0.05 ( 5 / 100 ) If instead, you change the define to be #define ratio( x, y ) ( x / y ) then the expression seen by the compiler is ( a / b ) ** 2 which is what you wanted.

@RalphBacon

2 жыл бұрын

A very good point you make, Michael; many libraries will contain all the #defines in "(" and ")" just to be sure (and UPPERCASE).

Very useful video Ralph, thank you.

@RalphBacon

2 жыл бұрын

Glad it was helpful!

You dragged a 3 minutes video way too long but it's a great concept for beginners.

@RalphBacon

2 жыл бұрын

I'm glad you said "it's a great concept for beginners". Imagine yourself being taught to drive a military tank. (I hope you don't have military service, especially in a tank 😲). Do you think 3 minutes of instruction is enough to even get you to move the tank forward (without destroying everything in its path)? Put yourself in the shoes of a noob who needs every single thing explained in a clear and concise way. At least once. Ideally more than once. That's why it's as long as it is. 😜

@eglintonflats

2 жыл бұрын

3 min video is too short for google to plant any adverts. Therefore, no money. Get it?

Good but you talk too much, gets bit boring .

@RalphBacon

3 ай бұрын

My middle name is boring. Ralph Boring Bacon. That's me. 😲

@edinfific2576

3 ай бұрын

You can always stop watching, nobody is forcing you.

Thanks for this great tip! I have a couple of further suggestions: 1. Use all caps when you define a macro so you can tell the difference between a function call and a macro because macros are expanded before compile, and sometimes this is important to know. 2. Surround your macro definition with '"{" and "}" so that multi-statement macros will be guaranteed to behave even if you don't know they're macros. As example, a multi-statement debug macro will compile fine and yet misbehave in code that looks like this: for(i = 0; i debug("foo");

@RalphBacon

2 жыл бұрын

Good suggestions, Jeff, thanks for sharing. 👍

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

@RalphBacon

10 ай бұрын

I'll bear your feedback in mind the next time I do a code walkthrough. 👍

Thanks for the information; a useful reference. you're just a regular bucket of knowledge!🍓💪

@RalphBacon

2 жыл бұрын

I appreciate that!

Excellent, thanks Ralph. Very useful!

@RalphBacon

2 жыл бұрын

Glad it was helpful!

Excelente. Saludos de Mar del plata, Argentina. Gracias.

@RalphBacon

2 жыл бұрын

Muchas gracias, Jaun. Me alegra que hayas encontrado útil el video. ¡No olvides ver mis otros videos también! Pues, hasta luego!

Nice video, just used this in my code and the speed increased considerably

@RalphBacon

Жыл бұрын

Great, glad to hear it!

Thanks Ralph I'm just starting out with Arduino at the my late stage of life but I find it very cool. I look towards many more of your videos.

@RalphBacon

Жыл бұрын

Best of luck!

Hi Ralph, very interesting and useful stuff, I haven't done much coding lately but with winter on its way I tend to start again, I shall be trying your recommendations out....cheers.

@RalphBacon

2 жыл бұрын

About time, Andy, get your coding pencils sharpened!

Thanks, good content as usual. Cheers.

@RalphBacon

2 жыл бұрын

My pleasure!

I have switched to this some months ago after watching this. Is working well for me.

@RalphBacon

Жыл бұрын

Excellent news, Terry, always good to have some longer term feedback.

Thank you very interesting and I have now used it !!!

@RalphBacon

2 ай бұрын

Glad it was helpful!

Really helpful trick with define debug :) Many thanks!

@RalphBacon

Жыл бұрын

Glad it helped!

I'm definitely one of those beginners who haven't done that sort of thing. Great vid. An excellent example of how precompiler statements can be used. Now I have to see if works with my PIC MCs. Thanks for the tips.

@RalphBacon

2 жыл бұрын

Glad it was helpful!

In my personal library I made a header that replaces serial.print with spr or sprl, and I can enter up to 4 different parameters. It's compact, very easy to type, and much more clear to read. Also, with one line of code or even an input wire, I can disable all serial prints at once to speed up the program

@RalphBacon

2 жыл бұрын

Sounds like you've done a similar thing then, Nathan. I think most coders eventually devise some method of doing this, thanks for sharing.

This was very helpful, thank you👍

@RalphBacon

2 жыл бұрын

You're welcome!

Genius! Nice one mate!

@RalphBacon

Жыл бұрын

Glad you think so!

I'm just beginning Arduino and found this video by happen chance. What a good idea!! I've subscribed👍 PS Does the 'S' in your name stand for smoky?

@RalphBacon

5 ай бұрын

Welcome! And the S stands for 'streaky', at least the boys at school told me that 😆

What is amazing to me is that it has taken you all this time to figure this out. ALWAYS remove debugging code from release versions. I use a #define and #if statements to turn on/off serial.print and other debugging code.

@RalphBacon

2 жыл бұрын

Absolutely, I couldn't agree more.

Great information! Thanks for the video.

@RalphBacon

Жыл бұрын

Glad it was helpful!

Really great explanation of some "micro-knowledge" that we old hacks use all the time, but is counter intuitive to others. And a great explanation of the value of the CPP macro language. I know CPP has an 'evil' reputation - but this is a great example of where it shines. Also, the nice thing about your example is that the debug is completely removed from the final version of the .exe. Supurb. I'm going to subscribe. Continued Success!

@RalphBacon

3 ай бұрын

Welcome aboard! I'm glad you found this video useful (or at least interesting) --- hang on, what's this all about C++ being evil? 😲

@drfrancintosh

2 ай бұрын

@@RalphBacon C pre processor... macros have been maligned for decades

Valuable reminder of good practice but worth stressing that any testing needs to be completed on the debug-stripped version of the code ... can’t count the number of times I’ve been chasing bugs generated by accidentally non-included or over-defined values not apparent until the effects of the def changes played out. Keep up the great work 😀👍

@RalphBacon

2 жыл бұрын

Sorry, Chris, what is this word "testing"? I've looked up the definition in the Arduino Coder's Bible and it states: "Testing, v, The iterative act of releasing code into the Real World and seeing what happens, mostly using the happy path". Sounds about right.

Legend, hope your finger got healed! Thanks for your content

@RalphBacon

Жыл бұрын

All good, although I still have a scar on my thumb.

Great info. Thanks for sharing 👍🏼

@RalphBacon

2 жыл бұрын

No problem 👍

Very good message. I have been working with a Nordic chip and initially I was inserting debug messages. Later when I starting the power reduction phase I realized that activating the UART port increased the power consumption more than 10X. Still at some point you really need the serial printing but when moving to running on battery I disable the UART totally. I have not tested on a Arduino if the Serial.begin() is impacting on the power consumption.

@RalphBacon

2 жыл бұрын

Good info, Tom. And we can disable the UART in the Arduino world by using: #include power_usart0_disable(); which could possibly be part of some precompiler construct too (not done it, but it should work).

Thank you. It's very helpful!

@RalphBacon

7 ай бұрын

Glad to hear that!

Wow, I needed this! You are a Saint sir

@RalphBacon

2 жыл бұрын

Glad it was helpful!

Another great video... I've not programmed in C for 25+ years, and have forgotten more than I remember, but this was just excellent. I'm still working on a project and knew I had to control my serial print statements as I 100% knew I had to remove them at final runtime/build. I was about to add in my own function for this, but this video makes me double check how I go about it. I love the idea of controlling the compiler to just filter out my unnecessary serial print commands 🤣 ... Thanks for this 👍

@RalphBacon

2 жыл бұрын

Glad you enjoyed it! And helped you too. Awesome!

Very Elegant! Easy to use, and easy to get rid of again! perfect

@RalphBacon

2 жыл бұрын

Thank you! Cheers!

@kroojohn

2 жыл бұрын

@@RalphBacon You are welcome ! Nice channel, saw it by accident a few days ago, and decided that I really like what you are doing !

Good tip, I'll use it.. thanks! 😊

@RalphBacon

2 жыл бұрын

You're welcome, Tony.

Well done Ralph, I like it!

@RalphBacon

Жыл бұрын

Thank you! Cheers!

Great video! Thanks for posting.

@RalphBacon

Ай бұрын

My pleasure!

Very nice, excellent tip!

@RalphBacon

2 жыл бұрын

Glad you like it!

Nice and easy trick, thank you for presenting. Best part of it: It can easily be extended to introduce debug levels for more or less detailed debugging information.

@RalphBacon

3 ай бұрын

Yes, you are right, it's what I also do! the ESP32 does it automatically (log_X where X is the debug level you want).

This debug is a sweet little trick Ralph, thank you! And of course the "real" Serial.print() commands can be left as they are, so it declutters the Serial display too.

@RalphBacon

2 жыл бұрын

You're welcome, Simon!

One of your problems, mr. Bacon, is that you go Serial.begin(9600). You can be 96 times faster with 921600.

@RalphBacon

2 жыл бұрын

The highest speed I use (usually with ESP32s), Vasily, is 115200; I will try higher speeds and see how it copes. The Arduino, with its 16MHz processor speed, is surely limited to 115200 at best? I tend to use 9600 on the Arduino to make it super safe and no risk of corruption. I guess I should increase that too! I can remember when 300 baud was the maximum I could get from some chips!

@vasiliynkudryavtsev

2 жыл бұрын

@@RalphBacon 921600 is one of standard values for UART. The FT232 USB-UART chip has 3Mbaud maximum data rate, same is for many clones and alternatives. As for microcontrollers, they usually have hardware implementation of UART, cpu clock is not that important.

@vasiliynkudryavtsev

2 жыл бұрын

@@RalphBacon Also, how faster one can go over UART for different boards can be a good investigation for your future video. BTW, for esp8266 and esp32 I used 921600 with no problems. 115200 is very safe for atmega328p (depending on USB-UART IC).

@RalphBacon

2 жыл бұрын

Hmm. If I clock an Arduino at 8MHz then my maximum sketch upload speed is only 19200, otherwise it might fail. On the other hand, an ESP32 can upload at 921600 no problem at all! There must be a correlation between processor speed and clock speed. Unless this is only true for storing program code into Flash (which is slower, we know).

@vasiliynkudryavtsev

2 жыл бұрын

​@@RalphBacon Well, this is true. The correlation is in how good and functional is the clock divider or PLL in MCU. That can be proved only experimentally or computed from datasheet.

This was genius, thank you so much for the video!!!

@RalphBacon

2 жыл бұрын

You're so welcome!

Nice tutorial ... I also like the format where you're in the bottom right corner of the screen ... that was a good idea. :-)

@RalphBacon

2 жыл бұрын

Glad you liked it!

Love this will have to go back to some of my older codes and try this see how much memory I can save also run a blink test see if it makes it faster 👍 great video ☺️

@RalphBacon

2 жыл бұрын

It won't make your Blink test run any faster if you have used the "delay(x)" statement. But if you have coded it in a non-blocking way then it will certainly run the code more quickly as it does not have to deal with, and wait for, serial output to complete.

@wires4auto

2 жыл бұрын

@@RalphBacon yeah I have a custom blink with out delay, it acts more like a heartbeat LED but I have used serial.print about 10times in it so will be just interesting. Sorry to hear about your ✋ hand. You take your time Ralph and be safe

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?

@RalphBacon

8 ай бұрын

That's because you are using the in-built Serial Monitor of the Arduino IDE. I'm using a standalone program called CoolTerm which is nice, and it's free too, although Roger is grateful for any donation if you find that you use it a lot: freeware.the-meiers.org

Thanks Ralph. The Arduino Printf will make my code cleaner compared to my current multiline approach.

@RalphBacon

2 жыл бұрын

I do have a video in the pipeline that goes into more detail on printf, aimed at beginners.

Good suggestion, quite useful especially for beginners!

@RalphBacon

2 жыл бұрын

Exactly so, good beginner tip!

Thank you Ralph, this is so useful and I was very impressed how it worked and saved space for me. Silly question, is there a way of making the debug trick available to all Arduino code? So, that when I open a new sketch the whole debug solution is already available please? Thank you.

@RalphBacon

Ай бұрын

The _easiest_ way of doing this is to keep all the DEBUG stuff in a separate file (I'd suggest of type hpp, which is a C++header with code too). Place it in your libraries folder (usually a sub-folder in your sketches folder). Then, in each sketch just include a simple #include "MySpecialDebugStuff.hpp" (or whatever you called it, keep it easy to identify but not as verbose as this!) at the top of your sketch and it will be included in the sketch. Glad you found it useful!

I do add a lot of debugging Serial.print lines in my code and I've seen countless times that how they slow everything. What I do is to add a global boolean variable "debug" and start every Serial.print line with if(debug). That way if the value of debug is 0, then all the debugging lines just don't work. Also if I have an IO pin that I don't use I add a header to it in the final design that I can put a jumper and turn debug on, leave the jumper off and turn debug off. This way I don't have to recompile and re-upload the the code if I ever need to debug it after some time of use. Yes, I know that although this method prevents slowing down, it does not not help (and even makes it worse) with the bloating of the complied code. This is exactly why I just loved this approach, all I need is to combine this with my pin controlled debugging somehow. Thanks! Much appreciated info!

@RalphBacon

2 жыл бұрын

Yes, I've done similar with a spare GPIO pin controlling the output. But you cant use that method with precompiler directives, as the code will either contain the debugging lines or it won't!

Nice! I've reduced 1656 bytes in my last code with this method. Thanks!

@RalphBacon

Жыл бұрын

That's good going, Jorge, well done.

Sorry to hear about your argument with the knife. I had another thought about using this. Would it be possible to turn this on or off with a MQTT message or some other means of remote control?

@RalphBacon

2 жыл бұрын

We would not be able to control the _compilation_ process, so the Serial statements would be present; but the _execution_ of those statements could certainly be controlled by pretty much anything that the microcontroller can receive (it's just a flag, after all).

I see where this would be great for some of my projects which have a few thousand lines of code. Even if you require serial.print for communicating with other processors, just use that explicitly and everything will still work. Awesome! Thanks!

@RalphBacon

2 жыл бұрын

That's a great idea!

​ @Ralph S Bacon How would one use the optional second parameter which specifies the base (format) to use; i.e. Serial.print(0x61, HEX); ? At the moment I will receive an error requiring 2 arguments or 1 argument. To ask another way, How can I specify #define debug(x,y) Serial.print(x,y) but allow Y to be optional?

@RalphBacon

Жыл бұрын

I did update my examples to include further arguments (you were not the first to ask this). Basically, use the ellipsis (...) as the second argument in the definition, which means "an unknown number of parameters", from none to infinity. That way we can parse any further parameters and pass them onto the Serial.print statement.

@gutrali

Жыл бұрын

@@RalphBacon thanks for the solution Ralph! I will give this a try on my next upload 👍

Thank you very much Sir for this memory saving and interesting new method... Such things makes coding interesting. 😀

@RalphBacon

2 жыл бұрын

Glad to hear that!

Very interesting ! I've learned something !

@RalphBacon

2 жыл бұрын

Excellent. My work here is complete.

Thanks for the video. Please advise. How did you bring up the "call term" window. (Or what did you call it?)

@RalphBacon

2 жыл бұрын

That would be CoolTerm, an independent serial port monitor. Free to use, although if you find that useful the author, Roger, appreciates a contribution. You can have several instances running at once, which I do, as I'm monitoring several ESP32 projects at once: freeware.the-meiers.org/

Thank you for your beautiful tutorials What is the difference between debugD and debugV? In both definitions, debugE, debugW, and debugD are executed. Was there a specific reason you defined debugV? And why is the debugNothing function used in debugV and not used in the rest of the functions? Is there a specific reason? Thank you for your reply

@RalphBacon

4 ай бұрын

The "V" stands for Verbose and is used for those really low level messages that otherwise would be really annoying and flood the output. "D" is for more general Debugging and E/W/I you know about. The level you set (eg "I") ensures that all message at that level AND HIGHER are output (so W and E too). debugNothing should exist for all levels if they are not defined.