Well people in this thread are disparaging of debuggers in general and have made statements that aren’t universal truths. I think that they believe that a JTAG interface and software breakpoints are all that’s possible.
All I can say is that I was involved in designing sub $1 very high volume (hundreds of millions) chips not sold as general purpose CPUs. I made damn sure to put decent hardware debugging on them for our internal developers. Things change quickly in industry and you typically need new chips every year to stay competitive. (Look at smartphone tear downs.) So if you value developer time then it makes sense to make debug as painless as possible.
If functions are walled off in cogs (UART here, I2C there) then you can probably live without full simultaneous multi core debug right? Having a nice hardware debugger for a single cog at a time plus hub RAM could get you pretty far.
>The Propeller 1 was not designed for tracing or watchpoints
I don’t see any reason that they couldn’t be added. It’s a simple processor architecture. The hard part would be writing the PC software to interface with it.
... Having a nice hardware debugger for a single cog at a time plus hub RAM could get you pretty far.
Depends what you mean by "nice hardware debugger" - there are no debug-pins, or hidden Debug hooks in P2.
Anything that is done, will need to be compiled into user code, and co-operate with user code.
This software stub has a size, and some time impact when running.
An alternative approach for less code overhead, and less time overhead, would be to use the Paired-COG feature and run Debug in one COG, & user code in the paired one.
(of course, debug of user-shared-cog code is not so easy in that case..)
There's nothing wrong with hardware support for various debugging/analysis/tracing purposes. Pour it on.
What some of us are saying is that for software *development*, there comes a point where you grow out of using debuggers. Not the other way around. If you actually need a debugger to get through a software development project then there's something seriously wrong with the method or the design.
As for other developers' code, if you can't understand their code well enough to figure out where and when variables are set, it's time to dump that code. It's useless.
In short, seasoned developers stop using debuggers after some time because there is and shall not be any need for using one.
seasoned developer. Nice. I have to remember that. I absolutely agree with you. Perhaps it was the lack of good debuggers when I did my first decade of programming, but when I finally had really nice debuggers like in VS, I did not really needed them anymore.
@Cluso99
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.
@Cluso99
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.
Before micros were released, I repaired and programmed a mini-computer that had a brilliant stepper/tracer/debugger. The mini was programmed in assembler (15+1 instructions). Assembling took hours so I often used the tracer to step thru the programs (often live) and could patch the object code without the need to reassemble.
So yes, there were some debuggers back in the early 70's.
The Javelin Stamp Integrated Development Environment (Javelin
Stamp IDE) software is a significant departure from a simple Editor
and messages window combination. When used with the Javelin
connected to a PC by a serial cable, this software can be used as a
highly integrated in circuit debugging system that allows you to run
code, set breakpoints and view variable values, memory usage, I/O pin
states and more. There is also no need for emulators; the
Javelin can be
placed directly into the circuit and debugged there.
"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.
What are you talking about? Microcontrollers nowadays have hardware breakpoints. These breakpoints I can set at runtime over some serial connection to a internal "debug hardware". Until I set a breakpoint address (click on the line in the sourcecode) the code runs at full speed. If the programmcounter then reaches the next time this address, the microcontroller breaks and I can inspect the memory.
The logic and the "tables" are in the IDE on the PC.
If I would add some debug code, then I would change the timing. Worst case would be some printf, the slowest thing I could use.
What's missing in Prop2 is, that I could set the breakpoint address from outside(from another cog) after start of the cog.
...And debug support in the IDE.
I'm not sure the hardware assistance is much better than the way we did it in the late 1970's by inserting software interrupt instructions into the program.
Thing is, after four decades of being involved in software that "has to work", I have come to a different view.
When I say "has to work" I mean things like the Primary Flight Computers of the Boeing 777. Or jet engine management units. Or secure communications software for the military.
There is no way those guys are going to rely on a bunch of code monkeys with debuggers to get the thing right. No, what they want is code reviews, unit testing, traceability, integration testing, etc, etc.
As I think you said earlier, a debugger might help you find a problem with some huge code base mostly written by others that you do not understand. That just means there are a 100 other bugs in that code base that have not surfaced yet and you do not understand.
As a practical matter I have found debuggers do not help.
When there is a lot of stuff going on in parallel and you have a problem, good luck with a debugger.
Even memory leaks are hard to find with a debugger.
It is like with them interrupts. If you do not like or need them, then just don't do it!
Same goes for debuggers, use them or not as ever you wish.
Compared to the P1 where was NO hw-debug support, besides parallel cores, the P2 does have a debug interrupt, so one core can single step another one, if wished for.
What kind of debugger gets build around it is open. but the needed hooks are there, hardware-wise.
Comments
All I can say is that I was involved in designing sub $1 very high volume (hundreds of millions) chips not sold as general purpose CPUs. I made damn sure to put decent hardware debugging on them for our internal developers. Things change quickly in industry and you typically need new chips every year to stay competitive. (Look at smartphone tear downs.) So if you value developer time then it makes sense to make debug as painless as possible.
If functions are walled off in cogs (UART here, I2C there) then you can probably live without full simultaneous multi core debug right? Having a nice hardware debugger for a single cog at a time plus hub RAM could get you pretty far.
I don’t see any reason that they couldn’t be added. It’s a simple processor architecture. The hard part would be writing the PC software to interface with it.
Depends what you mean by "nice hardware debugger" - there are no debug-pins, or hidden Debug hooks in P2.
Anything that is done, will need to be compiled into user code, and co-operate with user code.
This software stub has a size, and some time impact when running.
An alternative approach for less code overhead, and less time overhead, would be to use the Paired-COG feature and run Debug in one COG, & user code in the paired one.
(of course, debug of user-shared-cog code is not so easy in that case..)
What some of us are saying is that for software *development*, there comes a point where you grow out of using debuggers. Not the other way around. If you actually need a debugger to get through a software development project then there's something seriously wrong with the method or the design.
As for other developers' code, if you can't understand their code well enough to figure out where and when variables are set, it's time to dump that code. It's useless.
In short, seasoned developers stop using debuggers after some time because there is and shall not be any need for using one.
seasoned developer. Nice. I have to remember that. I absolutely agree with you. Perhaps it was the lack of good debuggers when I did my first decade of programming, but when I finally had really nice debuggers like in VS, I did not really needed them anymore.
Mike
I bring the view of one "simple minded" developer. Linus Torvalds on the use of debuggers:
https://lwn.net/2000/0914/a/lt-debugger.php3
Seems the opposite view is that many developers are too simple minded to not use a debugger
Newer programmers seem to be more reliant on debuggers.
There is nothing wrong with either method, as long as the job gets done efficiently.
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.
So yes, there were some debuggers back in the early 70's.
Let's let Parallax have the final word on this.
The Javelin Stamp Integrated Development Environment (Javelin
Stamp IDE) software is a significant departure from a simple Editor
and messages window combination. When used with the Javelin
connected to a PC by a serial cable, this software can be used as a
highly integrated in circuit debugging system that allows you to run
code, set breakpoints and view variable values, memory usage, I/O pin
states and more. There is also no need for emulators; the
Javelin can be
placed directly into the circuit and debugged there.
And 'That's that!'.
What are you talking about? Microcontrollers nowadays have hardware breakpoints. These breakpoints I can set at runtime over some serial connection to a internal "debug hardware". Until I set a breakpoint address (click on the line in the sourcecode) the code runs at full speed. If the programmcounter then reaches the next time this address, the microcontroller breaks and I can inspect the memory.
The logic and the "tables" are in the IDE on the PC.
If I would add some debug code, then I would change the timing. Worst case would be some printf, the slowest thing I could use.
What's missing in Prop2 is, that I could set the breakpoint address from outside(from another cog) after start of the cog.
...And debug support in the IDE.
I'm not sure the hardware assistance is much better than the way we did it in the late 1970's by inserting software interrupt instructions into the program.
Thing is, after four decades of being involved in software that "has to work", I have come to a different view.
When I say "has to work" I mean things like the Primary Flight Computers of the Boeing 777. Or jet engine management units. Or secure communications software for the military.
There is no way those guys are going to rely on a bunch of code monkeys with debuggers to get the thing right. No, what they want is code reviews, unit testing, traceability, integration testing, etc, etc.
As I think you said earlier, a debugger might help you find a problem with some huge code base mostly written by others that you do not understand. That just means there are a 100 other bugs in that code base that have not surfaced yet and you do not understand.
As a practical matter I have found debuggers do not help.
When there is a lot of stuff going on in parallel and you have a problem, good luck with a debugger.
Even memory leaks are hard to find with a debugger.
It is like with them interrupts. If you do not like or need them, then just don't do it!
Same goes for debuggers, use them or not as ever you wish.
Compared to the P1 where was NO hw-debug support, besides parallel cores, the P2 does have a debug interrupt, so one core can single step another one, if wished for.
What kind of debugger gets build around it is open. but the needed hooks are there, hardware-wise.
I still wish to have the monitor back.
Enjoy!
Mike