cognew and cogstop question

karli

··· In my Object I'm using three· cognew 's.
·· the first one is: cognew(blink, @stack[noparse][[/noparse]0]); it runs all the time as soon as I boot up;
·· the 2nd-one is: cognew(gate, @stack[noparse][[/noparse]10]); it's used whenever I need to input something;
·· the 3rd-one is: cognew(correction, @stack[noparse][[/noparse]20]); it is CALLed to fix some error condition;
·· on the 3rd-one I need to run a cogstop(3) to keep it from interfering with other
·· CALLs before· entering/or restarting·the·correction, @stack[noparse][[/noparse]20]) again.
·· Is it true that the cogstop(1) refers to the stack at [noparse][[/noparse]0]. cogstop(2)..to the stack at [noparse][[/noparse]10]
·· and cogstop(3)..to the stack at [noparse][[/noparse]20] ?
· or does the cogstop(1,2,3)· scheme depend on the order in which those cogs are being CALLed
· at the time when a cogstop is executed ?
· just need some clarification on this,
·thanks,
· karli
·

Mike Green

1) You may need more than 10 levels for these cogs. I suggest a minimum of 20. It's clearer
if you use different array names for the different stack areas. You're not required to do this,
but I recommend the practice. Maybe you'd have
"long blinkID, blinkStack[noparse][[/noparse] 20 ], gateID, gateStack[noparse][[/noparse] 20 ], correctionID, correctionStack[noparse][[/noparse] 20 ]",
Then you'd call "blinkID := COGNEW(blink,@blinkStack)" and so forth.


2) When you call COGNEW, the function returns the number of the cog actually used (0 to 7).
This is what you need to use for COGSTOP. The only way to get this number is to save the value
returned from COGNEW or to have the cog itself use COGID which returns the number of the cog
executing the COGID function.

karli

Thanks Mike, for the speedy comeback; every-so-often I get quirky results when I think that my
cogstop (I call 3) stopped something but apparently it didn't.
I'll use your advice and go by COGID.
karli // (karl_i)

karli

MIke,

'still burning the midnight oil on this one; In your reply, 2nd paragraph 2) I'm still stumped by the verbage:
"the cognew's function returns the number of the cog actually used (0-7)"
am not sure how this "returning works"

Here is what I want to do:
The correction routine I referred to in my Post, I call StallFix. In my Object I start a motion routine
and at the end I make a CALL to Stallfix to watch over that motion rtn and fix it if it goes wrong.
StallFix needs to run in a 'fesh' cognew and I want to tag or ID that cog so that I can do a cogstop
in 2 other routines if I have to.
this is what I've got:
cog := cognew(StallFix(3), @stack[noparse][[/noparse]3 * 20])
In the motion routine where I want to run StallFix. I just want to say: run cog

then, if I need to stop StallFix in the other 2 routines, I want to say: cogstop(cog)

how do I assign cog as a global label so that all my PUB XXX methods know what I want to do ?

thanks a bunch,
karli (karl_isbrecht)

Mike Green

Please re-read the description of COGNEW in the Propeller Manual and re-read my previous post.

1) COGNEW initiates a new cog with the subroutine call you specify and using the stack space you provide. It takes a little over 100us to do so, but the COGNEW returns well before that. Like all Spin subroutine calls, COGNEW has a return value which, in this case, is the number of the cog that was used or -1 if no cogs were available.

2) If you save this value as shown in my previous posting, you can use that number to stop the cog that was started (like "COGSTOP(blinkID)").

hippy

how do I assign cog as a global label so that all my PUB XXX methods know what I want to do ?

Put your 'cog' variable in the VAR section ...

VAR
  long cog

PUB StartTheCog
  cog := cognew(StallFix(3), @stack[noparse][[/noparse]3 * 20])

PUB StopTheCog
  cogstop(cog)

karli

Mike and "hippy", thanks for your help !
I got my CALL to StallFix to work. When I manually force a stall condition I can see that StallFix
responds and my machine resumes normally.
But I ahd to get rid of those (3)'s in the line below, before I could detect a StallFix response.
cog := cognew(StallFix(3), @stack[noparse][[/noparse]3 * 20])
I was coaxed into those (3)'s for two reasons:
a) on page 11 of the Methods and Cogs Manual they talk about Index which I don't need in my case;
b) I was under the impression that "I" can control which cog I want a routine to run in. so I picked
3 because that was my 3rd new, cognew I needed. Apparently that is not the case. I can not choose
the cog beforehand; it is a random, round-robbin pick by the Prop architecture, correct ?
so, after my StallFix gets launched in a new cog, it could run in any of them from 0--7.
that much I can follow,
what I'm "still" not sure about is the /// return path/// where the cog number or -1 gets reported or what
register it gets logged in. So where can I "see" that mysterious ID of the cog my StallFix
got launched into ?

When I do the coding that "hippy" suggested, setting a long cog in VAR
and then using two PUBs, one for starting my StallFix and one for stopping it, the cognew ID path
is in there 'somewhere'. but can I ever track down what that cogID was or, it seems' it wouldn't really
matter if the next time I call StallFix it would be a different ID anyway, because of the
round -robbin assignment scheme ?

