Shop OBEX P1 Docs P2 Docs Learn Events
SPIN Method to detect what cogs are in operation? — Parallax Forums

SPIN Method to detect what cogs are in operation?

cjrussellcjrussell Posts: 6
edited 2012-10-25 16:19 in Propeller 1
Hey all, first time poster, long time STAMP user. I recently upgraded to the Propeller chip (taking a step away from the BS2px) and was wondering if there's a way in SPIN to detect whether a specific cog is in use? Obviously I could set some variables when I launch a cog to state whether it's alive or not, but was hoping there was some other, more elegant way of doing it. Setting variables can be a pain, especially when using someone else's SPIN code (like the FullDuplexSerial spin in the library). Any thoughts? I looked through the documentation that comes with the editor and couldn't find it, so wasn't sure if such a method even existed.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-10-25 10:13
    cj,

    Welcome to the Parallax forum!

    First, let's examine your motives for wanting to do that. Why do you need to know which cogs are in use, rather than just how many are free?

    -Phil
  • cjrussellcjrussell Posts: 6
    edited 2012-10-25 10:22
    Thanks Phil! Glad to finally join in.

    The motive behind the question is more for debugging I guess. I've been launching cogs to do very minor activities (watch a clock line, toggle a PWM, etc). I actually have a use for all 8 cogs at this point in my program I'm throwing together. I come from a more software based background then hardware (the STAMP's are a great way to cross that line!) and generally have to write code in my software to detect when a process has given up the ghost and terminated prematurely. I'm not sure how the Propeller handles a fatal error (if such a condition could exist), or if a cog could 'hang' and deadlock somewhere. So I was hoping to detect when a Cog was no longer functioning.

    I guess the problem is that I'm assuming that on a fatal error, the cog just terminates but let's the other cogs continue operation. That would be a condition I'd need to test against. If the entire chip will hang up on a fatal, then it's fairly mute now that I think about it. I have an LCD Display plugged into the chip with one row dedicated to showing which Cogs are operational. Right now when I launch the cog, I just set a bit in a variable saying it's alive. But if it terminates...how would I know? Again, assuming that a cog could terminate prematurely.

    Just getting in a little over my head and probably over-thinking this entire thing, but there yah go! Thanks again for the response!

    -Cj
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-10-25 10:38
    Cogs can either go into an infinite loop or simply terminate. There are no other failure modes. The only way a misbehaving cog can affect other running cogs is by stopping or restarting them, writing errant data to the hub that those cogs require for normal operation, or outputting data on pins that the other cogs are using. The way to tell if a particular cog is running or not is to do a sequence of cognews, recording each result, until you can't start any more, then stopping all of the cogs you just started. If the cog in question was not among the recorded results, then it is still running.

    BTW, the reason I questioned your motives is that I wanted to make sure you weren't planning to use the information to start new cogs with coginit, cognew being the preferred method in virtually every case.

    -Phil
  • cjrussellcjrussell Posts: 6
    edited 2012-10-25 10:50
    Well that solves that issue then. I'm starting everything with CogNew at the moment, didn't have plans to use CogInit as of yet, but I'll keep that in mind. Thanks again Phil, greatly appreciated!
  • MagIO2MagIO2 Posts: 2,243
    edited 2012-10-25 12:22
    Maybe your "more software based background" is why you're thinking in this premature end direction. If you have a PC program running wild it starts doing things that are forbidden by the operating system. For example trying to access memory that's not available for the program....
    But in the propeller there are no mechanisms to detect this. If you let your PASM code run into a data section, then it will execute whatever instruction will be decoded out of the data.
    So, as Phil already said, only your program can stop a COG - either the code in the COG itself stops the COG or another COG stops it.... oh ... ok ... one and only exception is the reset which stops all COGs ;o)
  • cjrussellcjrussell Posts: 6
    edited 2012-10-25 12:28
    Aye, good point there Mag. Appreciate the input, I'm trying to get more complex with my hardware designs (just playing around really, for entertainment purposes at best) and my software background tends to get in the way sometimes. Just because my PC does something, doesn't mean my own hardware will do it...just gotta keep telling myself that ;)
  • John BoardJohn Board Posts: 371
    edited 2012-10-25 16:10
    If your trying to figure out how many cogs are in use, I normally do the following:
    PUB cogsInUse | temp

temp := cognew(DoNothing, @stack)

if temp > 0
  result := temp 'Doesn't add one onto this, as the cog launched is not one that you are using permanatly, and will terminate instantly.
elseif temp==-1
  result := 8 'If the id was -1, then the prop couldn't open another cog - must be 8 cogs in operation then

PRI DoNothing

    Try that, to see if it returns the correct numbers of cogs being used.

    -John
  • kuronekokuroneko Posts: 3,623
    edited 2012-10-25 16:19
    @John: Say I have cogs 0, 3..7 running. In this case your method returns 1. Nowhere near the number of cogs in use.
Sign In or Register to comment.