A maximum of four batch runs a day very quickly hones your attention-to-detail and debugging skills.
You could use the switches to enter data into memory or registers
QuoteBy the late 80's gdb was already fully working in many embedded environmentsUm. For x86 and 68000 class CPUs...
By the late 80's gdb was already fully working in many embedded environments
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.
Oh yes, and inserting NOPs into your hand-assembled PAL-8 programs, to allow you to slip in extra instructions later.
01 PATCH. 03 FILLER PIC X(300).
you patched in a JMP to the patch area
The Atmel hardware solutions ... set a BREAK instruction in flash and then restore the code during each single step on the non jtag implementations.
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.
make the holes in the punch cards ourselves with knitting needles