Basically you read the cnt register, add a constant to it (to give the other cogs time to start up), then write the value into a hub variable.
The cogs to be sync'd read the value and do a WAITCNT for that value.
I think cogs take several milliseconds to start up, so you need to add a large enough constant so CNT is not already past the stored value when the other cogs read it.
Thanks for the reply....I am using pasm...I am looking for a very deterministic timing
thinking though this...I have a few concerns/questions...Once the cogs are in-sync...any read to the hub will cause them to become out of sync...right? Here is my thinking
As an example lets say I want two cogs the be in-sync and read and output data at the same time by running the same program on the two separate cogs...because only one cogs gets access to the hub at a time..each read would cause them to become out of sync...Now lets say I am using cogs 2 and 3 (or any two cogs next to each other) I could calculate the time difference as long as the cogs access to the hub starts with any cog except cog three....because a start at cog three would cause cog two's access to wait until cogs 4,5,6,7,0, and 1 have access. Any other start (hub access) cog (except 3) would cause access for cog two to come before cog three..making the timing deterministic. How could I avoid this?...Or am I missing something...it seems that there is a system clock (cnt) and a hub access clock...and can you calculate the hub access clock? That way...you would know at each cnt time what cog has access to the hub
...it seems that there is a system clock (cnt) and a hub access clock...and can you calculate the hub access clock? That way...you would know at each cnt time what cog has access to the hub
Still not quite sure what you're after here. Anyway, cnt is never reset as such (like video frame counters and counter flip-flops), i.e. there is no fixed relationship between cnt and hub access. But it may help to know that the first instruction executed by a cog is -4 clocks relative to its hub window slot. So you'd have to run this test once and then you know where and when stuff happens.
mov cnt, cnt ' first cog insn
wrlong cnt, par ' broadcast timing (no penalty for this hubop)
I posted a project a few years ago where I sync'ed 4 cogs to be precisely 1 clock apart. Each cog read all ports so that I could actually have all ports being sampled 1 clock apart.
IIRC it was called something like DataLogger and perhaps I posted it in Obex.
It's no longer on my dev pc but I would have it archived somewhere.
Anyway, what I did was have all 1 cog get waitcnt and put it in hub. Then all other cogs grabed this and added a fixed amount (to cover the delay in getting it into a waitcnt value). Each of the cogs then added 0/1/2/3 to that value too, and then performed a waitcnt on the new value. They were then precisely 1 clock apart.
Hope this helps.
dr hydra
Posts: 212
Comments
The cogs to be sync'd read the value and do a WAITCNT for that value.
I think cogs take several milliseconds to start up, so you need to add a large enough constant so CNT is not already past the stored value when the other cogs read it.
Bean
P.S. Are you using spin or pasm ?
This could be solution for Your problem: http://wardyprojects.blogspot.com/2013/01/propeller-synchronising-two-or-more-cogs.html
thinking though this...I have a few concerns/questions...Once the cogs are in-sync...any read to the hub will cause them to become out of sync...right? Here is my thinking
As an example lets say I want two cogs the be in-sync and read and output data at the same time by running the same program on the two separate cogs...because only one cogs gets access to the hub at a time..each read would cause them to become out of sync...Now lets say I am using cogs 2 and 3 (or any two cogs next to each other) I could calculate the time difference as long as the cogs access to the hub starts with any cog except cog three....because a start at cog three would cause cog two's access to wait until cogs 4,5,6,7,0, and 1 have access. Any other start (hub access) cog (except 3) would cause access for cog two to come before cog three..making the timing deterministic. How could I avoid this?...Or am I missing something...it seems that there is a system clock (cnt) and a hub access clock...and can you calculate the hub access clock? That way...you would know at each cnt time what cog has access to the hub
mov cnt, cnt ' first cog insn wrlong cnt, par ' broadcast timing (no penalty for this hubop)IIRC it was called something like DataLogger and perhaps I posted it in Obex.
It's no longer on my dev pc but I would have it archived somewhere.
Anyway, what I did was have all 1 cog get waitcnt and put it in hub. Then all other cogs grabed this and added a fixed amount (to cover the delay in getting it into a waitcnt value). Each of the cogs then added 0/1/2/3 to that value too, and then performed a waitcnt on the new value. They were then precisely 1 clock apart.
Hope this helps.