Parallax Propeller 2 Multicore Microcontroller Release Date Update

124»

Comments

  • 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.
  • KeithE wrote: »
    ... 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.
  • @Tor,

    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 am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • dnalor,
    ...Maybe they are only too simple minded to use a debugger.
    It's probably best we ignore that insult to a large proportion of the forum member here.

    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 :)

  • While us oldies learnt to do without good debuggers, there is nothing like having a good debugger sometimes.

    Newer programmers seem to be more reliant on debuggers.

    There is nothing wrong with either method, as long as the job gets done efficiently.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Mike GreenMike Green Posts: 22,577
    edited October 25 Vote Up0Vote Down
    @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.
  • Mike Green wrote: »
    @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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • microcontrollerusermicrocontrolleruser Posts: 546
    edited October 25 Vote Up0Vote Down

    Let's let Parallax have the final word on this. :smile:

    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!'. :smile:
    JUNIOR ENGINEER
  • Heater. wrote: »
    msrobots,
    ... Debuggers are for the weak minded who don't understand the code they have written...
    My comment was the answer to this statement.
    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.

    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.
    οἶδα οὐκ εἰδώς
  • OK, MCU's have break points. Sounds great.

    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.












  • Well - seems to be a lot hot air in here.

    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


    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.