Save me from my Arduino's!! Inter Cog Comms....

Hi, this is my first post, so hi everyone...

I'm finally getting my MSR1 Propeller board up and running, but I could do with some help please...

I have 6 roles, or jobs, requiring 6 chunks of code. These 6 are to be under the control of 1 master piece of code. This Master will send each of the six a single byte, which will be used to tell the 6 slaves what job they are to do. The master will then send each one a 'Go' to tell them exactly when to begin. When each one has finished, it will store a 'Finished' flag, and a few bytes of results info (always the same number of bytes), so the master can see if they've finished or not, and if they have, it can look at the results.

I can do this with a pile of Arduino's, and i2C, but I'd really like to use the Propeller and Spin.

I've read, searched, and gone in circles, looking at communication between Cogs, and my problem is, it's too flexible! There are so many ways to do this, each with its own if's and but's, I just get lost. I've met business software like this before, so many options and settings it disappears like the Oozlum Bird...

Please can anyone give me some recommendations?

Thanks

Phil
Chesterfield U.K.

Comments

  • Here's what I'd do in PASM

    Setup a small control block for each one in VAR or DAT sections, with a go flag as the first byte.

    cognew each slave cog passing its own control block address - the slaves may or may not be the same
    code, its up to you.

    Set the flag to a non-zero command byte to start a particular cog, check for it becoming zero again
    (helper cog sets to zero once its written its results and finished).

    So basically you use the atomic nature of rdbyte/wrbyte as synchronization, no other locking needed

    You can be a little smarter and use the cogid as an index into the control block, then it can be shared with
    all slaves.

    If the slave cogs are Spin, you need to pass the control block address as an argument and use byte[cb]
    to index into it, I think, someone will correct me if I've got that wrong, I normally use spin to setup and
    control PASM cogs.
  • JonnyMacJonnyMac Posts: 6,153
    edited 2019-02-12 - 21:51:37
    If the slave cogs are Spin, you need to pass the control block address as an argument and use byte[cb]
    to index into it, I think, someone will correct me if I've got that wrong, I normally use spin to setup and
    control PASM cogs.

    It's easier than that. If the slave cog code is in Spin, those cogs can directly access [project] global variables. One of those variables can be a command flag that tells which slave to operate and when. Each slave should probably set an "I'm finished" flag so that the master cog doesn't try to hand off control too quickly, In fact, you could use a variable called slaveid that goes from 1 to 6 when a slave is activated; when the slave sets this variable back to 0 the main cog knows that slave is finished.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Phil,
    I think JonnyMac has nailed it, as usual!
    Your program spec seems quite small and tight, so 6 cogs launched within the same main program all with global variables seems a good way to go.
    Look at Scanlan examples 05, 06, 17 for some code and explanation. Scanlan gives some warnings about this approach.
  • jmgjmg Posts: 13,059
    philjjz wrote: »
    .. The master will then send each one a 'Go' to tell them exactly when to begin.

    How exact does that begin need to be ?
    Data passing via bytes HUB is the simplest way to arm, and report, but if you want the best precision on the actual 'exact begin', using a pin as a signal gives the most exact control.
    COGs can only poll HUB bytes in a loop, and that is slow and varies for each COG's access slot, but all COGs can WAITxx on a common pin change, and thus start on the same SysCLK (typ 12.5ns)

  • or you can poll a hub long for a waitcnt value (zero meaning not set yet), and then waitcnt on that value, no pin needed.
    All the master has to do is choose a non zero waitcnt time in the near future.
  • Thanks Guys,

    Some good guidance for me there, but not too many different ones! The 'Start time' isn't too critical from a code point of view, more from a human perception one, so a few milliseconds won't matter. If I'd been using I2c there would have probably been a bigger delay. I'll post a bit more when I've made some progress.

    Your help is much appreciated!

    Phil J.
Sign In or Register to comment.