jonathan.forbes@canremote.uucp (JONATHAN FORBES) (03/23/90)
Well, my development cycle is quite quick, because all my include files
are in a RAD: disk, which my system boots from. A software error hardly
ever damages RAD: (in fact, it hasn't happened in several months, now.)
For debugging, I use the old fashioned method of using printf()'s at key
points. Or, if I really don't know what's causing the bug:
.. line1 ..
puts("--A--");
.. line2 ..
puts("--B--");
.. line 3..
puts("--C--");
.
.
Yes, very very messy, but it's always worked for me (not that I have
that many GURU-type bugs in my programs.)
I've found that printing things at key points is much easier than
loading up a source level debugger (but then that's just my point of
view.)
---
* Via ProDoor 3.1R lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/25/90)
In <90032513573825@masnet.uucp>, jonathan.forbes@canremote.uucp (JONATHAN FORBES) writes: > >For debugging, I use the old fashioned method of using printf()'s at key >points. Or, if I really don't know what's causing the bug: > >.. line1 .. >puts("--A--"); >.. line2 .. >puts("--B--"); >.. line 3.. >puts("--C--"); > >Yes, very very messy, but it's always worked for me (not that I have >that many GURU-type bugs in my programs.) I just picked up a really nifty little piece of hardware from Black Belt Systems. It's called the 'SoftPanel', and consists of an array of 4 rows of 8 LEDs, just right for four bytes, two words, or one longword of debugging data, or for use as 32 bits of status flags. Setting an LED on or off is a simple matter of writing to the apropriate address, and requires only a single line of code in your program for each operation to the LEDs. Similarly, one line of code is sufficient to write a byte, word, or longword to the LEDs. It is available for use as son as the machine comes up, even before autoconfig has taken place, so it is quite useful for debugging such things as ROM-based device driver intitialization. It is hardwired into the 'cartridge' area at $f00000 or $f00100. The unit is supplied with an ARexx host program that allows you to maniipulate the LEDs in a number of ways, directly from an ARexx script. Provided are LED ON/OFF, BLINK (at specified rate), SET BYTE, WORD, or LONG value, VERTICAL or HORIZONTAL BAR GRAPH, and Supra internal modem monitor LEDs, as well as a SENSE to return the status of any LED. Additionally, it has a pair of commands that will set an intercept (via Setunction), on any library call, turn an LED on or off when the routine is called. A few other nifty programs are included. sysload - gives a 'bargraph' indication of system activity in the bottom row of LEDs panelled - Allows you to use a vertical column of three LEDs (user specified) to monitor any device by driver or volume name. The three LEDs are indicative of READ/WRITE/VERIFY, the latter being turned on with any write, and turned off when the 'update' is sent, providing an indication of when it is safe to reset after a wrote to disk. I find it to be invaluable for showing information abouta program in development, especially programs that cannot easily send debugging output to the screen. I am not affiliated in any way with Black Belt Systems, other than as a customer and friend. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
p554mve@mpirbn.UUCP (Michael van Elst) (03/27/90)
In article <1294@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >I just picked up a really nifty little piece of hardware from Black Belt >Systems. It's called the 'SoftPanel', and consists of an array of 4 rows of 8 >LEDs, just right for four bytes, two words, or one longword of debugging data, >or for use as 32 bits of status flags. I've used some even cheaper method. try: #ifdef DEBUG #define flashcolor(x) { int i; short *p = (short *)0xdff180; \ for (i=0;i<100000; ++i) *p = x; } #else #define flashcolor(x) #endif and flashcolor(...) when you want to show that some piece of code has been executed. Lateron, (before I get hands on the ddebug.lib) I wrote a library that writes messages to some replyport and a real process dumps them out to a console window. If you just want to show intermediate results, this is a nice thing, because you don't need to manage your own output window. Just 'kprintf(...)' in your program the values you want to show. The ddebug.lib comes from commodore (like the debug.lib) and allows printfs to the parallel port (the debug.lib goes to the serial port) without using PRT or the printer.device. Michael van Elst p554mve@mpirbn.mpifr-bonn.mpg.de
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/28/90)
In <693@mpirbn.UUCP>, p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <1294@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>I just picked up a really nifty little piece of hardware from Black Belt >>Systems. It's called the 'SoftPanel', and consists of an array of 4 rows of 8 >>LEDs, just right for four bytes, two words, or one longword of debugging data, >>or for use as 32 bits of status flags. > >I've used some even cheaper method. Yeah, but does it conjure up images of monster mainframes with all their flashing lights? :-) -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+