The return of my problems?!?!?

Microcontrolled

This is a question about returning values among cogs, and anyone can answer if they know. It's stumped me for a good hour. Here's the scenario:

A program is written. We will call this program "demo"
"Demo" calls a PUB in another object.
In the called PUB, a cog is launched with COGINIT. Cog 7 is the chosen cog.
Another PUB in the same object is what is launched into cog 7.
A value is returned (1 of 3 choices) by the PUB running in cog 7.

HERE IS WHAT I NEED TO KNOW: How does "demo" get the returned data from cog 7 from the "coginit" PUB??

I have tried several methods, all have not worked. If anyone has any idea what could be causing this, please help!

Thanks,
Micro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!

Use the Propeller icon!!

Follow me on Twitter! Search "Microcontrolled"

Phil Pilgrim (PhiPi)

You'll have to communicate the "returned" value via a hub variable:

1. Set the variable to an invalid value.
2. Start the new cog.
3. The new cog does its thing and sets the hub variable to some new value.
4. The top-level program sees the value change to a valid number and uses this as the return value.

BTW, you should not be using COGINIT to start cogs; use COGNEW instead.

-Phil

Microcontrolled

Thanks Phil! I'll try it out. I am using COGINIT because it needs to be the last cog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!

Use the Propeller icon!!

Follow me on Twitter! Search "Microcontrolled"

MagIO2

Demo calls the pub passing the address of a variable ( for example @cog_ret ) which is defined in demo.
The function of the other object will now have a parameter variable containing this address ... let's call that cog_ret_addr.
(definition of the function is something like: PUB other_function( cog_ret_addr ) )
It starts the COG with COGINIT(7, cog_function( cog_ret_addr ), @some_stack ).

The function defined as PUB cog_function( cog_ret_addr2 ) also has a parameter variable which now contains a copy of the address - let's call that cog_ret_addr2 to point out that it's different to the variable in other_function even if the name could be the same.
The COG now·can write back the result with long[noparse][[/noparse]cog_ret_addr2]:=42.

Note: you only need the address operator once. All parameter variables already contain the address. And a address is what's needed to use the long[noparse]/noparse, so what you want is to use the address contained in cog_ret_addr2.

It's a good idea to name the variables in a way you can easily see if it contains a value or a address.

Post Edited (MagIO2) : 4/19/2010 9:15:20 PM GMT

localroger

Microcontrolled, why does it have to be cog 7? All the cogs have identical capabilities. If you use cognew you just save the cogid it returns in case you need to cogstop it (that's the only thing you even need the cogid for). The problem with choosing fixed cog numbers is you could get serious object compatibility issues with multiple projects coded to demand the same cog, when others are available.

Microcontrolled

@MagIO2: This might work. I need to use that. Thanks for the help!
@localroger: This method is part of a Propeller OS. Cogs 0,1,and 2 drive the input and display, cogs 3-6 are for instant running applications and installers, and cog 7 is reserved for popup windows and notifications. Some of the cogs for applications will be taken up as this expands, but at least 2 will be left. Otherwise I would just use cognew.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!

Use the Propeller icon!!

Follow me on Twitter! Search "Microcontrolled"

kuroneko

Still, why do you care which ID they are? Communication is through the hub (most likely) so it doesn't really matter. What are we missing here?

mctrivia

only advantage i can see to static cog id is it saves a byte of memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.

BradC

mctrivia said...
only advantage i can see to static cog id is it saves a byte of memory.

Err.. no. The constant involved in specifying the cog number consumes at *least* a byte of memory.
(in the case of 7, it's 2 bytes)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

StefanL38

cognew can occupy ANY cog from 0 to 7.
So if you use only one single cognew anywhere in the program it might happen that it catches one cog that you intend to use by a coginit and then things are messed up.
If you use ONLY cognew the cog-numbers will change after each reset but they NEVER will be used overlapped.

This means: if cog 7 or any other cog is not already initialised by using coginit and another app uses a cognew it might happen that the cognew occupies cog 7.
Now if you execute coginit with cog 7 (which is already in use) the app running in cog 7 gets terminated and you start the cog new with "popup-window"

From this example you can see how much you have to care that this situation NEVER happens. If you use Cog-ID-variables and cognew you still have the possability
to do well defined cogstops but the situation described above can never happen.

Every sophisticated software uses the ID-technique. Regardless beeing windows (not so well sophisticated ) linux, OpenOffice using elements like graphics, frames or whatever

best regards

Stefan

MagIO2

I think he won't stop any of the predefined COGs, they'll always run in the background. And as the OS will be loaded first each OS conform application will never interfere with the COGs as long as those don't use COGINIT as well.

Nevertheless you are right .. there is no benefit in using COGINIT in this case. The only reason for using COGINIT for me was the FSRW which had problems at max speed because it was running in the 'wrong' COG.