Go Down

Topic: Debugging (Read 5514 times) previous topic - next topic

graynomad

Except that serial printing can be very intrusive for real real-time code. In these situations a couple of PULSE macros and a logic analyser or scope is the best method I know.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

GoForSmoke

You can have the code write a log to SD if you can spare the pins and overhead or even use a log as part of the process itself. I've just done that for someone using enums and PROGMEM labels to track the operation and timings of a few different asynch  state machines down to great detail.

Using event-driven modules does allow testing small pieces that can be used as they are in the whole. If code-weaving is avoided, not putting the line to act on a sensor read right after the code doing the read right before the code to report (but that is common do-it-right-there-now sense isn't it?) then a great deal of complexity and IMO extra code can be cut out of projects big enough to be debug nightmare spaghetti.

It's not like you're going to fit massive code on a 328P anyway, is it?
The environment is small and simple enough that it should force some changes in practice.
I view that as good. Too many tools will actually encourage complex over-development.by permitting it!

KISS!
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

bperrybap


Except that serial printing can be very intrusive for real real-time code. In these situations a couple of PULSE macros and a logic analyser or scope is the best method I know.

______
Rob

For timing profiling a logic analyzer or scope is great,  (I use an analyzer quite often)
but for code debugging,  source level debugging using gdb is definitely much better as it has no real-time
impact and then you can set break points or single step and look at all your variables.

gdb has been around for 25+ years, and is a huge part of what makes the gcc tool package
so great.

Unfortunately, the Arduino IDE environment is not very friendly towards using it.

--- bill

graynomad

Quote
you can set break points or single step and look at all your variables.

Which is intrusive by definition.

I love both pin toggling and full-featured ICE debugging, they both have their place.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

bperrybap


Quote
you can set break points or single step and look at all your variables.

Which is intrusive by definition.

I love both pin toggling and full-featured ICE debugging, they both have their place.

______
Rob

When the code is actually running, there zero impact.
Often when you hit the breakpoint, you no longer care about the real-time nature
since you are now wanting to look at the state of all your variables.

Sometimes you just want to break into the code to see where the heck it is.

I also use both.
What I often see is that many developers that use gcc,
never bother to take the time to set up gdb and learn how to use it and end up resorting to
primitive serial print type debugging.

larryd

Some Great ideas here:
http://www.gammon.com.au/forum/?id=11329
One or two here:
http://www.gammon.com.au/forum/?id=12153
No technical PMs.
If you are asked a question, please respond with an answer.
If you are asked for more information, please supply it.
If you need clarification, ask for help.

mart256

To OP. If you want "out of the box" solutions for hardware debugging, then you should move to 32 bits microcontrollers.

There are a lot of cheap options, check this TI ARM board : http://www.ti.com/tool/ek-tm4c123gxl. It includes hardware debugger on-board, just using the usb (no external debugger required). Just for 13 USD.

PS: Once I tried to debug with debugWire an 8 bit AVR but the entire process to setup was long and at the end I burned my AVR debugger (Dragon).

graynomad

Everybody burns a Dragon, or at least they used to although I think they are more reliable these days.

One reason I love working with LPCs is that ARMs all have debugging built in and it's supported by the IDEs out of the box.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

GoForSmoke

#23
Sep 04, 2014, 03:12 am Last Edit: Sep 04, 2014, 03:14 am by GoForSmoke Reason: 1
Compare to the Due or a stripped-down compatible?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

graynomad

Well actually it's not the LPCs as such as I think all ARMs have similar debugging capability. It's the the dev environment that makes the difference and the LPCXpresso boards have debugging built in, no ICE required just the standard USB cable and IDE.

The Due doesn't do that. IIRC there is a debug header but you need a separate ICE for that.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

mart256

Avr jtag ICE for DUE debugging is expensive (110 usd on digikey).

Go Up