Explaination of COG operation needed

T Chap

It just occurred to me the first time this week that I have been doing something all along that logically doesn't make sense.

The main COG launches other cogs. As an example, the main cog launches a PID object(PIDENGINE.spin) in a new cog. The PID object has a loop that never stops, taking in the new position and constantly trying the fix the error between newpos and the real position from the encoders. But, there are several other methods that get called from the main cog, like for example pid.resetencoder or pid.clearallvalues. These methods are definitely working to reset the encoder and clear the pid values to zero. So how is it that this is happening when the cog is running the main PID loop at all times and there is no method for the main PID loop to depart and go to the other methods mentioned and return, the other methods are simply calls from the main cog? pid.clearallvalues affects the main PID loop, so on the surface, it looks like the main PID loop never even stops to allow the other things to happen. The only conclusion is that these other methods are NOT really occurring in the PID cog, but are occurring in the main cog.

Post Edited (Todd Chapman) : 6/22/2010 6:10:02 PM GMT

sssidney

When i'm trying to figure stuff like this out I like to use MultiCogSerialDebug object to print debug messages from the cogs. It tells you what cog the debug print came from.

[noparse][[/noparse]COG0]: routinex setting value y to 1
[noparse][[/noparse]COG1]: clearing value y
...

MagIO2

With a COGNEW you really only start the function you mention there. If it's an endless loop which does not call other functions then no other functions are involved from that COGs point of view.
If you call other functions from your main COG, then these functions are really running in the main COG.

It makes no difference if we talk about functions in the same *.spin-file or in an object.

Both things (the looping COG and the function call in the main COG) happen independent from each other. So, depending on the problem you wanna solve with the program, there might be a need to synchronize. For example if you reset the PID you better might want to wait with setting the input values of the loop until a calculation is done. Because otherwise it can happen that old and new values are mixed as a cause of this independency. This can lead to wrong results.

T Chap

Ok that makes sense. That is the obvious answer. That means that I can modify counter parameters in the same way in other cogs. I need to set and forget more counters than just the main a/b. So, the idea is to park a method in some other cogs where the method would modify the counter, such that a call to that method(other cog than main) will access that cogs counters. Hopefully this will work. The idea being that I do not want to disturb the other cogs current activities just to make the counter changes.

MagIO2

Do you talk about the hardware counters or counter variables in the objects? Because counters are private for each COG. No other COG can setup/change hardware counters of other COGs. Variables can be changed by object functions even if the object functions run in different COGs because these are located in HUB-RAM.

Sal Ammoniac

The main way programs running on separate cogs communicate with each other is through variables in hub RAM. These variables can either be set up when a new cog is started, so that the program running in the new cog just modifies variables that other cogs can see, or you can call methods in objects that can then return or set values used by the other cogs.

ericball

Each cog is a separate CPU executing instructions out of local RAM. For SPIN, the local RAM contains the SPIN interpreter while the SPIN bytecode is stored in shared HUB RAM. Each SPIN "thread" has local variables (stored in the HUB RAM passed with COGNEW) and can access the global object variables (or any global variable in any object for which it has the address). The writable COG registers (e.g. CTRA) may be considered a special kind of local variables.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum