Arduino Forum

Development => Other Software Development => Topic started by: ardnut on Jul 09, 2012, 04:03 pm

Title: what about debugging?
Post by: ardnut on Jul 09, 2012, 04:03 pm
I seem to find little mention of debugging techniques here.

Is the arduino IDE simply a compile and upload facility?

avrdude allows access to flash and EEPROM but not the volatile memory it seems.

There does not seem to be any access to RAM and the registers which is necessary for any serious development.

Playground mentions debugging but only in the context of Visual Studio it seems.

So what are the options for full debugging in this environment?  I was under the impression that AVR allowed development platform free from expensive development kits and hardware.

Maybe I'm just not looking in the right place but there seems oddly little talk of how to do debugging here.

Thanks for any pointers.
Title: Re: what about debugging?
Post by: AWOL on Jul 09, 2012, 04:09 pm
You're working on a tiny, slow microcontroller with limited memory, but with largely well-tested libraries.
How much serious debugging do you envisage?

(FWIW, I work on much faster processors, with very many times more memory, more, complex peripherals yet still use pretty much the same techniques to debug as I use on the Arduino)
Title: Re: what about debugging?
Post by: wildbill on Jul 09, 2012, 04:25 pm
Basically, you're back to the world of the 80s. Printf (Serial.print), logging to a file (if you have an SD card) are your primary tools. Forget breakpoints, watching variables etc. If use of the serial port impacts your program's timing too badly, you have I2C and SPI. Lighting LEDs is used as a low impact debugging indicator, though it obviously doesn't tell you much. Signal analyzers and Oscilloscopes can help too.

Consider this though: the code you'll write for most arduino sketches isn't going to be that complex usually, so debugging them even without the fancy IDE tools, isn't especially difficult if you know what you're doing.

If you really want that stuff, take a look at the netduino: C# and a fully functional debugging IDE.
Title: Re: what about debugging?
Post by: ardnut on Jul 09, 2012, 04:26 pm
The libraries may be well tested but my use of them is not. If something does not do what I expect I need to look to see why not rather than just have another stab in the dark upload.

I'm not aiming to use the hardware to flash LEDs on and off, I need to control external hardware real time, reading ADC ports, monitoring the state of the external hardware and outputting control signals.

I would expect to do this by setting break points and checking registers etc.

"yet still use pretty much the same techniques to debug as I use on the Arduino"


Which is what in the most simple terms, print to serial port?

thx
Title: Re: what about debugging?
Post by: AWOL on Jul 09, 2012, 04:35 pm
Quote
Which is what in the most simple terms, print to serial port?

Well, it's a very, very fast serial port, but yes, pretty much that's what we do.

Graphics, DSP, I/O (lots of I/O), all get debugged through the serial port.
I haven't debugged with any kind of ICE in over ten years.
Title: Re: what about debugging?
Post by: bperrybap on Jul 09, 2012, 11:18 pm

I seem to find little mention of debugging techniques here.

Is the arduino IDE simply a compile and upload facility?

Yep, pretty much.

Quote

Maybe I'm just not looking in the right place but there seems oddly little talk of how to do debugging here.

Thanks for any pointers.


For any real sort of real debugging (which I assume you mean at the source level with variables, break points etc...)
you will want to use gdb or some GUI wrapper around it.
And to do that you will probably want/need to use makefiles to make sure you set
up everything the way you want it.

The Arduino IDE is simply too wimpy and didn't use Makefiles underneath so it is pretty
painful to use the debugging tools with the Arduino IDE.
You can choose to abandon the IDE (there are some makefiles out there that come close to working similarly)
or leave Arduino and its libraries behind and write your own code using avr gcc with makefiles,
or use AVR studio
You can use AVR studio if you are still using windows and want a GUI solution for Windows based OS's.
Alternatively you could use something like eclipse - I think they have some Arduino plugins now.

