I'm not sure I understand, but if you mean can more than one SX be driven from some clock/oscillator, then sure. But that by itself does not achieve lock=step software operation. It would however assure that things progress on a synchronized basis, albeit there may be up to 4 clock skew in their pipelines, and who knows what for instruction offsets. You could create some syncing method such as portB interrupt to get them all strted on the same foot. Not likely that over the long term they would remain synced without using some recurring realignment process. And that is what my approach does with very little overhead.
sorry about the confusion - what I'm asking is pretty non-standard. Think of I2C where the master drives the SCL line. What I'm trying to say: Could a pinOut on a (master) controller be used *instead of*·the SX·clock/osc circuit. The osc crystal, resonator, or R/C would not be physically there -·the SX would be clocked·directly from the master output pin. Granted, the master would have to run much faster, or the SX much slower, but then you'd have hardwired syncing.·· If this were *electrically* possible, then there would be virtually no sync overhead. Or am I way off here?
( Pipelining is pretty easy to calculate since·all sx instrucs. cycle times are known and jumps of whatever kind just discard the pending instrucs. in the pipe. )
Yes, as you suggested, multiple SX's can be clocked from any voltage compatible source clock whether a fast SX or otherwise, but this in itself will not construe syncing between them and the master, nor between themselves. As I stated earlier, in the short term their execution will happen at the same rate, but it is their starting point that is in question. And for that you will need some event common to all (like a sync pulse) to bring them all (back) in line. And you will need to execute that correction more often than just once at start-up, particularly if the slave software performs decisions on external asynchronous events where the edges can exist at any point relative to the master generated clock. Some slaves will detect the transition, and others not until one cycle later, throwing the (software) sync off. Timing sync is likely to stay correct, but some resyncing of your software will be required. And the sync pulse can do that among all slaves at once.
Well sometimes it takes saying the same thing more than once to make it clear - I appreciate your patience in explaining this again from another angle.·
OK, right, I think I got it now ...·I'll·repeat that back in my own words: even if the clocks are in lock-step, the routines can cause·loss of sync, as you just mention.·So there's really two issues to avoid - clock drift and, for lack of a better term, this software drift. The former is avoided by a 'fast-enough' sync pulse emission ("100 or 200 clocks", etc.) and the latter by re-lining things up with·sync pulse itself.
Correct on both?
thanks a bunch
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
Post Edited (CounterRotatingProps) : 6/14/2009 11:48:37 PM GMT
In my applications I use a rapid sync pulse of 100 nSec at a rate of 1 uSec (and sometimes 2 or 2.5 uSec) to align the clocks as well as the communication sotware. By doing that I can "blindly" sample for fast asynchronous data pulses 150 nSec after the sync (start) edge, and every 100 nSec thereafter. Each bit is usually 100 nSec, yielding a 10 Mbit data rate.
At that speed there are only 5 instructions per bit... that allows for one loop ie. a test and an @jump So that pretty well means in-line code (ugly but doable) or setting up a very code efficient buffer. That buffer of course, now that you presumably are synced, could allow for specified numbers bit gaps between bytes, and then get the next byte(s). All very carefully laid out, you CAN get very high performance, but not very generic.
This approach is only worth the effort for experimentation or where the throughput needs to be extreme. You will need to inventive, but that gets easier now that you are synced. All kinds of concepts can be conjured up............. One application I used it for is generating a precise high speed pseudo random sequence for a Direct Sequence Spread Spectrum radio I am (slowly) building. There, the beauty of syncing is great for tracking and recovery of the transmitted chips.
Very interesting, Peter --- actually, I was just wondering last week if these devices could do / follow freq. sequencing for SS radio --- please keep us posted on that project.
> 5 instructions per bit
ugh, that's pretty limiting indeed... this should be a challenge to try... thanks,
For frequency hopping SS, you dont need much. For Direct Sequence SS...... much more complicated but should work a ton better if you do it right. So far for what I've seen, other than the GPS guys, many seem to be doing it wrong!
Comments
thanks.
good explanation,
I think I understand.
learned a lot, and it could be quite useful to me so thanks again.
cool
-5ms
I'm not sure I understand, but if you mean can more than one SX be driven from some clock/oscillator, then sure. But that by itself does not achieve lock=step software operation. It would however assure that things progress on a synchronized basis, albeit there may be up to 4 clock skew in their pipelines, and who knows what for instruction offsets. You could create some syncing method such as portB interrupt to get them all strted on the same foot. Not likely that over the long term they would remain synced without using some recurring realignment process. And that is what my approach does with very little overhead.
Cheers,
Peter (pjv)
sorry about the confusion - what I'm asking is pretty non-standard. Think of I2C where the master drives the SCL line. What I'm trying to say: Could a pinOut on a (master) controller be used *instead of*·the SX·clock/osc circuit. The osc crystal, resonator, or R/C would not be physically there -·the SX would be clocked·directly from the master output pin. Granted, the master would have to run much faster, or the SX much slower, but then you'd have hardwired syncing.·· If this were *electrically* possible, then there would be virtually no sync overhead. Or am I way off here?
( Pipelining is pretty easy to calculate since·all sx instrucs. cycle times are known and jumps of whatever kind just discard the pending instrucs. in the pipe. )
thanks,
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
Yes, as you suggested, multiple SX's can be clocked from any voltage compatible source clock whether a fast SX or otherwise, but this in itself will not construe syncing between them and the master, nor between themselves. As I stated earlier, in the short term their execution will happen at the same rate, but it is their starting point that is in question. And for that you will need some event common to all (like a sync pulse) to bring them all (back) in line. And you will need to execute that correction more often than just once at start-up, particularly if the slave software performs decisions on external asynchronous events where the edges can exist at any point relative to the master generated clock. Some slaves will detect the transition, and others not until one cycle later, throwing the (software) sync off. Timing sync is likely to stay correct, but some resyncing of your software will be required. And the sync pulse can do that among all slaves at once.
Cheers,
Peter (pjv)
Well sometimes it takes saying the same thing more than once to make it clear - I appreciate your patience in explaining this again from another angle.·
OK, right, I think I got it now ...·I'll·repeat that back in my own words: even if the clocks are in lock-step, the routines can cause·loss of sync, as you just mention.·So there's really two issues to avoid - clock drift and, for lack of a better term, this software drift. The former is avoided by a 'fast-enough' sync pulse emission ("100 or 200 clocks", etc.) and the latter by re-lining things up with·sync pulse itself.
Correct on both?
thanks a bunch
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
Post Edited (CounterRotatingProps) : 6/14/2009 11:48:37 PM GMT
Yup.
In my applications I use a rapid sync pulse of 100 nSec at a rate of 1 uSec (and sometimes 2 or 2.5 uSec) to align the clocks as well as the communication sotware. By doing that I can "blindly" sample for fast asynchronous data pulses 150 nSec after the sync (start) edge, and every 100 nSec thereafter. Each bit is usually 100 nSec, yielding a 10 Mbit data rate.
Have fun.
Cheers,
Peter (pjv)
in your detailed post of 6/13, you mention 'short bursts' at that speed ... how do you figure the burst length, by experimentation?
just got my prop boards today... let's see what I can come up with [noparse]:)[/noparse])
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
At that speed there are only 5 instructions per bit... that allows for one loop ie. a test and an @jump So that pretty well means in-line code (ugly but doable) or setting up a very code efficient buffer. That buffer of course, now that you presumably are synced, could allow for specified numbers bit gaps between bytes, and then get the next byte(s). All very carefully laid out, you CAN get very high performance, but not very generic.
This approach is only worth the effort for experimentation or where the throughput needs to be extreme. You will need to inventive, but that gets easier now that you are synced. All kinds of concepts can be conjured up............. One application I used it for is generating a precise high speed pseudo random sequence for a Direct Sequence Spread Spectrum radio I am (slowly) building. There, the beauty of syncing is great for tracking and recovery of the transmitted chips.
Cheers,
Peter (pjv)
> 5 instructions per bit
ugh, that's pretty limiting indeed... this should be a challenge to try... thanks,
cheers,
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
For frequency hopping SS, you dont need much. For Direct Sequence SS...... much more complicated but should work a ton better if you do it right. So far for what I've seen, other than the GPS guys, many seem to be doing it wrong!
Cheers,
Peter (pjv)