Shop OBEX P1 Docs P2 Docs Learn Events
cog-to-cog communication — Parallax Forums

cog-to-cog communication

omgitsaliv55omgitsaliv55 Posts: 24
edited 2008-05-06 10:56 in Propeller 1
I'm planning on building a complex robot with many servos and don't wont to have to use a separate servo controller (for the sake of simplicity), so I figured I would write my own servo controller that would run on another cog, and the main cog would send data to the other cog. but I don't see anything in the propeller manual about "talking" cogs. I know there's an object that demo's this, but I've been kind of busy lately and don't have much time to go through and dissect the code. what I would really like to know is if this is even possible. Ideally, I'd like to just be able to tap into the other cog's ram, but if I have to I guess I could use serial commands.

thanks

-Patrick

Comments

  • Stan671Stan671 Posts: 103
    edited 2008-04-28 03:03
    Patrick, you really need to study the block diagram and the docs for the Propeller. All of the cogs share the main RAM memory in the hub. Any cog can see any memory location anywhere in RAM. So, to pass information from one cog to another, just store it someplace where the other cog will read it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Stan Dobrowski
  • omgitsaliv55omgitsaliv55 Posts: 24
    edited 2008-04-28 03:30
    so when I declare a variable in my program, every cog has direct access to it? I'm really sorry I'm so slow at this. my education kit hasn't come yet and I'm still acclimating to the idea of multiple core arcitecture.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-04-28 03:55
    omgitsaliv55,
    There are two completely independent ways of organizing your programs: 1) You can separate your program into objects which have their own private name spaces and the variables in one object cannot be directly accessed by another object. This is used primarily for creating abstractions, usually for device I/O drivers. 2) You can run bits of your program in separate processors (cogs) simultaneously. The smallest "bit" is a procedure or function which is called a "method" in Spin.

    If you have two or more cogs running and their code is all in one object, they both have complete access to global variables in the object.

    There already exist two objects in the Parallax Object Exchange for controlling servos. One is written partly in Spin and partly in assembly and can control up to 32 servos. The other is written completely in Spin and can control up to 4 servos and has additional provisions for ramping position. In both cases, the part that actually controls the servos executes in its own cog. The other part is the set of interface routines that one actually calls from ones program.
  • Ken PetersonKen Peterson Posts: 806
    edited 2008-04-28 13:22
    Mike mentioned that two or more cogs running code that is in the same object have access to the same variables. This is only if they are SPIN. If you are running PASM in a cog, you need to provide pointers to the variables because PASM cannot access variables in the VAR section by name. I have found the easiest way to do this is to use an INIT routine to assign pointers in the DAT section to point to the variables in the VAR section before launching the cog with the PASM code. Then the pointers get copied along with the PASM code to the cog and the variables can be accessed using RDBYTE, WRBYTE, etc.

    VAR
      long  long_var
      byte  byte_var
    
    PUB Init
      long_ptr := @long_var
      byte_ptr := @byte_var
      cognew(pasm_start, 0)
    
    DAT
      org 0
      pasm_start
             '  PASM code
             RDBYTE temp, byte_ptr   ' example access to byte_var variable
             WRLONG temp2, long_ptr  ' example access to long_var variable
             ' more PASM code
    
    byte_ptr  long  0    '  note both are long because they are pointers
    long_ptr  long  0
    temp      byte 0
    temp2    long  0
    
    

    If you only need access to one variable, you can pass the pointer to it in the cognew statement:·cognew(pasm_start, @long_var)
    and access it using the PAR reserved variable in PASM:· RDLONG temp2, PAR


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Post Edited (Ken Peterson) : 4/28/2008 1:30:07 PM GMT
  • DizzyDizzy Posts: 9
    edited 2008-05-06 02:41
    Okay so if I start a new cog in spin to a methodin that object that cog running that method has access to any variables I declare under VAR in the object. BUT! Does it have acess to the other methods in the object?

    I guess the root of my question: What all is restricted from a new cog when its created?

    Right now I have a problem where I have code that runs fine when just called from the main obect. But when I cognew on the function to seperate it... nothing happens or the prop locks up like:

    PUB insideMain
    secondObject.someMethodInObject2()

    But when inside the secondobject I do

    long stack[noparse][[/noparse]32]

    PUB insideSecondObject
    okay := cog := cognew(someMethodInObject2,@stack)

    PUB someMethodInObject2
    nothing runs in here or it freezes up

    Post Edited (Dizzy) : 5/6/2008 3:14:43 AM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2008-05-06 03:12
    Yes, if you start a method in its own cog, that method has full access to all the constants, variables, and other methods in that object. It can also call public methods and constants in any object declared in the object containing the method. That said, if two cogs access the same variables at the same time, strange and unpleasant things can happen if that access is not controlled by use of a lock (semaphore) or careful design for multiprocessing.
  • DizzyDizzy Posts: 9
    edited 2008-05-06 03:27
    Wow, thanks again for your reply Mike and... what like 15 minutes afterward at 10:30 on a Monday haha. You've been a great help to me as I fumble through this.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-05-06 03:45
    You've only given a fragment of a possible program. There's nothing in that fragment that would explain what you're describing. Details matter, particularly when you're trying to use two processors (cogs) to run the same program.
  • DizzyDizzy Posts: 9
    edited 2008-05-06 04:22
    I think you think I'm being sarcastic. Seriously, thanks a lot. I've been writing a project in SPIN for about a year now and we initially were looking at taking your OS and modifying and playing with it then and you were helpful even at the start. Our senior design project involves building a gaming console from scratch using the propeller. Check it out r8e8r.info
  • ErNaErNa Posts: 1,751
    edited 2008-05-06 10:56
    Take a second look ;->
Sign In or Register to comment.