Go Down

Topic: Software debugging (Read 259 times) previous topic - next topic

TommiP

#15
Jul 22, 2016, 08:40 am Last Edit: Jul 22, 2016, 08:53 am by TommiP
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
This option combined with seven segment display (if I don't have logical analyzer) for example could be the solution to get accurate enough off-line debugger. Thanks! :)

TommiP

Robin2

I can't help feeling that some logical thought and careful planning of program development would eliminate the need for the sort of thing the OP is searching for.

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
Two or three hours spent thinking and reading documentation solves most programming problems.

TommiP

#17
Jul 22, 2016, 09:10 am Last Edit: Jul 22, 2016, 09:18 am by TommiP
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
Of course this softwarer also use this method and writes his codes piece by piece and steps forwards after previous piece is working 100%.. ..although sometimes it's bit difficult.. :D

TommiP

KeithRB

I just came across this in the C programming faq:
Include line number info with a debugging macro

Of course, you have to use serial.prints() instead of printf(). This will at least get you line information.

bperrybap

I just came across this in the C programming faq:
Include line number info with a debugging macro

Of 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.

--- bill

bperrybap

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.

--- bill

Oh 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.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

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!

Arduino
via Egeo 16
Torino, 10131
Italy