You will also then need some additional hardware that can access the chip on behalf of the
debugger. The AVR dragon is probably the most cost effective device for source level debugging.
It can use the ISP port, JTAG pins,  or can use the reset line (debug wire mode) to access the internal chip resources.
Debug-Wire is very cool as it only uses a single pin that usually is not used for anything else anyway.

As far as "back to the world of the 80s" type debugging goes.
Boy do I wish it was that good on the AVR. By the late 80's gdb was already fully
working in many embedded environments
and true source level debugging with breakpoints and access to variables
was easily accomplished over a serial port
with the simple addition of a gdbmon to your embedded target code.

Today, on the AVR, life is not so simple nor as good. The Harvard architecture really throws
a wrench in things, (much of this issue has work arounds) but as far as having a gdmon goes
that allows source level debugging over a serial port goes, it is non existent.
There are some technical issues in making something like a gdbmon interface fully work
on the AVR so at this point everyone that wants
source level debugging is using a h/w tool that can be controlled by a debugger - usually gdb.
Tools like the AVR dragon or JTAGice are used. This is what avr studio and packages like DDD use)

I've often thought about doing a gdbmon for the AVR. Break points and single stepping
can be made to work but are ugly under the hood as you have to steal one of the interrupt pins.
I've just not had the time and an AVR dragon using debug-wire is actually better anyway.

For now, you are kind of stuck with a few options.
- use IDE "as is" and revert to using primitive debugging techniques like
"printf()", toggling pins, LEDs, etc...
- switch over to a more advanced build/development environment and use a h/w debugging tool
like the AVR dragon or JTAGice

If you switch build environments, you will have to decide if you want to stick with
the Arduino s/w environment or leave it behind as well.
If using a windows platform, AVR studio is a pretty nice tool set and offers full debugging
as well as a simulator.
You could use AVR studio with some "Arduino" makefiles to allow using AVR studio and its
debugging tools with the Arduino s/w environment and libraries.

You can also ask questions over on the AVR freaks site about AVR (non Arduino) development:
http://www.avrfreaks.net (http://www.avrfreaks.net)

For realtime runtime debugging even having a source level debugger may not help.
For example you may need to see a certain stream of events in real time.
A break point won't help in that situation as it halts the processor.
For sure anything like a serial port transfer will kill the realtime timing.
kiss i2c goodbye it is WAY slower than a serial port, even SPI can be too slow.
For these situations, I use multiple output pins and a logic analyzer.
You can assign an event to a pin or use a collection of pins along with a "strobe" indicator pin
to indicate the event. On the AVR, this allows indicating an event in as little a single AVR clock cycle
since if you pick your pins carefully you can update them all in a single write to the port register.
This is very unobtrusive to timing.
I've used this output pin strobing technique on many systems over the past 30 years especially for very
realtime systems where you simply can't do much of anything or something bad can actually happen
(like corrupt the format of the hard disk - in the case of disk controller)

It is very easy to implement, uses a very small amount of code in the target
and gives you realtime visibility into the code flow.
It is great for profiling routines as you can do strobes around portions of code to time it.

--- bill

Title: Re: what about debugging?
Post by: graynomad on Jul 10, 2012, 12:19 am
Until recently I've used two spare pins and a logic analyser for low intrusiveness and printf if I can afford the time. I have felt no real need for a debugger.

That said, over the last two days I've been working on a system with full debugging capability and it's been a dream. For example I had a hard fault exception, the debugger showed the stack frame so I clicked on the last executed line of code and immediately found a bad index into an array of function pointers. That would probably have taken half an hour of dicking around placing pulses to see how far the code got etc.

I still plan to use the pin-pulse method for time-critical stuff, but apart from that I'd say "Use a system that allows real debugging". Hopefully the new Due will.

______
Rob
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 04:00 am

Which is what in the most simple terms, print to serial port?


That is usually my first fallback. Then there are other methods:

http://www.gammon.com.au/forum/?id=11329

