Debugging

Hello

How can I debug my program when there is a serial connection to arduino only?

Thanks for your support. Miller

How can I debug my program when there is a serial connection to arduino only?

What is meaning of this. You have connected anything to serial port??? Can you share us interface diagram with your board.

Not sure exactly what you mean: the serial conn is exactly what you need… the common approach is to use Serial.print(variablename) and Serial.print(“some helpful text”) to give you feedback on the serial monitor.

You can see what the variables are up to, and the text can tell you where you are in the flow… eg you can see which branch in an if/else or case is being actioned, has setup() finished, are you back at the top of loop(), etc etc

It’s not ideal, by any means, but it works…

edit… Another approach, if you have spare pins, is to have some LEDs going on or off to indicate what’s happening inside.

@jimboZA

I think he used all port . TX and RX pins for enabling other device . In this situation How we can Debug the program. Thats reason i asked for interface he used for. I doubt We can simulate or arduino IDE(if any way we can simulate i dont have IDEA). I think we can simulate on visual micro IDE. Its like Keil compiler. Where you debug line by line

http://www.visualmicro.com/

Ah ok, that could be what he meant, yep.

You can sometimes use leds on free pins to show what path your code takes.
But you may have to add delays just to see the lights at all and that can ruin timing if timing matters.

If you show your code and wiring this wouldn’t be such a game of poking in the dark.

Good incentive to get code "right first time" 8)

Use SoftwareSerial and a USB-ttl cable (aka FTDI cable) to make up a temporary debugging link to the PC.

If communicating between a PC application and the Arduino (using the regular USB connection) add some capability to the PC application so it can display debugging messages from the Arduino.

...R

Hello

Thanks a lot for your answers. At the moment I do it like this: Serial.print("value of s.g.") Serial.println(value)

But that's very old school.... I prefer to program with debug mode like that: http://4.bp.blogspot.com/-kW16Nx_eRt0/UzOdWQwjspI/AAAAAAAAprw/Gj6pN85wlzI/s1600/eclipse-debug-view.JPG

Is something like eclipse possible?

Thanks Miller

There are AVR emulators but I can't say about debug-IDE of any of those.

Maybe see what free Code::Blocks Arduino version will do?

In general Arduino do not allow real debugging, that is about to change I think but meanwhile the above techniques are pretty much what you have got. Personally I prefer using a couple of spare pins to indicate things on a logic analyser as LEDs are too hard to see unless you add delays etc.

Is something like eclipse possible?

Look into the Visual Micro plugin for Atmel Studio, it's free and works really well and has a debugging interface as a paid option.


Rob

You could use DDD (gui) on top of gdb on top of avarice which can connect to
an AVR dragon, or AVR JTAG ICE.

That can give you full source level debugging without using any additional pins if you use
the debugWire interface.

It is a pain to setup with the Arduino IDE but it can be done and makes life so much simpler
and better than goofy serial prints.

— bill

If debugging is the art of taking mistakes out of code, programming must be the art of putting the mistakes in

:slight_smile: <<<<<<<<<<<<<< smiley, just for in case.

Then I must do a heck of a lot of programming.


Rob

If you make so many mistakes that Serial.print() etc is too tedious perhaps you need to consider another career hobby :)

You could define a function to reduce the typing and amalgamate the message and the value

dPr(message, value);

and make it conditional on a debug variable being true so it is easy to switch on or off.

...R

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

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!

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

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

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

Graynomad:

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.