At the bottom of the Prop manual on page 189, it uses the same language we covered here but it doesn't
"nail down' my question I stated above.
If could could comment on that, I'd appreciate it,
karli

Mike Green

Please look again at what hippy posted. Do you understand what "cog := cognew(StallFix(3),@stack[noparse][[/noparse] 3 * 20 ])" does?
Do you understand what a function is? All subroutine calls in Spin are function calls. They all return some kind of value.
Like in C, you can choose to ignore that value. If the subroutine doesn't provide a value, it is zero by default. In the
statement I wrote above, the global variable "cog" is set to the value returned by cognew as it sets up a new cog to run.
As the manual says, this value is -1 if there are no cogs available, otherwise it's the ID (a number from 0 to 7) of the cog used to
execute the call to "StallFix(3)". If you use hippy's code, this ID is stored in the variable "cog" and can be referenced later to stop
the new cog.

karli

Thanks Mike, for not hanging up on us newcomers too soon.
I have 'conjured' up a mental image of what cog := cognew(.......[noparse][[/noparse]..]) above, does to help me
over my current hurdles with Spin. If I had to write out
the answer in an essay style test then I'd probably fail miserably.
A function is a relationship between values and events...how close is that ?
I'd "really" like to grasp what signals are exchanged on the Prop bus to fulfill the various
code conditions but that may have to wait awhile.
much obliged for your help,
karli

Mike Green

A function (from a programming perspective ... not the mathematical definition) is a subroutine that, in addition to doing "something", returns a value. A procedure (from a programming perspective) is a subroutine that does something. There's no discussion about returning a value. In a programming language like Spin, things generally have values. Variables have values. Expressions have values. Even assignment statements have values (the value of the variable on the left side after the assignment is done). Values are used to compute other values. Values are passed as arguments to subroutine calls. Values are used as part of most statements (like REPEAT <variable> FROM <expression> TO <expression>). Here I'm using the term "expression" the same as "value".

"cog := cognew(..., ...)" is compiled into code that performs the subroutine call used as the 1st parameter, calculates the value given in the 2nd parameter, then a "cognew" interpretive code causes the interpreter to set up the information needed for a COGNEW instruction (which is a bit too complex to go into here - read the Propeller Manual description for a start), then execute a COGNEW and push the result left in a cog memory location into the original cog's stack. The "cog :=" causes that value from the stack to be stored in the hub variable "cog".

By the way, there is no such thing as a "Prop bus". There are internal signal paths on the chip, but they're really a "black box" as far as you're concerned. They have no existence outside the chip package and they're not directly reflected in the instructions. There is one diagram of the I/O pin connections and how they're propagated from one cog to another, but this is an abstraction used to show how there are delays that vary across the chip depending on which cog is being used to access the given I/O pin. The actual structure on the chip may be a bit different.

Post Edited (Mike Green) : 7/29/2008 3:12:49 AM GMT

hippy

Procedures can be thought of in a real world analogy such as an order to a secretary to "Mail This"; whatever it is gets handed over and mailed, you don't worry any more about it. For a Function, that's a 'do something and get a result back', such as "Order This"; what you want gets ordered and what you get back is an order number. You'll need to store that order number if you want to cancel it later.

In terms of "cog := CogNew(...)", you instruct the Propeller to launch a new Cog and it returns which Cog was used. You remember the Cog number so you can issue a CogStop(cog) later to stop that Cog running if you need to.

If you issue two "cog := CogNew(...)" satements you overwrite the Cog number so you don't have the reference to the first Cog used any more.

karli

Tue=29Jul08; 09:20MST
MIke and hippy,
Only 4 months ago, after completing the logic(=electronic circuitry) and stuffing 24 ICs on circuit boards
to breathe some life into my Mag Pulse Turbine (MPT)...and...after seeing the Parallax Ad in Nuts&Volts, I decided
to take the plunge and get a Prop Ed Lab kit to let SPIN take over.
As of yesterday, with the help of both of you as well as "other valued forum members!" I can now run
my MPT under SPIN control. I never thought that there could be such dedicated and responsive forum club
members like you.
The magic that resides inside that 10mm^2 chip on my Prop Stick USB is phenomenal but of course
one has to talk to that little 'black chip' in just the right way or it'll ignore you.
I'm sure that if I could spend several hours per day with you in "Spin Class" my little "black chip' would 'sing'
like the 'three sopranos'.
It might also be helpful for beginners if an addendum to the Prop Manual
were around to explain concepts such as procedure and function in a more down-to-earth
style, as you have done.
My heartfelt thanks goes out to both of you for your support !
karli (karl isbrecht)

Mike Green

Karl,
The Prop Manual is really not intended to be an introduction to basic programming concepts. That will come later from other authors as various people complete their books on the subject using Spin as the language. Remember that the Propeller is fairly new as these things go and it takes several years for the mass of specific educational material to accumulate. The Propeller Education Kit tutorials that can be downloaded from Parallax is a start although they focus more on the hardware.