It's all very well setting breakpoints etc. but often this sort of imbedded microcontroller is doing something timing-dependent, and setting breakpoints doesn't really help with that.
Title: Re: what about debugging?
Post by: DonBiederman on Jul 10, 2012, 04:57 am
I've been spoiled with AVR Studio and JTAGICEmkii for so long before Arduino. I like to use simulate or monitor what going on if I feel that something is not happening correctly. I made a simple SPI pod for my logic analyzer it has helped me. Serial.print is very useful too.
Setting and clearing output also.
Don
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 09:56 am
Thanks Bill, that's exactly the kind of detailed information I was looking for.

It seems calling the Arduino IDE an IDE is over selling it a bit. The "I" in IDE stands for integrated. The integration being that of code generation and debugging.
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 10:08 am
Can you oversell something that is free?

Check this out:

http://arduino.cc/en/Main/Software

Quote
The open-source Arduino environment makes it easy to write code and upload it to the i/o board.


It claims to be easy to write code and upload it. Which I believe it achieves.
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 10:30 am
Frisky:
Quote
I've been spoiled with AVR Studio and JTAGICEmkii for so long before Arduino.


JTAGICE can run atmega168 and atmega8 , both of which can run in the UNO , as far as I have been able to determine.

JTAGICE is not cheap ($300) but that would provide one route to having a full debugging evironment for Arduino, unless I'm mistaken.
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 10:36 am
Quote
Can you oversell something that is free?


Overstating it's capabilities if you prefer. I don't consider something with no debugging capability to be an IDE Though if you want to be pedantic you could always say the have "integrated" code generation and an uploader.

For what it does it seems to be a pretty good tool. But calling it and IDE is rather misleading.
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 10:43 am

But calling it and IDE is rather misleading.


My point was that on that page the letters IDE only appear once ("Previous IDE Versions"). It represents itself as "The open-source Arduino environment".
Title: Re: what about debugging?
Post by: JimboZA on Jul 10, 2012, 10:58 am
We mustn't lose sight of Arduino's provenance and original purpose, which (at least as I see it) was to let a bunch of lay folk write code and get it into a processor in a bit of a quick-n-dirty way so they could make stuff happen in the real world. And today my daughter- who would never otherwise have developed any kind of interest for this stuff- does exactly that when she writes simple C code to drive her 2-motor Magician chassis with an Uno and a MotoMama board.

That said, it has of course evolved and seems to have become a genuine embedded control platform used by professionals. Professionals need better tools than amateurs like 16yo schoolgirls, since they have time constraints and get paid to make stuff quickly and cleanly (not quickly and dirty  8) ).

So perhaps there's place for a (maybe even no longer free?) Arduino IDE-Pro to sit alongside the current and always free Arduino IDE-Am
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 11:11 am

Professionals need better tools than amateurs like 16yo schoolgirls, since they have time constraints and get paid to make stuff quickly and cleanly (not quickly and dirty  8) ).


I smiled when I read that, because the implication is that, somehow, if you pay for something you get a better product.

I have some software running on my Mac (I'm not going to name it because the exact product isn't relevant) which I find doesn't do exactly what I want, or if it does, I don't understand how to make it do it. I paid good money for this, so I expect professional support.

I joined their forum, and posted a polite message describing my problem, and asking for a solution. On July 3rd 2012. That's a week ago. Not a single response. Nothing.

Meanwhile, on this forum here, for the "free" software, you generally get a response within an hour, if not 10 minutes.

And as for "dirty" ... I have stuff running here (on the Arduino) in this house. It runs for months without rebooting. It works, and works perfectly. I would not characterize it as "dirty".
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 11:23 am
Perhaps go and get a professional tool, like the Atmel development environment? I tried to use that with the latest version (AVR Studio 5 at the time) and found it would not go into parallel programming mode on the AVR Dragon. So I submitted a support ticket in May this year. No response of any kind from Atmel. And then the ticket was quietly closed.

So, yeah, go buy your expensive development environments. They better do exactly what you want, because if they don't ... forget about getting support.




Ticket 639270: "Cannot do parallel programming with Dragon"
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 07:33 pm
Quote
And as for "dirty" ... I have stuff running here (on the Arduino) in this house. It runs for months without rebooting. It works, and works perfectly. I would not characterize it as "dirty".


