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

philjjz

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.

Mark_T

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.

JonnyMac

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.

macrobeak

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.

jmg

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)

Mark_T

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.

philjjz

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.