Welcome to the Parallax Discussion Forums, sign-up to participate.
KeithE wrote: »
... Having a nice hardware debugger for a single cog at a time plus hub RAM could get you pretty far.
...Maybe they are only too simple minded to use a debugger.
Mike Green wrote: »
I would add that there were no debuggers back in the day. Maybe there was a control panel with pretty lights and buttons that was rarely useful. You had to have a picture in your head of what the program was supposed to do and what it actually did and occasionally you needed a little more information to reconcile the two, so you added some debug output.
I've used sophisticated debuggers and occasionally (rarely) they've been useful, but not necessary. As with many tools, you may work better with the tools you're used to. That doesn't mean that they're the only tools for the job and you better be ready to use other tools if that's what's there.
Heater. wrote: »
... Debuggers are for the weak minded who don't understand the code they have written...
Mike Green wrote: »
"too simple minded to use a debugger"
Far from it. Every such tool has a cost for implementation. If you're going to have a symbolic debugger, where are you going to store the symbol table? How about the table that stores the correspondences between code address and source line? If you're dealing with a PC or something of that scale, you're going to have a hard disk (or equivalent) with a file system and gigabytes (or even terabytes) of storage, so a symbolic debugger makes sense. If you're dealing with a microcontroller like the Propeller 1, you're going to have 32K, maybe 64K if you're lucky ... without a file system. The Propeller 2 will typically have a megabyte of flash, maybe more, so it makes more sense there, but is not a certainty.
As others have mentioned before, debugging real-time code or I/O drivers is different from what you may be used to. A debugger changes timing and that may be where the problem is. If I'm explicitly adding debug code, I can choose where it goes so it shouldn't (no guarantees) affect the timing I'm concerned about. That's not what a generalized debugger does.