Why only months? Isn't it reliable?

I'm not being cheeky, just wondering. I have an ARM based system running linux and it the only time I can recall it rebooting without me telling it to was when there was a massive thunderclap directly overhead.

My installation was designed with much though to making it lightning proof, so the short coming is mine.

Shouldn't Arduino based hardware run indefinitely rather than just "for months" ?

BTW I agree that paying does not always guarantee support.
Title: Re: what about debugging?
Post by: AWOL on Jul 10, 2012, 07:56 pm
With as little memory as an Arduino, if the code makes it over the millis rollover, there's a pretty good chance that nothing else is going to stop it, unless you've got a memory leak that drips only every rollover.
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 07:57 pm
Jimbo:
Quote
We mustn't lose sight of Arduino's provenance and original purpose, which (at least as I see it) was to let a bunch of lay folk write code and get it into a processor in a bit of a quick-n-dirty way so they could make stuff happen in the real world.



Yes, I mentioned Visual Basic above in this thread. VB allowed people who could not program to press a few buttons and make a .EXE , the results were so disasterous that I evenually refused to waste any more time installing and evaluating anything based on the VBRUN runtime libs.

Making an easy entry path into making things work will be very inspiring and certainly get a lot more people hacking and experimenting. I hope the similarity with VB ends there ...

The idea of making it quick and easy to get some results and the hardware abstraction provided by the libraries are great features. But for more serious development I'd prefer full debugging capabilities.

Anyone able to confirm my idea that using an atmega8 or 128 in a UNO should allow full debugging with ATJTAGICE II ?



Title: Re: what about debugging? - Arduino debugger preview
Post by: visualmicro on Jul 10, 2012, 10:52 pm
Visual Micro has a debug tool (http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx) in beta for Visual Studio. It supports all arduino projects (memory allowing). The debugger uses hardwareSerial, softwareSerial or fastSerial. Break/pause can be optionally enabled along with many other useful features. In all cases you don't have to write a single line of debug code.

Arduino debugger video here (http://screencast.com/t/szL7FyXB8UF)

The video demonstrates first time use of both Visual Micro and the Debug Tools. The first task is simply to increase the width of the visual studio arduino boards list which most people do not realise can be done :) You will see that when the debug session begins the debugger windows are moved and docked. Visual Studio will remember the positions of the tool bar controls and tools windows so you only need to do this once. Optionally, when moving tool windows you can hold down the CTRL key to prevent them from docking.

The first part of the video shows moving the user interface around and the last part shows a normal compile, followed by a debug compile with various trace messages. Break/pause is not enabled for this example which means that all breakpoints become tracepoints. (Sorry no sound)

It's our first video and its not the best :) Better youtube videos to follow shortly.
Title: Re: what about debugging?
Post by: nickgammon on Jul 10, 2012, 11:07 pm

Why only months? Isn't it reliable?

I'm not being cheeky, just wondering.


You are joking, I hope. It isn't that it crashes every 3 months. It's just that the power tends to go off about that often.
Title: Re: what about debugging?
Post by: ardnut on Jul 10, 2012, 11:15 pm
Yes, that looks like a pretty fully featured debugger. I don't really want to change OS tho' .
Title: Re: what about debugging?
Post by: westfw on Jul 11, 2012, 11:19 am
Quote
By the late 80's gdb was already fully working in many embedded environments

Um.  For x86 and 68000 class CPUs...

Since Arduino generates standard C/C++/elf/etc, you can use standard AVR debug tools like AVR Studio and JTAGICE/Dragon/simulator and such.  That'd be the "professional" solution (just throw cash at the problem.)  AVRAICE is a shim that ties gdb to JTAGICE if you prefer the gnu debug tools.

Atmel apparently doesn't document their debugging features, which is sorta sucky of them, IMO.  Otherwise ArduinoISP could support some debugging features.

