Cognew Question:

T Chap

I stole some lines from an example:


"CogNew(BlinkingLED_A17 (WaitPeriod_Arg), @Stack1)"

In the line above:

1. a new cog is started
2. method is called
3. a variable has been entered as a parameter, and named the same name( to pass on a value previously given to the variable)
4. a stack area is assigned to the new cog

"PRI BlinkingLED_A16 (WaitPeriod_Par) | Pin "

1. In this line the method is named obviously, but then it has a different name for PAR
2. A local variable is declared


"WaitCnt(WaitPeriod_Par + Cnt) "
1. the value declared in the first cog is now used to set a delay


In the Method that is called, where it is declaring its parameter name in () i.e. BlinkingLED_A16 (WaitPeriod_Par),
does whatever name is declared in the () get assigned the value that was in the first calling method, regardless of the names?

Part 2

In the manual on P 4-38, a method is declared as MAIN with a local variable X. X is made = 2. A new cog is created, the Square method is called with (@x) parameter. Why didn't they just say X? What would be a case where you would use the addres of X and not X itself?

The same questions applies to this example as well, is (@X) automatically written to the (XAddr) parameter regardless of it name? It appears to be the case although I have not seen it clearly stated as so. What if multiple parameters were listed, comma delimted?

Thanks

T Chap

Sorry, I left out something regarding cognew.

1. Can you call a new cog from anywhere in the main program, for example:

PUB main
repeat
somemethod1
somemethod2
somemethod3

PUB somemethod1
if ina[noparse][[/noparse]but1]
cognew(somemethod4, @stack1)

PUB somemethod2
if ina[noparse][[/noparse]but2]
cognew(somemethod5, @stack2)

PUB somemethod4 'make motor go to position 10,000 steps, direction ccw, speed x, accel x, decel x
<code for moving to destination 1>

PUB somemethod5 " 'make motor go to position 0 steps, direction cw, speed x, accel x, decel x
<code for moving to destination 0>

2. If somemethod4 is moving the motor to its destination, how does a TRUE in PUB somemethod2 communicate with the same cog (en route) to cause it to cease(decel actually), and go to the new destination. Would not the same cog have to be instructed by some ID proccess to tell it to stop?

Does this make sense as an option:

1. cognew is called
2. the new cog is sending the motor somewhere
3. the cog in motion has not returned a required result yet (at end of motion, it returns done)
4. the main program upon receiving a true conditon for a new position move, first checks for a result from the current motion, if false, it issues a stop to that cog(by id?), then issues the newcog.

The point being that there will be a lot of pulses to be sent that need no interruption, so a standalone cog is required just for pulses out. The other option is to have the encoder count variable checked at any new button press, and a cog stop issued at that point, followed by newcog.

Mike Green

1) Your general idea is fine (start cogs where needed to accomplish tasks independently). You can start a cog from anywhere in your program.
2) Unless a cog is going to run until it is done then quit, you'll have to communicate somehow between cogs. The usual way of doing this is through some common memory location. Typically, when a cog is started, the starting routine initializes this variable. You can see this in the library objects where there's a "start" method like:

VAR
  long doIt, doneIt

PUB startSomething(anyParameters)
  doIt := doneIt := false
  cognew(theActualTask(anyParameters),@myStack)

PUB stopSomething
  doIt := true
  repeat until doneIt

PRI theActualTask(anyParameters)
  repeat
    if doIt == true
      doneIt := true
      cogstop(cogid)

If some thread calls startSomething, the new cog begins working and does whatever it's supposed to do. If any cog calls stopSomething, it tells theActualTask to stop working. When theActualTask actually gets a chance to check and finishes stopping (maybe it has to leave the motor in a
stable state before quitting), it signals that it's actually done, then stops itself. The signals back and forth between the two "execution threads"
here are just true and false, but more complex information can be passed. A command could be passed in "doIt" with zero being the command
to stop. Status could be passed back in "doneIt" where zero indicates "working" and some other value indicates an error status or completion
status.

Mike Green

To answer your other questions:
1) If you have:

PUB Main
  doSomething(23,55)

PRI doSomething(x,y)

When doSomething is called from Main, there are local variables x and y created and the assignments "x:=23" and "y:=55" are done in the
process of actually executing doSomething (in what's called a preamble). Note that the parameter values are computed before actually calling
doSomething, so there's no relationship between names used in the caller (Main) and names used in the callee (doSomething).

2) @x is used when you want to pass the address of x rather than the value of x. This is mostly used when you want the called routine to
store some value in x or if x is an array that the called routine will access. So you may have:

VAR
  long x[noparse][[/noparse]10], y, z

PUB Main
  doIt(@x,@y,z)

PRI doIt(addrX,addrY,valueZ) | a,i
  i := 5
  a := long[noparse][[/noparse]addrX][i]  ' This sets a to the value of x[i]
  long[noparse][[/noparse]addrY] := a ' This sets y to the value of a
  long[noparse][[/noparse]addrX] := valueZ  ' This sets x to z
[/i][/i]