PDA

View Full Version : inter cog communication



stravag
09-07-2007, 08:20 PM
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?

Tom Walker
09-07-2007, 09:35 PM
Would it be possible to have the "other" COG set a flag when it is done? Two-way communication trumps interrupts :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

ALIBE
09-07-2007, 09:45 PM
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 (http://aliben.wordpress.com/). In search of building autonoumous land robot

Ken Peterson
09-07-2007, 11:33 PM
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?

deSilva
09-07-2007, 11:53 PM
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

stravag
09-10-2007, 03:38 PM
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 :) )

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[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

ciw1973
09-10-2007, 07:05 PM
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 Peterson
09-10-2007, 09:35 PM
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?

Stan671
09-11-2007, 01:40 AM
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 :) )

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

deSilva
09-11-2007, 01:51 AM
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 Baker
09-12-2007, 01:41 AM
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 (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)