That dramatically affects runtime timing.What works better when timing matters, is to use a logical analyzer and strobe some i/o pins.You can create some raw port i/o macros and do things like high/low transitions on pins, multiple transitions, or even use multiple pins and decode them in parallel on the analyzer.I often use a single pulse to mark the beginning of something and double pulse to mark the end.Lots of information can be communicated very quickly just a few pins without affecting the runtime timing much.--- bill
For example developing a program in steps with each step proved to work before moving on to the next step. Then a new problem could be isolated to the impact of a few extra lines of code....R
I just came across this in the C programming faq:Include line number info with a debugging macroOf course, you have to use serial.prints() instead of printf(). This will at least get you line information.
But if you plan to do much of that in your code on an AVR based processor, you also need to wrap it all in a macro that automatically converts all the formatting strings to F() strings to avoid filling SRAM with your format strings.You will need a wrapper macro for debug() that wraps the format strings with F() macros then calls the function version to do the work. And the function version needs to use progmem format strings and call the apprpriate AVR versions for the xxprintf() functions that support progmem format strings.--- billOh and it is also possible to set up the i/o tables to allow printf() to work on the AVR.See my write up on the printf page in the playground.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16