I have a sketch where I want to check my nRF24L01's and they work great.

However, due to Serial.print(ln) statements I noticed there is a lot of delay. Is this normal?

I mean, is it better not to user Serial.print at all during speed checks? (probably not).

What other options would be best? Some I can think off:

  1. Put all debugging info in an array and print it later (downside: more programming needed, probably special logging class)
  2. Print less (bad solution I think, also makes logging more difficult to read)
  3. Use another Arduino (so sending it by other means, via Wire or so? Never tried this, but I think this might be the best solutions.
  4. I couldn't find any print that does not wait until ready sending (which would cause minimal 'downtime' for the running sketch.

I did not try the third option but I think that would be ideal (but cost another Arduino). Since in my project I eventually use multiple AVRs (mostly Arduino's), I was thinking about sending all logging info to one Arduino and let that Arduino print out everything, that means, only one serial monitor, and no delays (or barely) for all others (where it matters).

Do you think this is the best for logging/debugging? Or are there better methods for use with an Arduino?

  • 1
    Option 5: Run Serial at a much higher baud rate. You should be able to go at 1MBaud quite happily.
    – Majenko
    Jul 29, 2017 at 14:04
  • @Majenko ... With the Arduino IDE I just can chose 250000 baud, should I use a better serial port monitor? Jul 29, 2017 at 14:14
  • 1
    Hell yeah. That thing is ghastly.
    – Majenko
    Jul 29, 2017 at 14:14
  • I just learned a new word :-) ... going to check for better ones Jul 29, 2017 at 14:20
  • @Downvoter, can you instead of downvoting all my posts, explain WHY you downvoted, so I may improve the post. Nov 18, 2020 at 11:59

1 Answer 1


I use a couple of techniques to measure code timing or to instrument it with mimimally disturbing time-critical code:

  • Run the code-under-test in a loop of N times, taking the difference in the system clock before and after the loop. If the code-under-test is short enough that the loop housekeeping timing might significantly affect the measurement, I'll unroll part of the loop - cut and paste several repetitions of the code-under-test into the loop - to reduce the relative effect.

  • Toggle an output pin at entry and exit of the code segment-under-test. Measure the pulse width with an oscilloscope, or with a DVM that includes frequency and duty-cycle measurement and calculate the pulse-width from that. I write directly to the I/O port to keep the influence of the software probes (added code) to a minimum.

  • If I'm trying to collect debugging data without disturbing the code timing, then as you suggest, I store the raw data in an array (raw, to keep it small), dump the raw data in hex to the terminal after the test-run, and expand/interpret it on my PC (to address your point 1., more programming needed). You'll still need some extra programming but it will be in a separate domain (your PC), it can be big, dirty, and slow, and requires less disturbance to your embedded source-code.

  • Thanks for all those options ... for my test 3 will suffice, 1 I also use indeed for very small timing checks, 2 is also interested, hope my oscilloscope can handle it :-) Jul 29, 2017 at 14:43
  • (sorry for my late acceptance). Jan 18, 2018 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.