The Visual Micro "invasive, software based" debugging sounds interesting.  It'll be interesting to see how well it works. Unlike x86 and 68k, the AVR doesn't have a lot of the support needed for a good debugger, and having code in flash where you can't swap in breakpoint instructions "on the fly" is a pain.

I always thought "IDE" referred to the integration of the editor and the compiler?  I guess they've pretty much always had debuggers as well.
Title: Re: what about debugging?
Post by: JimboZA on Jul 11, 2012, 11:40 am

  I guess they've pretty much always had debuggers as well.



Yeah, that's what  Wikipedia (http://en.wikipedia.org/wiki/Integrated_development_environment) says.... must be true if it's in Wikipedia  8)
Title: Re: what about debugging?
Post by: nickgammon on Jul 11, 2012, 11:48 am

But for more serious development I'd prefer full debugging capabilities.


Oh, aye. Serious development.

In the early days, when whole banking systems, and insurance systems, were written without IDEs and debuggers. I suppose they weren't serious.
Title: Re: what about debugging?
Post by: dxw00d on Jul 11, 2012, 02:47 pm
My early programming was for British Shipbuilding (Vosper Thornycroft), using COBOL/CICS/DL1. There was no IDE (only XEDIT, and batch compilation) and very little scope for debugging tools on System 360/370, so it was all about watching what came out for what went in, and ploughing through dump listing.
Title: Re: what about debugging?
Post by: JimboZA on Jul 11, 2012, 02:50 pm

My early programming was for British Shipbuilding (Vosper Thornycroft), using COBOL/CICS/DL1. There was very little scope for debugging tools on System 360/370, so it was all about watching what came out for what went in, and ploughing through dump listing.


Only debbugging aid I had when learning Fortran on a 370 was someone helping you get your punched cards back in order when you dropped them....
Title: Re: what about debugging?
Post by: dxw00d on Jul 11, 2012, 03:43 pm
Fortunately, I started just after they took the card readers off. VM-CMS made life a lot easier. Rexx made life even easier, when it arrived.
Title: Re: what about debugging?
Post by: AWOL on Jul 11, 2012, 03:47 pm
A maximum of four batch runs a day very quickly hones your attention-to-detail and debugging skills.

Oh yes, and inserting NOPs into your hand-assembled PAL-8 programs, to allow you to slip in extra instructions later.
Title: Re: what about debugging?
Post by: dxw00d on Jul 11, 2012, 04:03 pm

A maximum of four batch runs a day very quickly hones your attention-to-detail and debugging skills.


True. We weren't actually restricted as to how many jobs we could submit to the dev partition, but all the other devs were using it too, so four runs sounds about right.
Title: Re: what about debugging?
Post by: fat16lib on Jul 11, 2012, 04:36 pm
I am really old and started embedded programming in the 1960s.  We debugged using the front panel switches and lights.  All the registers and some of the processor status was shown.  You could use the switches to enter data into memory or registers.

Single stepping was the last resort.

