I'm still confused about object vs cog

henkvbeek

I'm still confused about obects and cogs.

Suppose, I have a SPIN-object, a full duplex serial interface.
I would like this object to run in one separate cog, totally undependent of my main program.

It should be nice to put this into one , I mean really one, object.
All public methods, config, tx, rx, rxcheck and str, should be accessable even by the main program and by all other objects.
These other objects are running or in the same cog as the main-program or in other cogs.

I can't find how I declare this.

I may start a new cog with an argument of a SPIN-method, not with an argument of the whole object.

Please, enlight me

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What God wants, God gets . . .

Oliver H. Bailey

That isn't a problem. Take a look at the FullDuplex.spin object. Consider an object a program running within a COG. So you could fire off two FullDuplex objects using different pins and managed by a 3rd object that parses the input from one object and converts it for ourput through the other object. If you want to contain a program (or object) to a given cog, you can do that via thw way the object is written. It sounds like the nomanclature is getting you confused. If you've written in C or assembler before an object could be either a stand alone program if it's the only COG or a sub-routine if there are multiple COGS. You could write an object to continiously monitor inputs and store values to shared memory using another object to set outputs based on the memory variables. In short the two objects never have to have direct communications so they could be completely independent.

Oliver

henkvbeek

I Would like to create a program as follows:

VAR
BYTE  Rcv

PUB Main
  Uart.start(-1, 0, 19_200)
  WaitCnt(50_000_000 + Cnt)
  Uart.str(string("Uart started . . .",13,10))

  repeat
    Rcv := Uart.rxCheck
    if Rcv <> -1
      Uart.tx(Rcv)
    else
      Uart.tx(".")
    WaitCnt(5_000_000 + Cnt)
    until (Rcv == Escape)

  Uart.str(string("Uart will stop . . .",13,10))
  WaitCnt(50_000_000 + Cnt)
  Uart.stop
    

I would like the methods of object Fullduplex start, str, rxCheck, rx, tx and stop all running in one separate Cog.

How will I implement this ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What God wants, God gets . . .

Mike Green

A COG really doesn't run a method so much as an execution thread. In other words, "cognew" or "coginit" start a new Spin interpreter running with its own Spin stack to use for local variables. This interpreter gets its interpretive code bytes from Hub memory. If you do two "cognew" starting with the same Spin method, maybe with different parameters, but each with its own separate stack, they run simultaneously and independently (unless they both try to use the same I/O pins or global variables). In the example you gave, Main runs as one thread and any of the calls it makes to Uart run in the same thread (COG in this case). The call to Uart.start happens to start another COG with a second thread. This can be in assembly or Spin. The two threads communicate via shared memory. The call to Uart.tx (which is running on the first cog) probably puts the character into a buffer in the Fullduplex object and the second thread (either in Spin or assembly) takes characters out of the buffer and transmits them. Uart.start may also start a third thread to listen for received characters although, in assembly, it's not hard to combine both a receive and a transmit routine in the same COG. If this third thread sees an input character, it puts it in another buffer in shared memory in the Fullduplex object. Main is still running in the first COG and calls Uart.rxCheck to look in the receive buffer and return true if there's something there.

With the Fullduplex object, you're already doing the bulk of the work in a cog started by Uart.start. The Uart routines that you see (rxCheck, rx, tx, stop, str) are just interfaces to this separate cog. They're fast and short and should run in your main cog although they could be called from some other cog should your application need that (like for debugging a separate cog that interfaces to the PING sensor).