Debug with it's own cog?

Comments

• JonnyMac Posts: 9,572

  2026-01-02 21:14

  I used to do that, too, and still do when I want nice formatting on the output terminal (e.g., PST). If your background cog is simply displaying global variables being used by your main cog, then it shouldn't have any impact on the speed of your main cog.
• Wuerfel_21 Posts: 5,762

  2026-01-02 21:34

  Generally whatever is happening in one cog does not slow down or speed up another. The Propeller is specifically designed to avoid this sort of "scary action at a distance".

  The only exception is when using locks or other forms of explicit synchronization, which relates back to debugging: The debugger uses a lock bit to arbitrate access to the serial port. If one cog is hogging this debugger lock (by constantly printing debug messages) then other cogs will wait on that lock whenever they want to print a message.
• Rayman Posts: 15,939

  2026-01-03 01:24

  This is one reason the debug terminal mode is nice. If there is a concern one can use fullduplex serial instead of debug and be sure…
• evanh Posts: 17,037

  2026-01-03 19:10

  Use the DEBUG_COGS = <bitmap> constant to setup which cogs have debug enable. Then that's a sure way to know a cog is not slowed by debug.

  PS: Sequence serialising via waiting on mailboxes also causes cogs to impact each other.
• mwroberts Posts: 85

  2026-01-04 14:27

  The "debug on" switch before compile/upload only starts a debug program on the computer running Pnut/spin ide/prop tool?
• JonnyMac Posts: 9,572

  2026-01-04 17:13 edited 2026-01-04 17:14

  Debug output is run in the Propeller, it uses the upper 16K of RAM when enabled. Debug statements are just really fast serial messages. In PNut, a special window is open for basic debug, but in Spin Tools it's just a terminal window (that has the benefit of scroll-back). In PNut, Propeller Tool, and Spin Tools, special windows can be invoked to interpret and display messages in a nice format. The one I tend to use is the terminal window, though I have used the plot window a couple times for graphics-heavy displays.
• ManAtWork Posts: 2,266

  2026-01-05 14:33

  @mwroberts said:
  In a lot of my programs I'll start a second SPIN cog and run all the debug stuff in it's own method.

  I also call special debug methods written in Spin2 from the main code which is usually written in C for most of my projects. This is useful if I need the graphical debug stuff like a scope display. Of course, if it's only a normal function cal it still slows the caller down. But if you use an extra cog to output global variables or hub memory it has no influence on the execution times of other cogs. It also makes time-synchronous waveform output much easier. Real time violations (too long delays) are easily spotted by flat regions in the waveform.