Guys if someone could implement the debugging capability into arduino ide or somewhere else where one can track the instruction being executed. then it would be just awesome and most powerful embedded platform for both small and medium scale projects.. Thanks a lot.
if (true) Serial.println("worked"); else Serial.println("!worked");
if (true) digitalOut(13, TRUE); else digitalOut(13, FALSE);
You may want to have a look at JTAG, although I'm not sure it does what you are pretending.
I doubt that's possible in the IDE, I think you can run an Arduino sketch under AVRstudio with a hardware debugger though.
You could build your own in
Use combination of serial.prints and reading a pin, or time passage, to allow code advancement:
// code breakpoint, insert at breakpoint
Serial.print (“Waiting at (insert location here)”);
stopTime = millis();
while ( (digitalRead (continuePin) == 1) || (millis() - stopTime <=200) )
// hanging out until pin grounded, or 200mS goes by
// debounce may be an issue if button pressed and next break occurs while switch is bouncing
where one can track the instruction being executed.
Arduino code is written in C but the processor executes machine code instructions, there is not a one to one correlation between the two. One line of C can translate into many machine code instructions and they don't always translate into a coherent block of machine code.
This sort of thing can only be done with a hardware emulator and these cost many thousand dollars.
The ATmega processor in the Arduino does not support JTAG so that is not an option. Therefore you have to resort to the sort of techniques described here.
Could also move up to a board with a '644 or '1284 processor for the JTAG interface capability, and then learn how to use tools such as those offered by Atmel.
Would this imply that there is in fact a major advantage to PICs? Even PICs which can’t be hardware debugged (due to low pin count, older, etc.) can be simulated in MPLAB, with a free simulator.
I speak of 8bit PICs of course.
But there really isn’t a low cost (<$50) debugging solution for Mega328s?
Oh, and Grumpy_Mike, the fact that they don’t correlate directly is usually not a problem. It only takes a slight bit of (artificial) intelligence to map the steps back to C. Again, done by a free PIC simulator and low cost debugging solution (PICKit2) all the time. It should be even easier with Atmega chips due to the use of the branch asm commands, which are more like C/C++ conditionals than other command set solutions. Also, while assembly can be quite difficult to write, it is actually pretty easy to read once you understand the basics. Just keep the manual nearby.
In the mean time, you can do pretty well with Serial.print() statements and reading through your code.
"you can do pretty well with Serial.print() statements and reading through your code"
That's all I've ever used, and one of my programs was spread over 7 tabs (made it a lot easier to find stuff that way) and compiled to 13,000+ bytes with no progmem data arrays, strings, etc. Can flash an LED or two also if not using Serial for anything.
Simulating is free with AVRs, just use AVR Studio and select the simulator as the debug platform.
JTAG and debugWIRE (for small chips) does need some hardware. The Dragon costs $49 from AVR direct but there are probably cheaper clones.
The Mega328 can be debugged with debugWIRE but in the case of an Arduino you'd have to hack into the RST signal and change some fuse settings.
From experience, the problems you can't find with Serial.print() or LEDs flashing won't show up in a simulator.
I've never been a fan of simulators, most stuff I do needs interrupts and fast timing, none of which work well (or at all) on a simulator.
My personal favorite is to allocate two pins for pulsing and look at them with a logic analyzer. Almost no affect on the running program and you can tell most things by using different combinations of pulses.
You can't of course print out a variable in HEX without resorting to serial bit banging.
Don't confuse a simulator with a emulator. An emulator is a hardware device that has the functions of the target processor but also has full hardware access to the inside. They are normally made with FPGAs and cost a lot of money. However, they can do anything the real processor can do and that includes fast interrupts.
But agreed print statements are usually all you need. Occasionally you might resort to raising and lowering an output pin and looking at the resultant waveform on a scope along with what your hardware is doing.