This machine had eight instructions and the lights on right side decode the instruction.
(http://www.pdp8online.com/straight8/pics_front_panel/med/lights.jpg)
Title: Re: what about debugging?
Post by: AWOL on Jul 11, 2012, 04:40 pm
Quote
You could use the switches to enter data into memory or registers

Yup, that's why we put the NOPs in.
To have to toggle the whole lot in again just to insert another instruction was too much trouble.

(I've also done the opposite in a field repair on some UV-EPROMs - substituting a JSR xxxx with NOPs)
Title: Re: what about debugging?
Post by: fat16lib on Jul 11, 2012, 06:20 pm
I forgot one comment.  Note the yellow mass of wires above the panel.  That is how the machine back-plane was wired.  Much of the stuff we built back then used wire-wrap instead of PCBs.
Title: Re: what about debugging?
Post by: bperrybap on Jul 11, 2012, 07:28 pm

Quote
By the late 80's gdb was already fully working in many embedded environments

Um.  For x86 and 68000 class CPUs...

Don't forget the Intel i960 and by the mid 90's the ARM support was there and obviously with full gdb support.

It just strikes me as odd that more than 20 years after good source level debugging has been available that
a processor like the AVR lacks some internal hardware capabilities and IDEs like the Arduino IDE don't at least provide
some mechanisms to at least make it a bit easier for those that want to push things further for a software only
debugger solution.

Quote

Atmel apparently doesn't document their debugging features, which is sorta sucky of them, IMO.  Otherwise ArduinoISP could support some debugging features.

The Visual Micro "invasive, software based" debugging sounds interesting.  It'll be interesting to see how well it works. Unlike x86 and 68k, the AVR doesn't have a lot of the support needed for a good debugger, and having code in flash where you can't swap in breakpoint instructions "on the fly" is a pain.


I'm guessing that the reason their debug interfaces are not documented is that I bet
if using something like debug wire or JTAG that there is a way you could circumvent the read-only fuses.

While the lack of documented debugger interfaces on the AVR and its harvard architecture does makes
things more difficult for a software only debugger implementation, I don't think it is prevents it.

The biggest thing I find missing in the AVR is the lack of TRAP instruction.
The current gdb sets soft breakpoints by inserting a BREAK instruction into the flash which is a NOP if
the debug fuse isn't set. But the BREAK instruction requires atmels  h/w in order to use it.
To stay in a s/w only implementation, avr gdb can be changed to use some other instruction sequence
but it is difficult to find something that is a single instruction. Not that it has to be a single instruction
but it can make things easier.
I've looked at using a pin change interrupt to simulate a BREAK/TRAP.
You can then use a single instruction to set the pin level when you want the "trap", but that potentially burns a pin.
But it also does allow using a switch input to drop into the debugger.
(If you want to really get control of everything including the ability to break in ISR code
you have to steal the highest priority interrupt)

Swapping in the "break" instruction sequence into the flash can be done but is tricky as it
can require some support in the bootloader section in order to modify the users flash contents.
But it's definitely doable. It requires a bit of tricky code that can flip between user and bootloader code
(This is another place where a TRAP instruction would be useful)

Single stepping can be done without resorting to modifying the flash with some clever code
that uses a HARD stuck interrupt (using the same interrupt/pin that could be used for regular breakpoints).
The Atmel hardware solutions don't do this, they set a BREAK instruction in flash and then restore the code
during each single step on the non jtag implementations. This causes flash wear.

Looking at internal AVR registers and program variables is easy and comes "for free" as it just kind of works
once you have a gdbmon in place.

I know how to do it all, and I think it would only be a few hundred bytes of code at most to do it,
I just haven't spent the time tie it all together and finish it up.

--- bill
Title: Re: what about debugging?
Post by: fat16lib on Jul 11, 2012, 08:34 pm
Here is a recent article on using DebugWIRE with AVR Dragon on an Arduino.   It uses an Eclipse plugin.  AVR Dragon is a programmer/debugger that costs $50.96 from DigiKey.

http://husks.wordpress.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/ (http://husks.wordpress.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/)

You need to modify the Arduino to use DebugWIRE since the cap that does the reset pulse for download interferes with DebugWIRE.  DebugWIRE is a one wire serial protocol at F_CPU/128 using the reset pin.
Title: Re: what about debugging?
Post by: nickgammon on Jul 11, 2012, 11:52 pm

Oh yes, and inserting NOPs into your hand-assembled PAL-8 programs, to allow you to slip in extra instructions later.


In one of my early jobs we were actually told to include this in our code:

Code: [Select]
01 PATCH.
  03  FILLER  PIC X(300).


When you needed to do patches (like, add something extra) you patched in a JMP to the patch area, added your extra code, and jumped back.

This was in the days when compiles took half an hour, and that was after waiting an entire day for "machine time".
Title: Re: what about debugging?
Post by: graynomad on Jul 12, 2012, 12:09 am
I worked on a system once that used a bit-slice processor with a stack only a few levels deep, maybe 4 or 5 IIRC and at least 2-3 levels were taken by the normal running code.

With such a small stack you were never game to CALL anything to add a patch so we always did a JMP to and a JMP back again.

What a bloody maintenance nightmare.

And for a heads up on the LPC debugging, I've been using it for a couple of days now and am really impressed. For years I've been a printf-and-toggle-pins debugger but for non-realtime stuff a real debugger is a breath of fresh air that has allowed me to find and fix bugs in no time flat that would have taken me half the night.

And if I want printf it's there in "semihosting" mode, whereby that sort of IO is trapped by the debugger and directed to the IDE console. Bloody marvellous.

______
Rob


Title: Re: what about debugging?
Post by: westfw on Jul 12, 2012, 06:50 am
Quote
you patched in a JMP to the patch area

The debug tool on tops10/20/etc (DEC's mainframe computers) ("DDT") had a command (ctrl-\ according to the online ITS manual) to do this for you.  It would insert a jump to "PAT" at the open location, open PAT and allow you to enter code (DDT included a line-at-time-assembler), and then there was another magic command to close the patch by redefining PAT and inserting a jump back to the original location+1...

Quote
The Atmel hardware solutions ... set a BREAK instruction in flash and then restore the code during each single step on the non jtag implementations.

Really?  I was hoping there was some single-step mode available only via the debug interface.  Rats.

And yeah, a real debugger is much nicer than serial.print().  Though I'm not sure that it's explainable to a beginner.

Title: Re: what about debugging?
Post by: fat16lib on Jul 12, 2012, 04:07 pm
westfw,

There is a single-step capability for AVR. 

I posted this link above about DebugWIRE http://husks.wordpress.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/ (http://husks.wordpress.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/).

The article demonstrates single-step with an Arduino.
Quote

As the exercise, you can single-step (step into/step over) until you get into your loop() routine, and then you can use step-over each of the digitalWrite() commands, and you should see the light on the Arduino change accordingly.


Once again you must modify the Arduino since DebugWIRE is a one wire serial protocol over the reset line and the cap that does the auto reset messes up the serial which runs at F_CPU/128.
Title: Re: what about debugging?
Post by: ardnut on Jul 12, 2012, 09:00 pm
thanks for those comments and links , fats. Looks useful.

[old-git-story] when I was a lad we used to have to program directly in machine code and make the holes in the punch cards ourselves with knitting needles.... [/old-git-story]



Title: Re: what about debugging?
Post by: dxw00d on Jul 12, 2012, 09:11 pm
Quote
make the holes in the punch cards ourselves with knitting needles

Not far from the truth.
Title: Re: what about debugging?
Post by: nickgammon on Jul 13, 2012, 12:51 am
http://en.wikipedia.org/wiki/MONECS

When I started we used MINITRAN which was a "mini Fortran" compiler invented by Dr. Len Whitehouse at Monash University.

In order to make computing available to school children, they used punched cards with pre-punched chads (I think you still use those in elections in the USA?) where you used a paper-clip to push the chad all the way through, exposing the hole.

Down one side were pre-printed commands (eg. GOTO, LET, READ, WRITE, IF) and then the rest of the card let you do letters or numbers. These were "punched" during class, and then the teacher would take them all together in a tray out to Monash Uni, they would be run overnight, and he would collect the cards, and the printout, in the morning.

There were various controls, like a maximum CPU limit of 10 seconds, maximum paper usage of 10 pages, and so on. The compiler was in reality a program written in "real" Fortran which implemented the "mini" Fortran as a single app. It read the cards, detected a new program (special card), emulated the code, and printed the results.
Title: Re: what about debugging?
Post by: graynomad on Jul 13, 2012, 01:23 am
Sounds like an early version of Arduino :)

______
Rob
Title: Re: what about debugging?
Post by: mnoriaki on Jul 14, 2012, 10:41 am
This is not direct answer to the first question, but you can monitor pin status with this:

http://n.mtng.org/ele/arduino/arduinomon.html

It sends current pin status and analog pin values to PC. PC sends a command to Arduino when you modify a pin value or the output mode of a pin.

// Noriaki Mitsunaga