Rockwell Automation 1770-KF2 Data Highway or Highway Plus Interface Module User Manual - Manual (Page 220)

Detailed Flowcharts
Appendix D
DĆ16
Figure D.19
SLEEP and WAKEUP Interaction
PROCESS A PROCESS B PROCESS C
SLEEP
A Previous
Wakeup
Later
WAKEUP
2
1
7
8
3
6
5
Sequence of processor
execution is indicated
by circled numbers.
11672
NOTE 1:
SLEEP and WAKEUP are always
used in connection with some type of
indivisible interprocess interlock. Indivis-
ibility is achieved on many processors
(e.g., -Z-80) by disabling processor inter-
rupts. For this reason, SLEEP and
WAKEUP assure that interrupts are OFF
when they are called. They will always
return with interrupts OFF.
The interaction of SLEEP and WAKEUP:
When one process calls SLEEP, the
result is a return from a WAKEUP by
another process. When a process calls
WAKEUP, the result is a return from a
call to SLEEP by another process. An
interrupt subroutine that calls WAKEUP
is viewed as a subroutine of the inter-
rupted process.
In the above example, Process B woke
up Process A some time ago. Now, at 1,
when A goes to sleep, actual execution
resumes after the wakeup call in B at 3
and 4. Sometime later, Process C (at an
interrupt, for example) calls WAKEUP at
5. Execution flow proceeds to the in-
structions at 8 following the call to
SLEEP in Process A. The next time A
calls SLEEP, the WAKEUP call in C will
terminate.
NOTE 2:
This is not the only possible implementa-
tion of SLEEP and WAKEUP.
Another implementation would allow a
process to call WAKEUP without losing
immediate control of the processor.
Context switching would be deferred un-
til B itself executed a SLEEP.
A third alternative would cause a context
switch if a process performed a
WAKEUP on a higher priority process. If
a WAKEUP was performed on a lower
priority process, the context switch
would be deferred until the first process
went to SLEEP.
The first alternative is the result of
implementing the driver totally at inter-
rupt level. The third alternative would be
used if the driver were implemented as
tasks-- under a multi-tasking operating
system. Such an implementation might
be easier but would probably be limited
to lower baud rates.
4