Shop OBEX P1 Docs P2 Docs Learn Events
inter cog communication — Parallax Forums

inter cog communication

stravagstravag Posts: 4
edited 2007-09-11 18:41 in Propeller 1
hello

i have a quick question.

i have an application where one cog has a controller function, starting other cogs to do certain jobs. now it's important for the controller to know when the other cogs have finished their job.
at the moment i'm doing this by polling active methods of the objects running in other cogs to find out if the job is done. similar to the object explained in the "Propeller Manual" on page 118.

i dislike the idea of polling to find out if a cog has finished it's job. is there a way of having some sort if interrupt to trigger the controller?

Comments

  • Tom WalkerTom Walker Posts: 509
    edited 2007-09-07 14:35
    Would it be possible to have the "other" COG set a flag when it is done? Two-way communication trumps interrupts [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Truly Understand the Fundamentals and the Path will be so much easier...
  • ALIBEALIBE Posts: 299
    edited 2007-09-07 14:45
    stravag
    I have a similar situation in my project. When a Cog completes a process, i simply set a flag (example __bCog1Completed := 1) that is specific to that Cog/process. This variable will be available and is accessible by other Cogs. The "main" Cog checks the value of this and other "status" flags and takes action.

    hope that helps

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "any small object, accidentally dropped, goes and hides behind a larger object."

    ·
    ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-09-07 16:33
    You can use locks too. They're not just for resource contention issues.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-07 16:53
    stravag said...
    ...i'm doing this by polling active methods of the objects running in other cogs
    -This is a basic misunderstanding! There is no such thing as an "object running in a COG"!!!
    - Setting and reading variables is really, really fine. Don't get confused with the problems the large guys have with assembly programming.
    - There is absolutely no need to use a LOCK just because it has a fancy name and looks like a "flag",
    whatever that may be...

    @stravag: o.k. I see now what you want to say: As you cannot access variables in another object you use a "getter". This is quite all right.

    Post Edited (deSilva) : 9/7/2007 10:04:34 PM GMT
  • stravagstravag Posts: 4
    edited 2007-09-10 08:38
    hi, thanks for all the replies

    so you'd advise me to use something like this "active" method and poll it in the controller process to see if the cog running the subroutine is finished. so i assume there really is no "nicer" way to do that than polling (whether i'm polling a method or flag ... it's still polling [noparse]:)[/noparse] )

    i was hoping there is something like "wait for cogid" or something... but i can live with that. just wanted to make sure i'm not coding some sort of hack when there is something neat implemented in spin.

    thanks for your help

    
VAR
  long stack[noparse][[/noparse]9]       'TODO: check size with Stack Length Tool!
  byte cog            'id of cog in use, if any

PUB read(numberoftags, baudrate) : success
{{start read procedure of IEEEComponent in new cog}}

  stop
  success := (cog := cognew(readProcedure(numberoftags, baudrate, @stack) + 1)

PUB write(commandptr, ieeeaddr, baudrate) : success
{{start write procedure of IEEEComponent in new cog}}

  stop
  success := (cog := cognew(writeProcedure(commandptr, ieeeaddr, baudrate), @stack) + 1)  
  
PUB stop
{{stop running process }}

  if cog
    cogstop(cog~ - 1)

PUB active: yesno
{{return TRUE if process is active, FALSE otherwise }}

  yesno := cog         

PRI readProcedure
''do someting

  stop 'done

PRI writeProcedure
'' do something
  
  stop 'done
  • ciw1973ciw1973 Posts: 64
    edited 2007-09-10 12:05
    deSilva said...
    - There is absolutely no need to use a LOCK just because it has a fancy name and looks like a "flag",
    whatever that may be...

    Agreed. There's no real advantage to using a lock instead of just writing to bits in a piece of shared HUB memory, unless of course you are so short of hub memory that you don't have even a single byte free.

    If you can spare the I/O lines, your best bet is to use eight lines (or however many you need) as flags. They can be set/cleared/read without the wait associated with hub instructions, and you can also use the WAITPEQ/WAITPNE instructions as a simple way of handling blocking.
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-09-10 14:35
    I didn't mean to suggest that locks are a better way, just another way. straveg was asking for alternatives. Either way you have to poll them because there is no blocking mechanism in the SPIN language to wait for cogs to finish, like some languages have available to wait for threads to finish. I agree that setting a variable flag and polling it's value is the best solution in most cases.

    I was looking in the manual for a function to check a cog to see if it's running and there apparently is no such function. Would be nice in some cases.

    Ken

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • Stan671Stan671 Posts: 103
    edited 2007-09-10 18:40
    stravag said...
    so i assume there really is no "nicer" way to do that than polling (whether i'm polling a method or flag ... it's still polling [noparse]:)[/noparse] )

    i was hoping there is something like "wait for cogid" or something...
    Isn't a "wait for cogid" really just polling behind the scenes anyway?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Stan Dobrowski
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-10 18:51
    Stan671 said...
    Isn't a "wait for cogid" really just polling behind the scenes anyway?
    A very clever remark!

    Even an interrupt is performed in that the processor - by the way! - checks some lines during each instruction cycle before deciding where from to fetch the next instruction...

    The word "polling" is generally used for one of three basic software techniques to respond to asynchronious events:
    - "waiting" (while sleeping in a power reduction mode)
    - "polling" (and doing other things in case of a negative result)
    - "serving interrupts" (forwarding the "polling" to the processor hardware)

    There are pros and cons for each of the above techniques....
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-09-11 18:41
    Stan and deSilva are correct in thier observation, there is one exception which can afford a few milliwatts of power savings for battery based applications, or those high speed applications where checking a flag, indicator, status byte etc before retrieving the data is too slow. And that is using a physical pin as an indicator, when the producer has data ready it asserts a pin. The consumer is in a waitpe or waitpne on the pin in question, when the pin is asserted the consumer will wake up and start executing on the next clock cycle. The downside of this method of course is that it requires a free pin.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
Sign In or Register to comment.