Stamp synchronizing
Archiver
Posts: 46,084
I have a requirement for two different circuits that must not operate at
the same time. Both control NFETs that do different tasks at different
timing cycles. For example, one uses PULSOUT at about a 1Khz rate, the
other uses a PULSOUT once every 30 seconds.
Each task, by itself, may vary it's PRF and PULSOUT duration and they
must both never be ON at the same time. In fact there must be a 1
millisecond separation from either circuits operation.
I understand I could sync one to the other, by having one monitor an I/O
pin while in the input state and suspend operations if it gets high. I
suppose the other Stamp might also need to be rigged to monitor an input
signal in order that it does not operate if it receives a high from the
other Stamp.
I cannot use one Stamp to reset the other to accomplish this. Both
Stamps would control processes that are modulated.
I'm wondering what other methods of synchronization are possible without
complex handshaking. I suspect that it is possible that both Stamps
would issue a high at about the same time and halt operations
altogether.
the same time. Both control NFETs that do different tasks at different
timing cycles. For example, one uses PULSOUT at about a 1Khz rate, the
other uses a PULSOUT once every 30 seconds.
Each task, by itself, may vary it's PRF and PULSOUT duration and they
must both never be ON at the same time. In fact there must be a 1
millisecond separation from either circuits operation.
I understand I could sync one to the other, by having one monitor an I/O
pin while in the input state and suspend operations if it gets high. I
suppose the other Stamp might also need to be rigged to monitor an input
signal in order that it does not operate if it receives a high from the
other Stamp.
I cannot use one Stamp to reset the other to accomplish this. Both
Stamps would control processes that are modulated.
I'm wondering what other methods of synchronization are possible without
complex handshaking. I suspect that it is possible that both Stamps
would issue a high at about the same time and halt operations
altogether.
Comments
> I have a requirement for two different circuits that must not operate
> at the same time. [noparse][[/noparse]...]
> I'm wondering what other methods of synchronization are possible
> without complex handshaking. I suspect that it is possible that both
> Stamps would issue a high at about the same time and halt
> operations altogether.
They would. Eventually, at least. According to Murphy's Law, it won't happen
until it's absolutely essential that they NOT hang. Like when your client is
watching his first demo...
Last month, I was in the middle of designing a three-processor interface
with options for more when I got interrupted with a crucial doorbell design.
(Such is the excitement of retirement<g>.) For what it's worth, here is the
approach I'm using:
What we must have is a sequence like this on each processor:
1. Get the token.
2. Do whatever we like.
3. Release the token.
The tricky part is acquiring and releasing a token when ties are possible.
The method chosen to acquire cannot permit two contenders to believe they've
acquired the token, and the method chosen to release cannot permit one
contender to believe the token has been freed, while the other contenders
all believe it is still in use by the last winner. (We call that a "lost
token" interlock.)
Ties can be excluded when you have something serial in nature, like a token
ring network where each node hands off to only one other. You could use that
technique by having a recurring exchange between the two stamps. Here: your
turn, Stamp 2. Back at you, Stamp 1: your turn now. I've never tried this
technique because it looks seriously flawed to me on processors without
interrupts. I'm open to correction, but I don't see how I could program that
recurring exchange when both stamps have other things to do. And if they do
not, then why do I need the synchronization? It seems like the subordinate
processor would have to be always "available for a call" from the other. So
in this context, I'll skip on to a more usable method.
We need to create a hardware token. A latch is probably easiest. We need one
that is regularly clocked to enter data from it's input lines. Wire one pin
from each supported processor to an input line of the latch. Put the highest
priority processor on the highest order bit of the latch input. The get and
release sequence would look like this on each processor:
1. Raise our request line.
2. DO
[noparse][[/noparse]Possibly clock the latch, but see note 1 below]
Read the latch.
Set WeHaveToken by examining the value read. [noparse][[/noparse]see note 2 below]
LOOP UNTIL (1=WeHaveToken)
3. Do whatever we have to do while holding the token. [noparse][[/noparse]see note 3 below]
4. Lower the request line.
Note 1. Clocking. Our request line, and any others raised by other
contenders, will not affect the latch output value until it is clocked. That
is, when the "Output Enable" line is changed appropriately. We can let the
contender processors create the clock themselves by raising a strobe line,
but that creates its own difficulties when wiring the circuit, as well as
the possibility that the latch never gets clocked if something goes wrong.
I'd just as soon put an independent clock on the circuit. Can anyone suggest
a simple alternative to handle the case where multiple processors try to
clock the latch in the same short time interval? (There probably is one I'm
just not seeing, because I have this important doorbell to complete, you
see.) If you do let the requestors clock the latch, no clock pulse is needed
when releasing a token because we've dropped our line and that's all it
takes. The requestor always clocks the latch before reading it under that
protocol above and our lowered line will be reflected in the new value
clocked in at that time. The "release the token" step cannot fail from this
cause.
Note 2: We examine the output value to determine whether the token is ours.
If the output bit corresponding to our request line is the highest bit set,
then we have the token. If any higher order bit is set, then someone else
acquired it. We ignore any lower order bits.
Suppose we are the third processor in priority. We will set WeHaveToken to
one if the value of the latch is 001xxxxx. If our bit is set, but so is a
higher one, as in 011xxxxx, then we do NOT have the token. In other words,
for processor 3, we shift right five bits and the result must be exactly
one. The statement would look something like:
WeHaveToken=0
IF (1=(LatchValue>>5)) THEN WeHaveToken=1
Remember this is the way it would look on the third processor only. The
number of bits to shift is determined by our position in the hierarchy.
I'd use boolean expressions to make those statements look even simpler, but
I don't know offhand how PBasic 2.5 accommodates that, if at all. I suspect
it could be written as simply:
DO
[noparse][[/noparse]Clock the latch if that isn't happening externally.]
[noparse][[/noparse]Update LatchValue]
LOOP UNTIL (1=(LatchValue>>5))
but I don't know for sure.
Note 3: We must leave no possibility that a processor hangs without lowering
the request line. A couple of ways are available to "watchdog" this if the
software leaves it open as a possibility. For example, an RC circuit can be
used to lower the request line automatically after a time interval chosen to
be longer than any legitimate period to hold the token. The same circuit
might be used to reset the offending Stamp at such times.
All of this meets the classic requirement of handling ties, because latch
circuits are designed to be definitive. They will read each request line as
being either high or low, even if a signal is in transition at the time of
the clock. And we have provided a prioritization that ensures that only
processor will consider that it holds the token even if two or more request
it between two clocks.
Sorry this isn't reduced to actual code and wiring yet, but maybe it will
help anyway.
Oh yes. You had a constraint about one millisecond separating actions on
those shared resources. You can accommodate that with a pause statement
after acquiring the token, although that unnecessarily delays action by
inserting a delay even when the other processor did NOT just release the
token. If that inefficiency is an issue, then put an RC circuit around
somewhere. Maybe let the request line of each processor charge a cap that
takes one millisecond plus to discharge, so the input pin of the latch does
not actually see a logic low until one millisecond after the token is
released.
Gary
Off to work on doorbells...
Your mention of interrupts and tokens rang a bell (not yours.[noparse]:)[/noparse]
Stamp#1 (real worker bee), PRF approx. 1 Khz within the pulsing loops
looks for a high (request) on an Input pin. When detected wanders off
into continuous looping looking for that high to dissipate, plants a
high and holds it (permission) on Stamp#2 Input pin. When the request
drops, it clears the permission and resumes it's pulsing loop.
Stamp#2, PRF approx. 2hz, is in a timing loop waiting for the proper
time or temperature. Plants a high (request) on #1's input,
interrupting it's process and holds it. It keeps an eye on it's Input
pin waiting for a high (permission), PAUSEing a millisecond. It does
its PULSOUT, DEBUG, PAUSEs for a millisecond, LOWs (drops request) on
the #1 Input pin and returns to it's timing loop, ignoring it's
permission Input pin.
The need for the permission line is to compensate for any time for DEBUG
statements that #1 might be in the process of rattling off. Were #2 to
blindly attempt to assert control while #1 was DEBUGing the millisecond
PAUSE could expire and both Stamps would be in a position to execute
their function.
I suppose the allowance for #1's DEBUG statement time was the thing that
was subconsciously bothering
me. I had felt, but couldn't put my finger on it, that #2 could not
blindly do it's job until it knew #1 had acknowledged the request.
Thanks for the info on token methodology though. That will be filed for
future projects and I'm sure will come in handy some day.
Good luck on your Stamp doorbell project! Are you sure it wouldn't be
cheaper to hire a white gloved attendant to greet and screen
visitors???? [noparse]:)[/noparse]
"Gary W. Sims" wrote:
>
> From: "Don Denhardt" <dondenhardt@y...>
> > I have a requirement for two different circuits that must not operate
> > at the same time. [noparse][[/noparse]...]
> > I'm wondering what other methods of synchronization are possible
> > without complex handshaking. I suspect that it is possible that both
> > Stamps would issue a high at about the same time and halt
> > operations altogether.
>
> They would. Eventually, at least. According to Murphy's Law, it won't happen
> until it's absolutely essential that they NOT hang. Like when your client is
> watching his first demo...
>
> Last month, I was in the middle of designing a three-processor interface
> with options for more when I got interrupted with a crucial doorbell design.
> (Such is the excitement of retirement<g>.) For what it's worth, here is the
> approach I'm using:
>
> What we must have is a sequence like this on each processor:
>
> 1. Get the token.
> 2. Do whatever we like.
> 3. Release the token.
>
> The tricky part is acquiring and releasing a token when ties are possible.
> The method chosen to acquire cannot permit two contenders to believe they've
> acquired the token, and the method chosen to release cannot permit one
> contender to believe the token has been freed, while the other contenders
> all believe it is still in use by the last winner. (We call that a "lost
> token" interlock.)
>
> Ties can be excluded when you have something serial in nature, like a token
> ring network where each node hands off to only one other. You could use that
> technique by having a recurring exchange between the two stamps. Here: your
> turn, Stamp 2. Back at you, Stamp 1: your turn now. I've never tried this
> technique because it looks seriously flawed to me on processors without
> interrupts. I'm open to correction, but I don't see how I could program that
> recurring exchange when both stamps have other things to do. And if they do
> not, then why do I need the synchronization? It seems like the subordinate
> processor would have to be always "available for a call" from the other. So
> in this context, I'll skip on to a more usable method.
>
> We need to create a hardware token. A latch is probably easiest. We need one
> that is regularly clocked to enter data from it's input lines. Wire one pin
> from each supported processor to an input line of the latch. Put the highest
> priority processor on the highest order bit of the latch input. The get and
> release sequence would look like this on each processor:
>
> 1. Raise our request line.
>
> 2. DO
> [noparse][[/noparse]Possibly clock the latch, but see note 1 below]
> Read the latch.
> Set WeHaveToken by examining the value read. [noparse][[/noparse]see note 2 below]
> LOOP UNTIL (1=WeHaveToken)
>
> 3. Do whatever we have to do while holding the token. [noparse][[/noparse]see note 3 below]
>
> 4. Lower the request line.
>
> Note 1. Clocking. Our request line, and any others raised by other
> contenders, will not affect the latch output value until it is clocked. That
> is, when the "Output Enable" line is changed appropriately. We can let the
> contender processors create the clock themselves by raising a strobe line,
> but that creates its own difficulties when wiring the circuit, as well as
> the possibility that the latch never gets clocked if something goes wrong.
> I'd just as soon put an independent clock on the circuit. Can anyone suggest
> a simple alternative to handle the case where multiple processors try to
> clock the latch in the same short time interval? (There probably is one I'm
> just not seeing, because I have this important doorbell to complete, you
> see.) If you do let the requestors clock the latch, no clock pulse is needed
> when releasing a token because we've dropped our line and that's all it
> takes. The requestor always clocks the latch before reading it under that
> protocol above and our lowered line will be reflected in the new value
> clocked in at that time. The "release the token" step cannot fail from this
> cause.
>
> Note 2: We examine the output value to determine whether the token is ours.
> If the output bit corresponding to our request line is the highest bit set,
> then we have the token. If any higher order bit is set, then someone else
> acquired it. We ignore any lower order bits.
>
> Suppose we are the third processor in priority. We will set WeHaveToken to
> one if the value of the latch is 001xxxxx. If our bit is set, but so is a
> higher one, as in 011xxxxx, then we do NOT have the token. In other words,
> for processor 3, we shift right five bits and the result must be exactly
> one. The statement would look something like:
>
> WeHaveToken=0
> IF (1=(LatchValue>>5)) THEN WeHaveToken=1
>
> Remember this is the way it would look on the third processor only. The
> number of bits to shift is determined by our position in the hierarchy.
>
> I'd use boolean expressions to make those statements look even simpler, but
> I don't know offhand how PBasic 2.5 accommodates that, if at all. I suspect
> it could be written as simply:
>
> DO
> [noparse][[/noparse]Clock the latch if that isn't happening externally.]
> [noparse][[/noparse]Update LatchValue]
> LOOP UNTIL (1=(LatchValue>>5))
>
> but I don't know for sure.
>
> Note 3: We must leave no possibility that a processor hangs without lowering
> the request line. A couple of ways are available to "watchdog" this if the
> software leaves it open as a possibility. For example, an RC circuit can be
> used to lower the request line automatically after a time interval chosen to
> be longer than any legitimate period to hold the token. The same circuit
> might be used to reset the offending Stamp at such times.
>
> All of this meets the classic requirement of handling ties, because latch
> circuits are designed to be definitive. They will read each request line as
> being either high or low, even if a signal is in transition at the time of
> the clock. And we have provided a prioritization that ensures that only
> processor will consider that it holds the token even if two or more request
> it between two clocks.
>
> Sorry this isn't reduced to actual code and wiring yet, but maybe it will
> help anyway.
>
> Oh yes. You had a constraint about one millisecond separating actions on
> those shared resources. You can accommodate that with a pause statement
> after acquiring the token, although that unnecessarily delays action by
> inserting a delay even when the other processor did NOT just release the
> token. If that inefficiency is an issue, then put an RC circuit around
> somewhere. Maybe let the request line of each processor charge a cap that
> takes one millisecond plus to discharge, so the input pin of the latch does
> not actually see a logic low until one millisecond after the token is
> released.
>
> Gary
> Off to work on doorbells...
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and Body
of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
> [noparse][[/noparse]describes req-ack solution]
> Thanks for the info on token methodology though. That will be
> filed for future projects and I'm sure will come in handy some day.
>
Since you and others may well file it, let me expand that ad lib description
slightly. I neglected to mention a couple of important points.
First, the winner in that little contention only has the token for the
duration of one clock tick. That suited my purposes fine, using a little
clock circuit running at 500 hz to 2 kHz as my application might require.
The stamps are all doing the same thing when they get the token (posting a
message in a shared location) so variable times to retain the token were not
required.
That is not good enough if you can't be sure each Stamp can be serviced in
the longest clock tick. (Or if you don't want to make the token retention
time for everyone as long as the worst case for any Stamp.) To keep the
token longer than a single clock tick requires one additional step. After
you confirm you are entitled to the token, you must grasp it, so to speak.
With the latch example, the simplest way is probably an N-way NOR that is
AND'ed with the clock signal. Each of the N processors has one output pin
contributing to the NOR. Normally low, the pin is raised when the processor
has been granted the token by that priority scheme and wishes to retain it
beyond a single clock tick. You must drop this line as well as the request
line in order to release the token. Otherwise no further clock ticks will
reach the latch and changes in the request lines will not be recognized.
Second, all these issues are the ones that concern me with letting the
Stamps generate the clocks themselves. I doubt there is any easy solution to
that problem. A reliable clock independent of the contenders is a
fundamental need when synchronizing asynchronous parallel demands. It wasn't
the physical interconnection of all those possible clocks that worried me.
It was the logical treatment, and that's why I dropped it early in my
consideration and decided on a simple 555 ticking at the fastest rate that
would handle my slowest service need.
> Good luck on your Stamp doorbell project! Are you sure it
> wouldn't be cheaper to hire a white gloved attendant to
> greet and screen visitors???? [noparse]:)[/noparse]
>
Ah well. With the price of Stamps going down, and white gloves going
up...<g>
Gary