Rockwell-automation 1770-KF2 Data Highway or Highway Plus Interface Mo Manual de usuario descargar pdf (Pagina 220)

Detailed Flowcharts

Appendix D

D16

Figure D.19

SLEEP and W

AKEUP 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

1 2 ... 215 216 217 218 219 220 221 222 223 224 225 ... 234 235

Comentarios a estos manuales

Sin comentarios