With some external hardware, you could probably do this, although I'm not sure I see what benefit accrues from it. Basically, it would involve an external clock that feeds both Props: a master and a slave. The clock to the slave Prop would be gated by the master Prop in such a way that the master could block single clock pulses to the slave. This might be as simple as using and AND or OR gate, depending on the timing relationship, so as to avoid runts. It will also preclude using the PLL to boost the system clock rate, since then you wouldn't have any control over individual system clock pulses.
Next, both master and slave will need an assembly program in cog 0 (or any other known cog, so long as they're both the same) to do a RDLONG, then output a pulse. The master would then compare its pulse to that from the slave, and drop clocks to the slave until they line up. From that point onwards the hubs should be synchronized.
But, again, I think it should be possible to gang multiple Props to do useful work, without bothering to synchronize their hubs.
You can certainly use multiple props together without synchronizing their hubs. The same way you need to partition the work between the 8 cogs within 1 prop, you need to partition the work between all the cogs in however many cogs across all the props you need.
I would assume that some of the cogs on different props will need to communicate but you should partition the work to keep as much of the communication within a prop. Within 1 prop you can go through hub memory across props you need to come up with a scheme. serial ports being the more obvious simple one. There are other schemes that work as well. The approach I am using is to use 1 serial port (2 pins) on each prop, the tx on 1 prop goes to the next prop, the tx on that prop goes to the next, etc in a ring. This limits the number of pins I use for communicate at the expensive of needing to forward data from prop to prop.
I just wanted to synch the hub access windows so that a cog from each chip could access the shared memory during the same window of time.
I finally did synch the windows by letting a master restart the slave until they synch'd up at random. I still haven't tested whether they will stay synch'd when·I execute CLKFREQ, CLKMODE or any other function.
I want to minimize the latency of IPC (or in this case IchipC) introduced when I cluster the processors (chips)·with no network backbone.
I think I am missing something. Are you saying you have some shared memory between props, or are you trying to sync 2 props, so you can do a read from hub and an out on 1 prop and a in, write to hub on the other prop, with the hub accesses sync for minimum delay? My comment on the 2nd is that I dont think you can do a read/out/inc/loop fast enough to stay in step with the hub (though the reverse loops from the lmm work may manage that). And you may do better to batch the ipc. i.e. loop read from hub into cog memory. Then out loop from cog memory to out pin, and hte reverse on the other cog. This you should be able to do and stay in step with the hub on each prop during the hub read/write loops and this doesn't need the 2 hubs synchronized.
You can synchronise the hub access·as follows...· It will not be easy, but IS possible in PASM.
I have code that will sample pins on each clock, so that makes 4 cogs operating on each successive clock. So it is only a matter of then synchronising the hub access.
1. You will need a common clock (crystal oscillator) between both/all propeller chips.
2. You will need at least 1 common pin between the propellers.
3. You will then have to start all 8 cogs on each propeller.
4. Have all cogs (except cog 0 on the master) execute a waitpeq (waiting for "the" pin high)
5. After a delay (to ensure all slave cogs are at waitpeq) have cog 0 on the master set "the" pin high.
6. The instruction after the waitpeq must be a mov c1,cnt (to save the current system counter)
7. Execute the a·rdlong x,par (anywhere, this is just to get the hub access reference)
8. Execute a mov c2,cnt (get the current system counter)
9. Execute a sub c2,c1 to get the elapsed clock count for hub access
9. Now in all cogs (except cog 0) you will have a reference to use to synchronise the hub accesses. I'll leave that to you.
I've been thinking - the one gotcha is you could have the hubs one clock out of phase
Obviously from my previous post you could reassign the cogs, but the clock phasing between the hubs is a problem. This is because the hubs require·2 clocks per execution (16 per reound robbin).
You could overcome this in hardware by a simple gate and a pin. Us this to block one clock if they are out of phase. Or actually skipping enough clocks to put the cogs (0 to 0, etc) into phase by skipping 0-15 clocks. If you do this, don't skip successive clocks as I am not sure what the propeller will do.
kdoney
Posts: 3
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Next, both master and slave will need an assembly program in cog 0 (or any other known cog, so long as they're both the same) to do a RDLONG, then output a pulse. The master would then compare its pulse to that from the slave, and drop clocks to the slave until they line up. From that point onwards the hubs should be synchronized.
But, again, I think it should be possible to gang multiple Props to do useful work, without bothering to synchronize their hubs.
-Phil
I would assume that some of the cogs on different props will need to communicate but you should partition the work to keep as much of the communication within a prop. Within 1 prop you can go through hub memory across props you need to come up with a scheme. serial ports being the more obvious simple one. There are other schemes that work as well. The approach I am using is to use 1 serial port (2 pins) on each prop, the tx on 1 prop goes to the next prop, the tx on that prop goes to the next, etc in a ring. This limits the number of pins I use for communicate at the expensive of needing to forward data from prop to prop.
I just wanted to synch the hub access windows so that a cog from each chip could access the shared memory during the same window of time.
I finally did synch the windows by letting a master restart the slave until they synch'd up at random. I still haven't tested whether they will stay synch'd when·I execute CLKFREQ, CLKMODE or any other function.
I want to minimize the latency of IPC (or in this case IchipC) introduced when I cluster the processors (chips)·with no network backbone.
I have code that will sample pins on each clock, so that makes 4 cogs operating on each successive clock. So it is only a matter of then synchronising the hub access.
1. You will need a common clock (crystal oscillator) between both/all propeller chips.
2. You will need at least 1 common pin between the propellers.
3. You will then have to start all 8 cogs on each propeller.
4. Have all cogs (except cog 0 on the master) execute a waitpeq (waiting for "the" pin high)
5. After a delay (to ensure all slave cogs are at waitpeq) have cog 0 on the master set "the" pin high.
6. The instruction after the waitpeq must be a mov c1,cnt (to save the current system counter)
7. Execute the a·rdlong x,par (anywhere, this is just to get the hub access reference)
8. Execute a mov c2,cnt (get the current system counter)
9. Execute a sub c2,c1 to get the elapsed clock count for hub access
9. Now in all cogs (except cog 0) you will have a reference to use to synchronise the hub accesses. I'll leave that to you.
Hope this helps
Obviously from my previous post you could reassign the cogs, but the clock phasing between the hubs is a problem. This is because the hubs require·2 clocks per execution (16 per reound robbin).
You could overcome this in hardware by a simple gate and a pin. Us this to block one clock if they are out of phase. Or actually skipping enough clocks to put the cogs (0 to 0, etc) into phase by skipping 0-15 clocks. If you do this, don't skip successive clocks as I am not sure what the propeller will do.