Serial speed for debugging/logging

Question

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?

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.