Text preview for : 19770728_D0_RS232C_Controller_Functional_Specifications.pdf part of xerox 19770728 D0 RS232C Controller Functional Specifications xerox sdd memos_1977 19770728_D0_RS232C_Controller_Functional_Specifications.pdf
Back to : 19770728_D0_RS232C_Contro | Home
Internal Memorandum
To Distribution Date July 28, 1977
From Victor Schwartz and Roy Ogus Location Palo Alto
Subject DO RS232C Controller Organization SOO/SO/CS
Functional Specifications
XEROX SDD ARCHIVES
XEROX I have read and understood
Pages _________To _________
Reviewer Date _ _ __
Filed on: [MAXC]Control\er-memo.press
I of Pagee Ref .,1;7~DD- Z'7t
Introduction
This memo specifies the functions performed by the DO RS232C Controller, and how
PILOT software interfaces to the controller microcode in order to control these functions.
Controller Status Block
Software and microcode communicate via Controller Status Blocks (CSBs) located at
dedicated memory addresses. There are separate CSBs for input and output (although
implementation may assign them contiguous), since the support of full-duplex links
requires the microcode to treat input and output as separate channels. The CSB contains
various flags (see Table Formats below), and a pointer to a chain of Input/Output Control
Blocks (IOCBs).
Input/Output Control Block
The IOCB is the structure by which the software passes a single command to the controller
microcode. Parameters within the IOCB describe the function to be performed, the
resulting status, and the data areas involved. IOCBs are chained together by PILOT
software, and are processed sequentially by the microcode. Each IOCB instructs the
microcode as to which process wakeups to perform and when. Each processed IOCB is
flagged by the microcode, and later dequeued by the software.
Command
Five commands are described by the command field in the IOCB. They are:
1. Reset
2. Change parameter
3. Transmit/Receive frame
4. Transmit break (asynchronous lines only)
5. Dial-a-Digit
Frames
A frame is the smallest meaningful unit of transmission across the communication link.
The format and content of a frame depend upon the link control protocol, and are
described in Frame Formats below, for each of the link control protocols supported by the
DO RS232C Controller. Frames are stored into frame buffers allocated by software. A
single frame may be split across non-contiguous buffers to allow scatter/gather facilities,
although no buffer contains more than one frame.
Xerox
Private
Data
, DUAFT - DRAFT - DRAFT - DRAFT
2
DO RS232C Controller Functional Specifications
DRAFT - DRAFT - DRAFT - DRAFT
A single 10CB points to a single buffer. Therefore, on output, the software must indicate
(in the 10CB) whether a frame starts/ends in the associated buffer. On input, the
microcode will indicate (in the IOCB) whether a frame starts/ends in the associated buffer.
Two additional flags in the IOCB allow the software to specify which buffers may be used
by the microcode for the start of a frame, and to specify which buffers should force any
overflow data for the current input frame to be discarded. These facilities allow the
software to allocate buffers efficiently based on the anticipated nature of incoming data,
and to resynchronize should the data be other than as anticipated. For example, if the
software expects incoming frames to consist of a short header and a long body. which it
wishes to read into separate buffers. it can allocate a small buffer exactly equal to the
header length, followed by a buffer large enough to hold the largest anticipated frame
body. The IOCB for the small buffer would have the flag set allowing a frame to start,
and the IOCB for the large buffer would have the flag set requiring a frame to end. If a
short frame arrives which fits in the small buffer (Le. loss of synchronization between
frame size and buffer size), the microcode would bypass the large buffer, thereby
preventing it from being used inefficiently to hold a small frame. Should an illegally long
frame arrive, the flag in the IOCB for the large buffer would result in truncation.
preventing allocation of arbitrarily large numbers of buffers to invalid frames.
Device Dependent Parameters
In order to transmit and receive frames correctly, the controller microcode must know a
number of things about the device at the other end of the communication link. as well as
the associated link control protoco\' This information is communicated to the microcode
in two ways. First, there are three variants of microcode (one for asynchronous protocols.
one for BSC, and one for the bit-oriented protocols such as HDLC. SOLC. and AOCCP).
The software requests the loading of the proper variants microcode prior to any other
controller activity. Each microcode variants is properly coded to handle the general
characteristics of the associated line discipline. The second way to configure the
microcode, is via parameters, listed in Table Formats below, which are passed to the
microcode via change parameter commands when the link is first activated (Le. following a
reset), but may also be changed synchronously with frame transfers at any time.
Built-In Parameters
The fonowing parameters relate to the hardware configuration of the 00 and its associated
RS232C hardware (including modems and automatic calling equipment). It is assumed that
these parameters are available elsewhere, and are used in configuring the microcode prior to
its initial execution.
modem timeouts, clocking (internal or external), communication facility (half vs. full
duplex; switched vs. dedicated), existence of Automatic Calling Equipment (with or
without answer-detect circuitry), etc.
Note that the DO RS232C Controller will not provide receiver Signal element timing (i.e.
receive clock) for synchronous lines, but will expect the modem to provide it.
Xerox
Private
Data
3
DO RS232C Controller Functional Specifications
DRAFf - DRAFf - DRAFf - DRAFf
Table Formats,
CONTROLLER BLOCK
o 15
Pointer to first unprocessed IOCB (-I: NIL: no chain) Word 0
Wakeup Request bit mask Word 1
Flags set by MESA code Word 2
Flags set by Microcode Word 3
Flags
Bit Set by MESA code Set by Microcode
o Request to Send Clear to Send
1 Data Terminal Ready Data Set Ready
2 reserved Ring Indicator (latched)
3 reserved Carrier Detect
4 Ring Indicator reserved
5 .' reserved Data lost (latched)
6 reserved Break detected (latched)
7 reserved Call Origi nation Status
8 Call Request Data Line Occupied
9-14 reserved reserved
15 Abort Microcode is running
Note: Input status matches as closely as possible the actual state of the controller. Output
status is generated by the controller to match the bits in the Controller Status
Block. Latched status bits, when set by microcode, will remain set until cleared by
the software (via the change parameter command).
Xerox
Private
Data
4
DO RS232C Controller Functional Specifications
DRAFf - DRAFT - DRAFT - DRAFr
IOCB: Reset, TransmitlReceil'e Frame, Transmit Break Commands
Pointer to next IOCB (-1= NIL= end of chain) Word 0
0 Long Pointer to ... Word 1
... frame buffer (-1= NIL= no buffer) Word 2
Command Word Word 3
Completion Word Word 4
length (bytes of data) Word 5
maxlength (bytes of buffer: input only) Word 6
Pilot Event ID Word 7
Command Word
bit 0 = Wakeup requested upon completion of IOCB
bit 1 = Wakeup requested if error encountered while processing this IOCB.
bit 2 = Stop if error encountered while processing IOCB; do not proceed to next IOCB.
bit 3 = Start of Frame
bit 4 = End of Frame
bits 5-7 = reserved ." ; . ..
_ ::. . :; .. ,, __ , .. t _
bits 8-15= Command:
1= Reset
2= Change Parameter: see IOCB: Change Parameter Command
3= Transmit/Receive Frame
4= Transmit Break: for asynchronous lines only.
5= Dial-a-Digit: see IOCB: Dial-a-Digit Command
Xerox
Private
Data
DO RS232C Controller Functional Specifications
s
DRAFf - DRAFf - DRAFf - DRAFf
Completion Word: 0= 10CB is unprocessed. Else. status word is as fol1ows:
bit 0 = 10CB-has-been-processed flag.
bit 1 = Error
bit 2 = End of Frame
bits 3-7 = reserved
bits 8-15= Status:
1= Success
2= Data lost (overrun)
3= Break detected
4= Frame timeout
5= CRC error
6= LRC/VRC error
7= Invalid character (BSCI ASCII)
8= Block check (BSC)
9= Invalid frame
10= Asynchronous framing error (i.e. stop bit(s) missing)
11= Invalid 10CB (e.g. illegal command or bad parameter)
255= Disaster (e.g. DSR lost): See CSB for further information.
length/maxlength: on output, the software fills the buffer and stores a byte count in
length; maxlength is not used. On input, the software sets maxlength to indicate
the size of the buffer. and the microcode sets length to indicate how many data
bytes were stored in the buffer.
Xerox
.