Is there a way to debug the program as it's running on the target board?
It seems that the Arduino IDE does not have anything related to debugging.
How are people doing this?
Hi
as far as I know, the only way to monitor execution in real time is to use serial statements that send values to your host machine. Of course there is also the good old blinking LED loop: if something or other is true, blink the led.
If you want to see the states of registers you are out of luck, although there might be something in the AVR line that you can buy for $1000 bucks to do it.
D
I don't want to monitor the application in real time. I want to step trough it with the debugger. Obviously debugging would not be real time, because you are inserting breakpoints.
As far as I know using tools like AVR Studio you can do this using a fairly inexpensive (50$) JTAG or ICE interface like this one
As far as I can see the Arduino-USB board has no JTAG connector, so it can't be debugged.
Correct me if I am wrong. I have been a programmer for quite a while, but had not had much contact with embedded microcontrollers since 1990. It seems to me without a debugger it will be much more difficult (time consuming) to found out and fix a problem.
The ATmega8 and ATmega168 don't support JTAG, which is why there's no header for it on the board. The ATmega168 has some sort of one-wire debugging functionality on the reset pin, but I've never tried it.
And yes, it can be hard to track down problems without a debugger, but on the other hand, with only 8 KB of program space, programs tend to be much simpler (and easier to debug) than those running on a computer.
yes... on top of this the protocol (DebugWire) is proprietary and Atmel doesn't want to reveal it...
they sell a device that costs about 400USD that you can use to debug the code under windows..
I have been writing code on the arduino that has been in need of debugging and just added serial.println statements by the dozens. I have been able to debug stuff pretty well. I suppose you could do something with an external interrupt if you wanted to halt the program in mid execution but that is not like inserting a breakpoint in a C program.
That's a super clever idea robocarp. Just attach a momentary switch to one of the interrupt pins (digital pins 2 or 3) and dump all of your variables out on the serial from the interrupt function. This solution won't halt the execution of the code, but will give you a good idea of the state of your variables. This would probably reduce your program size during development because you don't have to have all those serial.println statements either. The only disadvantages I can see would be the sacrifice of one digital pin, and a bit of code space for the interrupt function.
Are there any constraints on interrupts? Will it activate during a delay call, or will it wait until the delay is complete? What about if an interrupt is called inside of another interrupt? Has anyone run into any instances where an interrupt will not execute, like getting bogged down in a recursive loop or something?
I'm going to experiment with this idea a bit, and I'll post my results.
I do not have a ton of experience with the atmega interrupts but here is what I (like to think that I) know:
Interrupts will activate during a delay. It effectively stops the delay and restarts it when the interrupt routine is done. I think that delaymicroseconds is different and cannot be interrupted. If that is true though then the interrupt would just get called immediately after the delaymicroseconds call returns.
As far as I know there is no ability for nested interrupts. When an interrupt is called the processor preempts the program running and executes the interrupt code. The only time lapse is that of storing where the program was when it was preempted, which is at most a stack push or two and setting a flag of some sort. If an interrupt event occurs when there is already an interrupt being handled, the handler probably does not even notice until normal execution resumes. That is just a guess. I know that there is no facility for nested interrupts. I would bet that they are atomic operations.
I would be careful about dumping a lot to the serial port inside an interrupt routine. For one, serial communication might be disabled. More importantly, because there is no facility for nested interrupts, interrupt routines should be short and sweet. Something like setting a variable which then could be read by the normal execution loop.
Psuedo code:
byte int_called = 0;
void interrupt_handler(void){
int_called = 1;
}
void setup(){
interrupt_attach(....);
}
void loop(){
if (int_called){
int_called=0;
Serial.print_all_vars();
}
}
For anyone interested i've started a thread on using interrupts here. They work really well as a debugging tool. They activate, as far as i have seen, without exception. Although I have not tested that too much. As well, serial output seems to work, which is why i found them to be well suited as a debugging tool.