|
This technical note documents the event record information that gets passed
when the serial driver posts an event for a break/CTS status change.
[Dec 01 1986]
|
CTS Status Change
The serial driver can be programmed to post a device driver event upon
encountering a break status change or CTS change (via the SerHShake
call). The structure of device driver events is driver specific. This technical
note documents the event record information that gets passed when the serial
driver posts a device driver event for a break/CTS status change.
When the event is posted, the message field of the event record will be a long
word (four bytes). The most significant byte will contain the value of SCC Read
Register 0 (see below for the relevant Read Register 0 values). The next byte
will contain the changed (since the last interrupt) bits of the SCC read
register 0. The lower two bytes (word) will contain the DCtlRefNum .
The values for Read Register 0 are as follows:
- If a break occurred, bit 7 will be set.
- If CTS changed, bit 5 will reflect the state of the CTS pin (0 means the handshake line is asserted and that it is OK to transmit).
We discourage posting these events because interrupts would be disabled for a
long time while the event is being posted. However, it is possible to detect a
break or read the value of the CTS line in another way. A break condition will
always terminate a serial driver input request (but not an output
request), and the error breakRecd (-90) will be returned. (This constant is
defined in the SysEqu file.) You could therefore detect a break by checking the
returned error code.
The state of the CTS line can be checked by making a SerStatus call
and checking the value of the ctsHold flag in the SerStaRec
record. See the Serial Drivers chapter of Inside Macintosh for
details.
Back to top
References
The Device Manager
Serial Drivers
Zilog Z8030/Z8530 SCC Serial Communications Controller Technical
Manual
Back to top
Downloadables
|
Acrobat version of this Note (52K)
|
Download
|
Back to top
|