next topic »

[Reply #30 on:]

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.

[Reply #31 on:]

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.

[Reply #32 on:]

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)

[Reply #33 on:]

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.

[Reply #34 on:]

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.

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

[Reply #35 on:]

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/

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.

[Reply #36 on:]

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:

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".

[Reply #37 on:]

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

[Reply #38 on:]

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...

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.

[Reply #39 on:]

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/.

The article demonstrates single-step with an Arduino.

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.

[Reply #40 on:]

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]

[Reply #41 on:]

make the holes in the punch cards ourselves with knitting needles

Not far from the truth.

[Reply #42 on:]

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.

[Reply #43 on:]

Sounds like an early version of Arduino

______
Rob

[Reply #44 on:]

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