top - download
⟦126e9e36a⟧ Wang Wps File
Length: 69872 (0x110f0)
Types: Wang Wps File
Notes: CPS/SDS/028
Names: »2040A «
Derivation
└─⟦4e34bac2f⟧ Bits:30006102 8" Wang WCS floppy, CR 0161A
└─ ⟦this⟧ »2040A «
WangText
?…00……00……00……00…=…02……00……00…=
<…0c…<…05…<…07…;…08…;…0c…;…0f…;…05…:…09…:…0d…:…0e…:…0f…:…05…:…06…9…0e…9…02…9…07…8…08…8…09…8…0a…8…0e…8
7…08…7…0c…7…0f…7
7…05…6…08…6…0b…6…00…6 5…0a…5…0f……86…1 …02… …02… …02…
…02…CPS/SDS/028
…02…840901…02……02…
I/O CONTROL
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
4.2.2 LTUX Handler Sub-Package ...............
4.2.2.1 Functional Specification ...........
4.2.2.1.1 Functional Breakdown ...........
4.2.2.1.1-1 VDU Handler Functions ......
4.2.2.1.1-2 MSTP Handler Function ......
4.2.2.1.1-3 PTP/PTR Handler Function ...
4.2.2.1.1-4 TRC/TRP Handler Function ...
4.2.2.1.1-5 OCR Handler Function .......
4.2.2.1.2 Functional Description .........
4.2.2.2 Software Structure .................
4.2.2.2.1 VDU Protocols ..................
4.2.2.2.2 OCR Protocol ...................
4.2.2.2.3 LSL-Protocol ...................
4.2.2.3 Data Flow and Control Logic ........
4.2.3.3.1 VDU Handler Flow ...............
4.2.2.3.1-1 VDU Protocol Data Flow and
Control Logic...............
4.2.2.3.1.2 VDU SPLIT CONTROL Data Flow
and Control Logic...........
4.2.2.3.1.3 VDU SPLIT DATA Data Flow and
Control Logic...............
4.2.2.3.2 OCR Handler Flow ...............
4.2.2.3.3 Low Speed Line Handler Flow ....
4.2.2.4 Module Specification ...............
4.2.2.4.1 VDU ̲INPUTTER Module ............
4.2.2.4.2 VDU ̲OUTPUTTER Module ...........
4.2.2.4.3 VDU ̲PROT CONT Module ...........
4.2.2.4.4 VDU ̲CONTROLLER Module ..........
4.2.2.4.5 VDU SPLIT DATA USER INTERFACE
Module .........................
4.2.2.4.6 VDU SPLIT DATA SPI Module ......
4.2.2.4.7 VDU SPLIT DATA EHP Module ......
4.2.2.4.8 VDU SPLIT CONTROL USER INTERFACE
Module .........................
4.2.2.4.9 VDU SPLIT CONTROL SPI Module .
4.2.2.4.10 VDU SPLIT CONTROL EHP.........
4.2.2.4.11 LSL USER INTERFACE Module ....
4.2.2.4.12 LSL SPI Module ...............
4.2.2.4.13 LSL EHP Module ...............
4.2.2.4.14 LSL PROTOCOL Module ..........
4.2.2.5 Common Subpackage Data .............
4.2.2.6 Common Subpackage Procedures .......
4.2.2.7 Subpackage Interfaces ..............
4.2.3 LTU Handler Subpackage .................
4.2.3.1 Functional Specification ...........
4.2.3.1.1 Functional Breakdown .........
4.2.3.1.2 Functional Description .......
4.2.3.2 Software Specification .............
4.2.3.3 Data Flow and Control Logis ........
4.2.3.3.1 NICS TARE Flow .................
4.2.3.3.2 CCIS/SCARS Flow ................
4.2.3.4 Module Specification ...............
4.2.3.4.1 NT SPI Module ..................
4.2.3.4.2 NT EHP Module ..................
4.2.3.4.3 NT Subdevice Interface Module ..
4.2.3.4.4 NT INPUT CONVERTER Module ......
4.2.3.4.6 NT PROTOCOL Module .............
4.2.3.4.7 NT DATA USER INTERFACE Module ..
4.2.3.4.8 NT DATA SPI Module .............
4.2.3.4.9 NT DATA EHP Module .............
4.2.3.4.10 CS USER INTERFACE Module ......
4.2.3.4.11 CS SPI Module .................
4.2.3.4.12 CS EHP Module .................
4.2.3.4.13 CS INPUT CONVERTER Module .....
4.2.3.4.14 CS OUTPUT CONVERTER Module ....
4.2.3.4.15 CS PROTOCOL Module ............
4.2.3.5 Common Subpackage Data .............
4.2.3.6 Common Subpackage Procedures .......
4.2.3.7 Subpackage Interfaces ..............
4.2.3.7.1 LTU Handler - NICS TARE LTU
Function Subpackages Interface
HANDLER - LTU PROCOCOL SOFTWARE
INTERFACE ......................
4.2.3.7.2 LTU Handler Subpackage CCIS/SCARS
LTU FUNCTION SUBPACKAGE Interface
4.2.2 L̲T̲U̲X̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲
The LTUX Handler Sub-Package implements the definition
of terminals in DAMOS TMS sense for the following external
devices/channels:
VDU
Medium Speed Teleprinter
Papertape Reader/Puncher
TRC/Point-to-Point/Teleprinter
OCR
Figure 4.2.2.1.1-1 presents the functional breakdown
FIGURE 4.2.2.1.1-1
4.2.2.1.1.1 V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The VDU handler functions are
1.1 Initialization
1.2 VDU Control
Collection of key on/off reports, function key
reports, system key report
Setting of VDU key board filter, selecting the
split of the key board cursor.
LTUX FUNCTION Subpackage Control.
1.3 Format Handler communication. Implementation of
2 high level protocols per VDU split. One for data
in/out, one for control commands.
1.4 Data Transfer
Scheduling of output activities among splits and
the SSC control connection.
Scheduling of input activities
4.2.2.1.1.2 M̲S̲T̲P̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The MSTP Handler Functions are
2.1 Initialization
2.2 MSTP Control
Collection of key on/off reports, paper out report.
LTUX FUNCTION Subpackage Control.
2.3 Application communication
Implementation of one high level protocol
2.4 Data Transfer
Output of data from application.
4.2.2.1.1.3 P̲T̲P̲/̲P̲T̲R̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The PTP/PTR Handler Functions are
3.1 Initialization
3.2 PTP/PTR Control
Collection of key on/off reports (TBD). LTUX FUNCTION
subpackage control
3.3 Application Communication
Implementation of high level protocol
3.4 Data Transfer
Input/Output of data
4.2.2.1.1.4 T̲R̲C̲/̲T̲P̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
4.1 Initialization
4.2 TRC/TP Control
LTUX FUNCTION subpackage control
4.3 Application communication
4.4 Data transfer
4.2.2.1.1.5 O̲C̲R̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
5.1 Initialization
5.2 OCR Control
LTUX FUNCTION subpackage control
5.3 Application interface
5.4 Data input
4.2.2.1.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The numbers refer to the functional breakdown in 4.2.2.1.1
I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲(̲1̲.̲1̲,̲ ̲2̲.̲1̲,̲ ̲3̲.̲1̲,̲ ̲4̲.̲1̲,̲ ̲5̲.̲1̲)̲
The SDID record for the handler is initialized
C̲o̲n̲t̲r̲o̲l̲ ̲(̲1̲.̲2̲,̲ ̲2̲.̲2̲,̲ ̲3̲.̲2̲,̲ ̲4̲.̲2̲,̲ ̲5̲.̲2̲)̲
This function is control of the external device according
to the specification.
Setting the LTUX Function subpackage parameter to control
the device (Commands ENABLE, OPEN ̲PROTOCOL, CLOSE ̲PROTOCOL,
REDEFINE ̲PARAMS, STATISTICS, STATUS, DEVICE ̲STATUS)
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲(̲o̲r̲ ̲F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲)̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
(̲1̲.̲3̲,̲ ̲2̲.̲3̲,̲ ̲3̲.̲3̲,̲ ̲4̲.̲3̲,̲ ̲5̲.̲3̲)̲
Implementation of the required TMS interface. For VDU
further implementation of high level protocols.
D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲ ̲(̲1̲.̲4̲,̲ ̲2̲.̲4̲,̲ ̲3̲.̲4̲,̲ ̲4̲.̲4̲,̲ ̲5̲.̲4̲)̲
Implementation of standard protocol data transport
interfaces. For VDU scheduling of activities among
splits. The VDU handler communicates with 2 splits
for each split, one called primary the other secondary.
This allows the FORMAT handler to output data to the
secondary split and subsequently link it to the primary
without scrolling on the VDU.
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The LTUX Handler Subpackage is organized as a set of
protocols (DAMOS Term) within the STI handler.
V̲D̲U̲ VDU Protocol
VDU ̲SPLIT ̲DATA Protocol
VDU ̲SPLIT ̲CONTROL Protocol
O̲C̲R̲,̲ T̲R̲C̲ ̲T̲P̲, M̲S̲T̲P̲, P̲T̲P̲ ̲P̲T̲R̲ LSL Protocol
The three VDU protocols are elsewhere in this document
referred to as the VDU handler.
4.2.2.2.0 G̲e̲n̲e̲r̲a̲l̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The GHS consists of the following modules
GHS ̲INPUTTER module
GHS ̲OUTPUTTER
GHS ̲PROT ̲CONT
GHS ̲CONTROLLER
IOC ̲COMMON ̲PRC
GET ̲P ̲P ̲ADDR
GHS ̲SEND
4.2.2.2.1 V̲D̲U̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
The VDU Protocol consists of the following modules:
VDU ̲SUBDEVICE ̲INTERFACE module
VDU ̲SPI module
VDU ̲EHP module
VDU ̲PROTOCOL module
The VDU ̲SPLIT ̲DATA Protocol consists of the following
modules
VDU ̲SPLIT ̲DATA ̲USER ̲INTERFACE module
VDU ̲SPLIT ̲DATA ̲SPI module
VDU ̲SPLIT ̲DATA ̲EHP module
The VDU ̲SPLIT ̲CONTROL Protocol consists of the following
modules
VDU ̲SPLIT ̲CONTROL ̲USER ̲INTERFACE module
VDU ̲SPLIT ̲CONTROL ̲SPI module
VDU ̲SPLIT ̲CONTROL ̲EHP module
4.2.2.2.2 O̲C̲R̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The OCR Protocol consists of
OCR ̲USER ̲INTERFACE module
OCR ̲SPI module
OCR ̲EHP module
OCR ̲PROTOCOL module
4.2.2.2.3 L̲S̲L̲-̲P̲r̲o̲t̲o̲c̲o̲l̲
The LSL Protocol consists of
LSL ̲USER ̲INTERFACE module
LSL ̲SPI module
LSL ̲EHP module
LSL ̲PROTOCOL module
4.2.2.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
4.2.2.3.1 V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲l̲o̲w̲
The VDU handler transfers data from/to a number of
sources to/from LTUX.
The sources are:
1) The creator of the protocol will by means of Control
Commands set up the VDU. The Control Commands are
output followed by input.
2) Output from data terminals.
3) Input from data terminals.
4) Input of control info.
The environment is shown in figure 4.2.2.3.1-1 and
the data transport mechanisms in fig. 4.2.2.3.1-2.
FIGURE 4.2.2.3.1-1
FIGURE 4.2.2.3.1-2
The dataflow on module level (leaving out SPI and EHP
modules) is shown in figure 4.2.2.3.1-3 for one split
(DATA and CONTROL).
4.2.2.3.1-1 V̲D̲U̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The VDU Protocol communicates with 5 parts:
a) The data and control to/from the LTUX is performed
via the STI handler LTUX protocol. The interface
is implemented via the SPI interfaces. The data
exchanged is specified in section 4.2.2.7.
b) Input and output from/to a split is exchanged with
the VDU ̲SPLIT ̲DATA protocol. The data formats exchanged
follow the standard LDU conventions.
c) Output and input is exchanged with the VDU ̲SPLIT
̲CONTROL for commands and function key requests.
The format for output is:
1.byte Data, Entire LDU
2.byte LDU id
3.byte Command Code
(SUBSPLIT ̲SELECT,
SUBSPLIT ̲LINK,
DATA ̲KEY ̲ENABLE)
Subsplit select: 4.byte (PRIMARY, SECONDARY)
Cancel and response as usual.
The format for input is the standard.
Response: Either Entire LDU returned with the data
containing function by:
1.-2. byte standard
3. byte FUNCTION ̲KEY
or reception status giving the error code.
d) Controller interface to SSC via IOS/TMS. The format
of the data exchanged is defined in section 4.1.7.2.4
and has a 1:1 correspondence with the LTUX control
interface described in section 4.2.2.7.
FIGURE 4.2.2.3.1-3
e) Protocol creation/deletion via OPEN ̲SUBDEVICE,
CLOSE ̲SUBDEVICE.
The processing for the different transactions is:
I̲n̲p̲u̲t̲ (DATA). The VDU ̲SPLIT ̲DATA sends an input request.
The VDU ̲SUBDEVICE ̲INTERFACE module adds a communication
cursor addressing to the request before handing it
to the INPUTTER.
When data returns the SUBDEVICE ̲INTERFACE module loads
the LDU identification of the VDU ̲SPLIT ̲DATA instead
of the LDU identification used by the VDU protocol.
O̲u̲t̲p̲u̲t̲ (DATA). The VDU ̲SPLIT ̲DATA requests an output
buffer. The VDU OUTPUTTER module is requested to handle
the request. Eventually an output buffer is returned
to the VDU ̲SPLIT ̲DATA. In the first output buffer
for a LDU room is reserved by the VDU ̲SUBDEVICE ̲INTERFACE
module for load of display cursor address when the
buffer is output.
Eventually the output is completed and the LDU id of
VDU ̲SPLIT ̲DATA is loaded into the control buffer before
it is returned to the VDU ̲SPLIT ̲DATA.
Input and output may also be performed by the CONTROLLER
when the SSC uses control types EXTERNAL ̲DEVICE ̲INPUT
and EXTERNAL ̲DEVICE ̲OUTPUT.
I̲n̲p̲u̲t̲ ̲(̲C̲O̲N̲T̲R̲O̲L̲)̲. The VDU ̲SPLIT ̲CONTROL presents an
input request to the VDU ̲SUBDEVICE ̲INTERFACE. This
module detects that the request is from the Control
Split and directs the request to the VDU ̲PROTOCOL module.
(Function keys are returned as data to the VDU ̲SPLIT
̲CONTROL).
O̲u̲t̲p̲u̲t̲ ̲(̲C̲O̲N̲T̲R̲O̲L̲)̲ The VDU ̲SPLIT ̲CONTROL presents the
output data to the VDU ̲SUBDEVICE ̲INTERFACE which directs
it to the VDU ̲PROTOCOL ̲MODULE. This selection is performed
on time of the SPLIT ̲CONTROL making Reserve Output
Buffer.
4.2.2.3.1.2 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The VDU ̲SPLIT ̲CONTROL Protocol communicates with 3
parts:
a) TMS interface for transfer of Format Handler Control
requests.
b) VDU Protocol interface for output of control transfer
and input of function keys.
c) Protocol creation/deletion through OPEN ̲PROTOCOL,
CLOSE ̲SUBDEVICE.
O̲u̲t̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲s̲ are transferred to the VDU Protocol
as output control buffers and
I̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲s̲ are transferred to the VDU Protocol
as genuine input requests
4.2.2.3.1.3 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲D̲A̲T̲A̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Inputs and outputs to/from TMS are transferred as requests
to the VDU Protocol with one difference relative to
other devices. As TMS does not support sufficient "Position"
data space in input requests to allow transfer of ARM
commands, the Format Handler always loads the data
for the ARM command into the first output request issued
after input is requested. This output is not transferred
to the VDU protocol but included in the Input Request.
4.2.2.3.3 L̲o̲w̲ ̲S̲p̲e̲e̲d̲ ̲L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲l̲o̲w̲
The Low Speed Line Handler transfers data from/to the
application to/from the LTUX.
The environment for the Low Speed Line Handler is shown
in figure 4.2.2.3.3-1 and the data transfer mechanism
in figure 4.2.2.3.3-2.
For low speed lines the data transfer is of a different
nature from VDU. The input or output data streams are
to be seen on a contiguous string of records.
Output streams may be interrupted when no output request
is pending.
Input streams are interrupted by the LTUX on 4 conditions.
1) A time interval of more than N seconds between
two characters received.
2) Error condition, i.e. parity error or V24 status
line change occurred.
3) End of message detected.
4) A second Start of Transmission detected before
end of message.
The Low Speed Line Handler may be configured for input/output
or for output only. In the latter case input buffers
are not available.
In the following the abbreviation LSL is used for low
speed line.
The dataflow for the LSL protocol on a module level
is shown in figure 4.2.2.3.3-3. (SPI and EHP modules
not shown.
FIGURE 4.2.2.3.3-1
FIGURE 4.2.2.3.3-2
FIGURE 4.2.2.3.3-3
4.2.2.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
All modules in the LTUX HANDLER subpackage exept for
the PROTOCOL module of each protocol are specified
relative to the standard protocol modules described
in section 4.1.5 of this document. This way of documenting
the design is used in order to avoid duplication of
large amount of information.
4.2.2.4.1 VDU ̲SUBDEVICE ̲INTERFACE Module
Refer 4.1.5.7
Modify for handling of Control Split (interfaces to
VDU ̲PROTOCOL Module).
4.2.2.4.2 VDU ̲SPI Module
Refer 4.1.5.2
4.2.2.4.3 VDU ̲EHP Module
Refer 4.1.5.1
Modify such that TMS calls to
ENABLE ̲INPUT
GET ̲OUTPUT ̲BUFFER
are returned with code NOT ̲IMPLEMENTED
Delete calls to
CANCEL ̲USER ̲OPERATION
USER ̲OUTPUT
ACK ̲DATA ̲INPUT
ENABLE ̲INPUT
GET ̲OUTPUT ̲BUFFER
4.2.2.4.4 V̲D̲U̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲M̲o̲d̲u̲l̲e̲
4.2.2.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The VDU ̲PROTOCOL module handles
Function key requests,
Split link commands,
Subsplit select commands,
Datakey enable.
for the VDU ̲SPLIT ̲CONTROL
and
Interrupt buffer processing
System Key reporting
for the CONTROLLER module (SSC interface)
The processing for a function key request is:
1. The SUBDEVICE ̲INTERFACE module calls
REQUEST ̲PROTOCOL
2. When the protocol buffer is available it is returned
to the subdevice interface.
3. The Subdevice Interface module loads the input
request and sends it to the VDU ̲PROTOCOL module.
4. If the request has lower priority than all existing
FK request it is just queued.
5. If some FK request have lower priority they are
queued for priority override termination.
6. If the keyboard status needs change keyboard state
change is initiated.
The processing for Split link is:
1. The OUTPUTTER is requested for output.
2. When buffer available split link is loaded and
sent.
3. When result available the completion is loaded
into the protocol buffer and requestor notified.
The processing for subsplit select is:
The SUBDEV.PROTOCOL data in the twin subdevice is updated
to reflect the new split addressing and the requestor
immediately notified.
The processing for Datakey enable is:
If the split is active (the keyboard cursor is in this
split), the SET ̲KEYBOARD ̲STATE is requested to change
keyboard state.
In all cases the datakey enable in the SUBDEV.PROTOCOL
is set.
Interrupt buffer processing is:
Key on/off and system key are reported to SSC.
Legal function keys to requestor (if any active)
Trapped keys ignored.
Function keys and trapped keys leads to reset of keyboard
state (The state is set to Unknown at these events).
4.2.2.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The VDU ̲PROTOCOL module is called via one of the following
entries.
INITIALIZE ̲PROTOCOL ̲DATA(PARAM: OPEN ̲SUBDEVICE ̲PARAM)(
)
CLEAN ̲PROTOCOL ̲DATA( )( )
REQUEST ̲PROTOCOL(QEL: IO ̲QEL, PRIORITY: PRIORITY ̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER ̲REF:
POINTER)
SEND ̲PROTOCOL(CC: COMPLETION ̲CODE, BUFFER ̲REF:
POINTER) ( )
NOTIFY ̲PROTOCOL ̲FIRST ̲OUTPUT ̲BUFFER(QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)( )
NOTIFY ̲PROTOCOL ̲SUBSEQUENT ̲OUTPUT ̲BUFFER(QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)( )
PROTOCOL ̲OUTPUT ̲RESULT(QEL: IO ̲QEL, BUFFER ̲REF:
POINTER)( )
CANCEL ̲PROTOCOL(QEL: IO ̲QEL)( )
RELEASE ̲PROTOCOL ̲BUFFER(BUFFER ̲REF: POINTER)( )
The VDU ̲PROTOCOL module calls following functional
entries to other modules:
SUBDEVICE ̲PROTOCOL ̲RESULT(QEL: IO ̲QEL, BUFFER ̲REF:
POINTER)( )
NOTIFY ̲SUBDEVICE ̲PROTOCOL ̲BUFFER(QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)( )
Furthermore
PROTOCOL ̲ERROR
QUEUE ̲PRIORITIZED
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
EXTRACT ̲SPECIFIED
SEND ̲STATUS ̲REPORT
4.2.2.4.4.3 M̲o̲d̲u̲l̲e̲ ̲c̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
E̲n̲t̲r̲y̲ ̲p̲o̲i̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
B̲a̲s̲i̲c̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
INITIALIZE ̲PROTOCOL ̲DATA
CLEAN ̲PROTOCOL ̲DATA
R̲e̲q̲u̲e̲s̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲PROTOCOL
CANCEL ̲PROTOCOL
SEND ̲PROTOCOL
RELEASE ̲PROTOCOL ̲BUFFER
O̲U̲T̲P̲U̲T̲T̲E̲R̲ ̲n̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲PROTOCOL ̲FIRST ̲OUTPUT ̲BUFFER
NOTIFY ̲PROTOCOL ̲SUBSEQUENT ̲OUTPUT ̲BUFFER
PROTOCOL ̲OUTPUT ̲RESULT
I̲n̲t̲e̲r̲r̲u̲p̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
NOTIFY ̲INTERRUPT
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
RETURN ̲PROTOCOL ̲BUFFER
RETURN ̲PROTOCOL ̲RESULT
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NEXT ̲PROTOCOL ̲ACTION
NEXT ̲FK ̲OVERRIDED
NEXT ̲PROTOCOL
K̲e̲y̲b̲o̲a̲r̲d̲ ̲s̲t̲a̲t̲e̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
SET ̲KEYBOARD ̲STATE
LOAD ̲KEYBOARD ̲SETTING
ACTIVATE ̲FIRST ̲FK
O̲u̲t̲p̲u̲t̲ ̲s̲u̲p̲p̲o̲r̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
LOAD ̲PROTOCOL ̲OUTPUT
4.2.2.4.5 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲D̲A̲T̲A̲ ̲U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.5
Modified to load input request data from output.
4.2.2.4.6 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲D̲A̲T̲A̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
Delete calls to
CLEAN ̲SUBDEVICES
CLEAN ̲PROT ̲CONT
CLEAN ̲CONTROLLER
CLEAN ̲PROTOCOL ̲DATA
NOTIFY ̲PROT ̲CONT ̲OUTPUT ̲BUFFER
NOTIFY ̲PROT ̲CONT ̲OF ̲RESPONSE
NOTIFY ̲INTERRUPT
INITIALIZE ̲CONTROLLER
INITIALIZE ̲SUBDEVICE ̲INTERFACE
INITIALIZE ̲PROT ̲CONT
INITIALIZE ̲PROTOCOL ̲DATA
RELEASE ̲INPUT ̲B
RESERVE ̲OUTPUT ̲BUFFER
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER
RELEASE ̲OUTPUT ̲BUFFER
TRANSMIT ̲OUTPUT ̲BUFFER
WANT ̲TO ̲CLOSE
(note these are mainly subdevice SPI entries).
4.2.2.4.7 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲D̲A̲T̲A̲ ̲E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.1
Modify such that
calls to
OPEN ̲SUBDEVICE, ENABLE ̲CONTROL ̲INPUT,
GET ̲CONTROL ̲BUFFER are answerred with
CC = NOT ̲IMPLEMENTED
Delete calls to
OPEN ̲SUBDEVICE
ENABLE ̲CONTROL ̲INPUT
GET ̲CONTROL ̲BUFFER
ACK ̲CONTROL ̲INPUT
CONTROLLER ̲OUTPUT
CANCEL ̲CONTROLLER ̲OPERATION
4.2.2.4.8 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.5
4.2.2.4.9 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
Delete calls as VDU ̲SPLIT ̲DATA ̲SPI module
(4.2.2.4.12)
4.2.2.4.10 V̲D̲U̲ ̲S̲P̲L̲I̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲E̲H̲P̲
Refer 4.1.5.1
Modify and delete as VDU ̲SPLIT ̲DATA ̲EHP module
(4.2.2.4.13)
4.2.2.4.11 L̲S̲L̲ ̲U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.5
4.2.2.4.12 L̲S̲L̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
Delete calls for subdevices namely
RELEASE ̲INPUT ̲B
RESERVE ̲OUTPUT ̲BUFFER
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER
RELEASE ̲OUTPUT ̲BUFFER
TRANSMIT ̲OUTPUT ̲BUFFER
WANT ̲TO ̲CLOSE
and following
CLEAN ̲SUBDEVICES
INITIALIZE ̲SUBDEVICE ̲INTERFACE
4.2.2.4.13 L̲S̲L̲ ̲E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.1
Modify such that call to
OPEN ̲SUBDEVICE is answerred with
CC = NOT ̲IMPLEMENTED
Delete call to
OPEN ̲SUBDEVICE
4.2.2.4.14 L̲S̲L̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲M̲o̲d̲u̲l̲e̲
4.2.2.4.14.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module allows return of interrupts (buffers) received
from the LTUX to the synchronization element specified.
4.2.2.4.14.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The module has an functional entry
NOTIFY ̲INTERRUPT(BUFFER ̲ENTRY: POINTER)( )
and two for init/delete
INITIALIZE ̲PROTOCOL ̲DATA(PARAM: OPEN ̲SUB-
DEVICE ̲PARAM)( )
CLEAN ̲PROTOCOL ̲DATA( )( )
4.2.2.4.14.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
NOTIFY ̲INTERRUPT
INITIALIZE ̲PROTOCOL ̲DATA
CLEAN ̲PROTOCOL ̲DATA
4.2.2.4.14.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer section 4.2.2.7 for the Low Speed Line interrupts
Loads SDID record STATUS ̲REPORT
4.2.2.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Refer 4.1.4.3 IOC handler data
4.2.2.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
None
4.2.2.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The VDU split protocols interface to the Format
Handler as described in 4.2.1.7.
All handlers interface to the LTUX function subpackage
as specified below.
L̲T̲U̲X̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲-̲ ̲L̲T̲U̲X̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲ ̲s̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲.̲
The interface is as specified in TDX handler
based on the LDU concept.
1. byte specifies CONTROL or DATA plus
START ̲OF ̲LDU, END ̲OF ̲LDU,
PART ̲OF ̲LDU, ENTIRE ̲LDU
For DATA the second byte in the first buffer
of an LDU gives the LDU sequence number.
For CONTROL outgoing the second byte gives the
control type:
INPUT ̲REQUEST, CANCEL ̲INPUT ̲REQUEST, CANCEL ̲OUTPUT,
REPORT ̲STATUS ̲REQUEST, OPEN ̲CHANNEL, CLOSE ̲CHANNEL.
For incoming CONTROL (also called STATUS) the
second byte gives the STATUS type
TRANSMISSION ̲STATUS, RECEPTION ̲STATUS,
INTERRUPT( A synchronous report), PROTOCOL ̲STATUS
Data input/output is performed with the standard
requests as follows:
I̲n̲p̲u̲t̲
INPUT ̲REQUEST has following format
1.-2. byte Standard
3. byte LDU identification for
input
4. and following Device depended
VDU 4. byte - N. byte (N is at most 25)
ARM command for VDU
other None
CANCEL ̲INPUT ̲REQUEST
1.-2. byte Standard
3. byte LDU to be cancelled
Input data is transferred in LDU's consisting of buffers
of type.
START ̲OF ̲LDU, PART ̲OF ̲LDU, END ̲OF ̲LDU or ENTIRE ̲LDU.
END ̲OF ̲LDU or ENTIRE ̲LDU means that the LDU has been
read with no error. If an error occurs these types
are not returned, but the LTUX returns (after last
good data) an
RECEPTION ̲STATUS with following format:
1.-2. byte Standard
3. byte LDU identification
4. byte Completion code:
CANCELLED,
DEVICE ̲STATUS ̲ERROR,
DEVICE ̲ERROR
PARITY ̲ERROR,
TIME ̲OUT
SOTF ̲INTERRUPTION
For each handler the input interface specification
are:
V̲D̲U̲
LDU's are normally terminated when the ARM of the Input
Request is completed. LDU's are abnormally terminated
on Cancel, any abnormal reception (time-out + retry
count) and any device failure (106, 107 drops with
timeout or retransmission error.
The IOC records are normally of type with FLAG ̲BYTE
=
LINE ̲FLAG generated from the field separators. For
the case of oversized fields DATA ̲FLAG is generated.
O̲C̲R̲
LDU's are normally terminated by ETX Abnormal termination
by transmission error, multiple STX, Cancel and any
device failure (106, 107 off with timeout)
IOC records are of type LINE ̲FLAG, DATA ̲FLAG or
CONTROL ̲FLAG.
T̲R̲C̲ ̲T̲P̲
LDU's are normally terminated on reception of "NNN"
in the beginning of a line (and includes the full line).
Abnormal termination is on cancel, Halted Message timeout,
dual occurrence of Start of Transmisson Function (and
parity error if so specified).
IOC records are of type LINE ̲FLAG, DATA ̲FLAG or
CONTROL ̲FLAG.
P̲T̲P̲ ̲P̲T̲R̲
Termination is TBD
IOC records are generated as of TRC ̲TP.
O̲U̲T̲P̲U̲T̲
Output data is transferred in LDU's consisting of buffer
types
START ̲OF ̲LDU, PART ̲OF ̲LDU, END ̲OF ̲LDU and
ENTIRE ̲LDU
The output data is either straight for output (when
CONVERTER ̲STATE = OFF) or recorded in IOC records (when
CONVERTER ̲STATE = ON)
The output is completed by the LTUX returning an TRANSMISSION
̲STATUS to the handler
1.-2. byte Standard
3. byte LDU
4. byte Completion Code
OK, CANCELLED
DEVICE ̲STATUS ̲ERROR
DEVICE ̲FAILURE,
BAD ̲DATA
The codes may in general occur as follows:
CANCELLED when cancel requested
DEVICE ̲STATUS ̲ERROR e.g. paperout on MSTP.
DEVICE ̲ERROR
The state of the protocol is not running possibly due
to timeout on 106, 107, or due to VDU retransmission
count overrun.
ILLEGAL ̲DATA
The occurrence of control characters in output records
of type DATA ̲FLAG or LINE ̲FLAG
The specialities for each device are
V̲D̲U̲
LINE ̲FLAG records converted to Data output, Clear to
end of field, TAB.
Each output is on a IOC record boundary.
M̲S̲T̲P̲
An output LDU needs not to be on a IOC record boundary
Conversion of LINE ̲FLAG records to "CR, CR, LF"
T̲R̲C̲ ̲T̲P̲
An output LDU needs not to be on IOC record boundary
Conversion of LINE ̲FLAG records to "CR, CR, CF"
C̲O̲N̲T̲R̲O̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
Commands to the LTUX
ENABLE
1.- 2. byte Standard
3. byte Identifier
4. byte Command Code = ENABLE
5.-16. byte Level 1 parameters
5. byte MODE (= DTE)
6.-10. byte Parameters for selected
mode
6. byte USE ̲105 ̲106
7. byte TIME ̲OUT ̲106
8. byte USE ̲108 ̲107
9. byte TIME ̲OUT ̲107
10. byte Spare
11.-16. byte Other level 1
11. byte LTUX ̲BAUDRATE
12. byte STOP ̲BITS
13. byte PARITY
14. byte CHAR ̲SIZE
15.-16. byte Spare
17.- ? byte Level 2 parameters
17. byte L2 ̲PROTOCOL
18.-23. byte Protocol parameters
For VDU PROTOCOL:
18. byte Retransmission count for
output/input before failure
0-10
19. byte Key Status request repeat
rate
1..255 seconds
(When VDU is idle)
20.-21. byte Spare
22. byte Max record length (characters)
23. byte CONVERTER ̲STATE
For OCR PROTOCOL
18. byte Retransmission count for
NAK
19. byte NAK delay 1..255 seconds
20.-21. byte Spare
22. byte Max record length
23. byte CONVERTER ̲STATE
For MSTP ̲PROTOCOL
18. byte Spare
19. byte Status request repeat rate
(1..255 seconds)
(when no LDU in output)
20.-22. byte Spare
23. byte CONVERTER ̲STATE
For TRC ̲TP PROTOCOL
18. byte ALPHABET
19. byte Halted Message Timeout
1..255 seconds
20. byte Parity error replace character
21. byte Spare
22. byte Max record length
23. byte CONVERTER ̲STATE
For PTP ̲PTR PROTOCOL
18.-21. byte TBD
22. byte Max record length
23. byte CONVERTER ̲STATE
OPEN ̲PROTOCOL
1.- 2. byte Standard
3. byte Identifier
4. byte OPEN ̲PROTOCOL
Open means: Setup interface lines according to ENABLE,
wait for 106, 107 if included (DTE). Furthermore for
VDU attempt to set VDU in block mode and request status
(error if status not available).
Furthermore for MSTP attempt to request status (error
if status not available).
During OPEN ̲PROTOCOL, CLOSE ̲PROTOCOL is accepted by
the LTUX.
CLOSE ̲PROTOCOL
1.- 2. byte Standard
3. byte Identifier
4. byte CLOSE ̲PROTOCOL
Takes down V24 as opposed to OPEN ̲PROTOCOL
REDEFINE ̲PARAMS
1.- 2. byte Standard
3. byte Identifier
4. byte REDEFINE ̲PARAMS
5. byte CONVERTER ̲STATE
STATISTICS
1.- 2. byte Standard
3. byte Identifier
4. byte STATISTICS
All statistics are collected in 16 bit counters and
reset upon request.
For all DTE protocols following can be requested:
Number of 106 drops (if included)
Number of 107 drops (if included)
For VDU
Number of transmitted blocks
Number of retransmitted blocks
Number of correctly received blocks
Number of NACKed blocks
Number of transmitted status requests
For OCR
Number of received blocks
Number of NACK's transmitted
For MSTP
Number of transmitted status requests
For TRC ̲TP
Number of characters received with parity error
For PTP ̲PTR
TBD…86…1 …02… …02… …02… …02… …02…
STATUS
1.- 2. byte Standard
3. byte Identifier
4. byte STATUS
STATUS may be requested any time
DEVICE ̲STATUS
1.- 2. byte Standard
3. byte Identifier
4. byte DEVICE ̲STATUS
The DEVICE ̲STATUS is only relevant when PROTOCOL ̲STATE
= RUNNING
and only for VDU, MSTP and PTP ̲PTR Protocols.
Responses to commands ("Channel Status")
ENABLE response
1.- 2. byte Standard
3. byte Identifier (as of ENABLE)
4. byte ENABLE
5. byte = 0 OK
Else error
OPEN ̲PROTOCOL response
1.- 2. byte Standard
3. byte Identifier (as of OPEN ̲PRO-
TOCOL)
4. byte OPEN ̲PROTOCOL
5. byte = 0 OK
= 1 Close during open
T1 other error
CLOSE ̲PROTOCOL response
1.- 2. byte Standard
3. byte Identifier (as of CLOSE ̲PRO-
TOCOL)
4. byte CLOSE ̲PROTOCOL
5. byte = 0 OK
REDEFINE ̲PARAMS response
1.- 2. byte Standard
3. byte Identifier
4. byte REDEFINE ̲PARAMS
5. byte = 0 OK
STATISTICS response
1.- 2. byte Standard
3. byte Identifier
4. byte STATISTICS
5.- 6. byte = 0
7.- 8. byte No of 106 drops
9.-10. byte No of 107 drops
For VDU
11.-12. byte No of tr. blocks
13.-14. byte No of retr. blocks
15.-16. byte No of corr. r. blocks
17.-18. byte No of NACKed blocks
19.-20. byte No of tr. status requests
For OCR
11.-12. byte No of received blocks
13.-14. length No of transmitted Nack
For MTSP
11.-12. byte No of tr. status req
For TRC ̲TP
11.-12. byte No of ch. r. w. parity error
For PTP ̲PTR
TBD
STATUS response
1.- 2. byte Standard
3. byte Identifier
4. byte STATUS
5. byte = 0
6. byte PROTOCOL ̲STATE
7. byte CONVERTER ̲STATE
8. byte Spare
9. byte S 105 = (OFF, ON)
10. byte S 106 = (OFF, ON)
11. byte S 107 = (OFF, ON)
12. byte S 108 = (OFF, ON)
DEVICE ̲STATUS response
1.- 2. byte Standard
3. byte Identifier
4. byte DEVICE ̲STATUS
5. byte = 0 OK
= 1 Protocol not RUNNING
6. byte State (see below)
VDU keylock status
0 no key locked
1 software key locked
2 hardware key locked
3 both keys locked
MSTP keylock, paper and audio alarm status
0 status all off
1 key locked
2 audio alarm
4 paper out
Status summed to give combined status.
Asynchronous reports
General format
1. byte Control, Entire LDU
2. byte INTERRUPT
3. byte Code (see below)
4. byte Data (if any, code depended)
General interrupts (only in state RUNNING)
Code IT ̲DEVICE ̲FAILURE A serious error on device
interface bringing the interface
from state RUNNING to state
ENABLED
4. byte Error Code
DROP ̲106, DROP ̲107,
OUT ̲RETRANSMISSION, IN ̲RE-
TRANSMISSION
UNEXPECTED ̲CONTROL ̲CHAR ̲SEQUENCE
Specific interrupts
V̲D̲U̲ 3. byte IT ̲VDU
VDU interrupts A, E, F, T are returned to VDU handler
with no processing by LTUX:
4. byte = (ITA, ITE, ITF, ITT)
5. byte ITF: The code of PF key
ITT: 1. character of key
code
6. byte ITT: 2. character of key
code
VDU interrupt C, M, P, Z are considered fatal
(IT ̲DEVICE ̲FAILURE)
VDU interrupts L: Any change of hardware state is reported
as follows:
4. byte ITL
5. byte state (OFF, ON)
VDU interrupt R (see input completion codes)
VDU interrupt S is processed locally in LTUX, may lead
to a IT ̲DEVICE ̲FAILURE
M̲S̲T̲P̲ 3. byte IT ̲MSTP
Error codes from printer
4. byte ITE
5. byte the code (Hex 10, 20, 40)
Rub-out + status: Change of status on printer is reporter
as follows:
When keylock goes on or off
4. byte ITL
5. byte (OFF, ON)
When paperout goes on or off
4. byte ITP
5. byte (OFF, ON)
When audion alarm goes on
4. byte ITA
4.2.3 L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.3.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲
The LTU Handler Subpackage implements the definition
of terminals in DAMOS TMS sense for the NICS TARE interface
and the CCIS/SCARS interface.
Furthermore, the LTU Handler performs the generation
of data records (see section 4.1.7) from incoming characters
and converts from data records for outgoing characters.
Figs. 4.2.3.1.1-1 through 9 present the functional
breakdown.
Figure 4.2.3.1.1-1
Fra Figure 4.2.3.1.1-2 - Fig. 4.2.3.1.1-9
4.2.3.1.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The Control Functions are Handler Control interface
from TMS including requests for data transfer.
The NICS ̲TARE interface is defined as two high level
protocols (terminals), one for data and one for Acknowledges,
where the CCIS/SCARS interface is defined as one terminal.
Message handling - the NICS ̲TARE interface to the LTU
is on a segment basis. For outgoing, characters are
collected into segments for transmission, after conversion
of format. Segment size = 512 bytes. For incoming,
the segments are set for conversion and assembled into
messages. The first data returned to the requestor
contains a start of message record, the last an end
of message record.
The CCIS/SCARS interface to the LTU is a data block
interface, where each data block contains an identification
of the transferred message. If the identification changes
in the middle of a message, further input is skipped
and the input requestor notified.
For outgoing CCIS/SCARS, each created data block is
headed by the identification forwarded to the Handler
by the first record of the output.
Data Format Control - the internal CAMPS format of
data is a record format, where each line consists of
a header + data. The external data is not recorded
but can be seen as a continuous data string. The task
of the Format Control is to provide the conversion
to/from the internal CAMPS format.
The record types are for message data type 0,1,4 and
for start and end type 5 and 6. They are all described
in section 4.1.7.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The LTU Handler is to be seen as two handlers with
a set of shared procedures.
The NICS ̲TARE Handler consists of 2 protocols.
NICS ̲TARE Protocol with following modules:
NT ̲SUBDEVICE ̲INTERFACE module
NT ̲SPI ̲Module
NT ̲EHP ̲Module
NT ̲INPUT ̲CONVERTER module
NT ̲OUTPUT ̲CONVERTER module
NT ̲PROTOCOL module
NT ̲DATA protocol is equivalent to the VDU ̲CONTROL ̲SPLIT.
The NT ̲DATA protocol implements both subdevices, The
normal data and Acknowledge.
The CCIS/SCARS Handler consists of one protocol, the
CS protocol with following modules:
CS ̲USER ̲INTERFACE module
CS ̲SPI module
CS ̲EHP module
CS ̲INPUT ̲CONVERTER module
CS ̲OUTPUT ̲CONVERTER module
CS ̲PROTOCOL module
4.2.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The general data flow/control flow for the two handlers
is shown in figure 4.2.3.3-1 and is as follows:
For output, the handler works with two buffer types.
One is the handler buffer. It must be located within
the memory space accessible by the CPUs, which means
it must be within the PU or within the LTU. (The actual
location is within the LTU provided the LTU memory
budget allows. If not sufficient space, it is within
the PU). The other is the LTU buffer. It must be located
in the LTU and is accessible by the LTU microprocessor
and the handler.
When by conversion, the LTU buffer is full (either
NICS ̲TARE segment or CCIS/SCARS data block) the address
is handed to the LTU microprocessor, which will output
the data. When the handler buffer has been emptied
and there are more pending requests, it is returned
asynchronously to TMS.
If at a TMS output request a buffer is free, it is
immediately returned.
FIGURE 4.2.3.3-1
The input processing is quite similar.
The LTU interrupts the handler with an address of a
full buffer (located in the LTU). The handler converts
the data from the LTU buffer to the handler buffer.
When either the TMS request has been fulfilled (the
application buffer is to be full) or an end of message
or irrecoverable error has occured, the input buffer
is returned to TMS. When the LTU buffer is emptied,
an acknowledgement is returned to the LTU.
4.2.3.3.1 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲F̲l̲o̲w̲
In addition to the described flow above, the NICS ̲TARE
Handler provides a second terminal for transfer of
Acknowledges. Whenever an acknowledge is requested
transmitted, the NICS ̲TARE Handler releases acknowledge
for end of message segment.
The Flow on a module level is shown in fig 4.2.3.3-2
The 3 subdevices to the NT ̲PROTOCOL are all created
with the same protocol so only the subdevice address
determines the usage.
4.2.3.3.2 C̲C̲I̲S̲/̲S̲C̲A̲R̲S̲ ̲F̲l̲o̲w̲
In addition to the general processing in section 4.2.3.3,
the output processing for CCIS/SCARS contains the following
:
The message type and precedence are stripped off the
application output request and added to the beginning
of each LTU buffer output for this message.
For input, the incoming buffers contain the message
type and precedence. If these values do not fit with
the message in processing, the input request is terminated
with an error code and subsequent data blocks skipped
until next start of message.
The flow on a module level is shown on fig 4.2.3.3-3
Figure 4.2.3.3-2…86…1 …02… …02… …02… …02…
Figure 4.2.3.3-3…86…1 …02… …02… …02… …02…
4.2.3.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
All modules in the LTU HANDLER subpackage except for
the PROTOCOL modules of each protocol and the INPUT
̲CONVERTER and OUTPUT ̲CONVERTER modules are specified
relative to the standard protocol modules described
in section 4.1.5 of this document. This way of documenting
the design is used in order to avoid duplication af
large amount of information.
4.2.3.4.1 N̲T̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
4.2.3.4.2 N̲T̲ ̲E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.1
Modify such that TMS calls to
ENABLE ̲INPUT
GET ̲OUTPUT ̲BUFFER
are returned with CC = NOT ̲IMPLEMENTED
Delete calls to
CANCEL ̲USER ̲OPERATION
USER ̲OUTPUT
ACK ̲DATA ̲INPUT
ENABLE ̲INPUT
GET ̲OUTPUT ̲BUFFER
4.2.3.4.3 N̲T̲ ̲S̲u̲b̲d̲e̲v̲i̲c̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.7
The procedure LOAD ̲INPUT ̲REQUEST is not implemented.
4.2.3.4.4 N̲T̲ ̲I̲N̲P̲U̲T̲ ̲C̲O̲N̲V̲E̲R̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
4.2.3.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The NT INPUT CONVERTER module converts the incoming
data into IOC records used internally in CAMPS. This
means put lines into separate IOC records based on:
- "CR, CR, LF" or "CR, LF" terminates a normal line
and marks the IOC record with LINE ̲FLAG
- More than 69 data characters lead to a termination
of the 69 characters in a record marked DATA ̲FLAG
- Encountered SI, SO are ignored (does not count)
- Other control characters make the record in collection
be terminated with DATA ̲FLAG and the control characters
be collected in a record marked CONTROL ̲FLAG
4.2.3.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The module has following functional entries
M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
INITIALIZE ̲CONVERT ̲INPUTTER (PARAM: OPEN ̲SUBDEVICE
̲
PARAM)
()
CLEAN ̲CONVERT ̲INPUTTER () ()
REQUEST ̲DATA ̲INPUT (QEL: IO ̲QEL, PRIORITY:PRIORITY
̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER ̲REF:
POINTER)
SEND ̲INPUT ̲REQUEST (SIZE: INTEGER) ()
RELEASE ̲INPUT ̲BUFFER (BUFFER ̲ENTRY: POINTER) ()
NOTIFY ̲INPUTTER ̲OUTPUT ̲BUFFER (BUFFER ̲ENTRY: POINTER)
()
NOTIFY ̲INPUTTER ̲FIRST ̲INPUT ̲DATA (QEL: IO ̲QEL,
(BUFFER ̲ENTRY: POINTER)
()
NOTIFY ̲INPUTTER ̲INPUT ̲REQUEST ̲BUFFER (QEL: IO ̲QEL,
(BUFFER ̲ENTRY: POINTER)
()
NOTIFY ̲INPUTTER ̲INPUT ̲RESULT (QEL: IO ̲QEL, BUFFER ̲ENTRY:
POINTER) ()
CANCEL ̲INPUT (QEL: IO ̲QEL) ()
ACKNOWLEDGE ̲INPUT () (CC: COMPLETION ̲CODE)
The module calls following functional entries of other
modules:
RELEASE ̲INPUT ̲BUFFER (BUFFER ̲REL ̲POINTER) ()
SEND ̲INPUT ̲REQUEST (SIZE: INTEGER) ()
REQUEST ̲DATA ̲INPUT (QEL: IO ̲QEL, PRIORITY: PRIORITY
̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER ̲REF: POINTER)
CANCEL ̲INPUT (QEL: IO ̲QEL) ()
RELEASE ̲ERROR ̲BUFFER (BUFFER ̲ENTRY:POINTER) ()
NOTIFY ̲SUBDEVICE ̲INPUT ̲RESULT (QEL: IO ̲QEL,
(BUFFER ̲ENTRY: POINTER) ()
NOTIFY ̲SUBDEVICE ̲INPUT ̲REQUEST ̲BUFFER (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ()
NOTIFY ̲SUBDEVICE ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ()
NOTIFY ̲SUBDEVICE ̲FIRST ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ()
Furthermore:
PROTOCOL ̲ERROR
ACTIVATE ̲SPI
INIT ̲BUFFER ̲ENTRY
INIT ̲QEL
QUEUE
QUEUE ̲PRIORITIZED
EXTRACT ̲FIRST
EXTRACT ̲SPECIFIED
INSERT
M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
E̲n̲t̲r̲y̲ ̲P̲o̲i̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
B̲a̲s̲i̲c̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
INITIALIZE ̲CONVERT-INPUTTER
CLEAN ̲CONVERT-INPUTTER
R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲DATA ̲INPUT
SEND ̲INPUT ̲REQUEST
CANCEL ̲INPUT
ACKNOWLEDGEMENT
RELEASE ̲INPUT ̲BUFFER
N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲INPUTTER ̲OUTPUT ̲BUFFER
NOTIFY ̲INPUTTER ̲INPUT RESULT
NOTIFY ̲INPUTTER ̲INPUT ̲REQUEST ̲BUFFER
NOTIFY ̲INPUTTER ̲FIRST ̲INPUT ̲DATA
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
C̲o̲n̲v̲e̲r̲t̲e̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
INITIALIZE ̲CONVERTION
START ̲CONVERTION
CONVERT
END ̲CONVERTION
DO ̲CONVERT
DATA ̲SCAN
CONTROL ̲SCAN
CHARACTER ̲TEST
DO ̲EMPTY ̲STACK
INITIALIZE ̲BUFFER
I̲n̲p̲u̲t̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
PROCESS ̲NEXT ̲REQUEST
REQUEST ̲NEW ̲DATA
RELEASE ̲INPUT ̲DATA
SEND ̲ACKNOWLEDGE
GET ̲NEXT ̲SOM ̲BUFFER
GET ̲NEXT ̲I ̲BUFFER
R̲e̲q̲u̲e̲s̲t̲o̲r̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
RETURN ̲INPUT ̲DATA
E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
PROCESS ̲ERROR
PROCESS ̲ERROR ̲BUFFER
C̲a̲n̲c̲e̲l̲ ̲S̲u̲p̲p̲o̲r̲t̲
CANCEL ̲PENDING
CANCEL ̲ONGOING
4.2.3.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
4.2.3.4.5 N̲T̲ ̲O̲U̲T̲P̲U̲T̲ ̲C̲O̲N̲V̲E̲R̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
4.2.3.4.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module converts the IOC records received from
the application into segments for transmission over
the NT link.
Segments are generated as entire ̲LDU's and always filled
to the size of 512 bytes except for the last segment
of a message.
4.2.3.4.5.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The NT ̲OUTPUT ̲CONVERTER module is interfaced via following
calls
4.2.3.4.5.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
INITIALIZE ̲CONVERT ̲OUTPUTTER (PARAM: OPEN ̲SUBDEVICE
̲
PARAM) ()
CLEAN ̲CONVERT ̲OUTPUTTER () ()
REQUEST ̲DATA ̲OUTPUT (QEL: IO ̲QEL, PRIORITY: PRIORITY
̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER ̲REF: POINTER)
REQUEST ̲NEXT ̲BUFFER () (CC: COMPLETION ̲CODE, BUFFER
̲REF:
POINTER)
SEND ̲OUTPUT ̲BUFFER (BYTE ̲COUNT, INTEGER, TYPE: BUFFER
̲
TYPE) ()
NOTIFY ̲OUTPUTTER ̲FIRST ̲BUFFER (QEL: IO ̲QEL, BUFFER
̲REF:
POINTER) ()
NOTIFY ̲OUTPUTTER ̲SUBSEQUENT ̲BUFFER (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER) ()
NOTIFY ̲OUTPUTTER ̲OUTPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲REF:
POINTER) ()
CANCEL ̲OUTPUT (QEL: IO ̲QEL) ()
RELEASE ̲ERROR ̲BUFFER (BUFFER ̲REF: POINTER) ()
The module calls following functional entries of other
modules:
RELEASE ̲INPUT ̲BUFFER (BUFFER ̲REF: POINTER)()
REQUEST ̲DATA ̲OUTPUT (QEL: IO ̲QEL, PRIORITY:
PRIORITY ̲TYPE)
(CC: COMPLETION CODE, BUFFER ̲REF: POINTER)
SEND ̲OUTPUT ̲BUFFER (BYTE ̲COUNT: INTEGER, TYPE:
BUFFER ̲TYPE) ()
CANCEL ̲OUTPUT (QEL: IO ̲QEL) ()
NOTIFY ̲SUBDEVICE ̲FIRST ̲OUTPUT ̲BUFFER (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER) ()
NOTIFY ̲SUBDEVICE ̲SUBSEQUENT ̲OUTPUT ̲BUFFER (QEL: IO
̲QEL,
BUFFER ̲REF: POINTER) ()
NOTIFY ̲SUBDEVICE ̲OUTPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲REF:
POINTER) ()
Furthermore:
PROTOCOL ̲ERROR
INIT ̲BUFFER ̲ENTRY
INIT ̲QEL
QUEUE
QUEUE ̲PRIORITIZED
EXTRACT ̲SPECIFIED
EXTRACT ̲FIRST
M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
E̲n̲t̲r̲y̲ ̲P̲o̲i̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
B̲a̲s̲i̲c̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
INITIALIZE ̲CONVERT-OUTPUTTER
CLEAN ̲CONVERT-OUTPUTTER
R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲DATA ̲OUTPUT
REQUEST ̲NEXT ̲BUFFER
SEND ̲OUTPUT ̲BUFFER
CANCEL ̲OUTPUT
RELEASE ̲ERROR ̲BUFFER
N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲OUTPUTTER ̲FIRST ̲OUTPUT ̲BUFFER
NOTIFY ̲OUTPUTTER ̲SUBSEQUENT ̲OUTPUT BUFFER
NOTIFY ̲OUTPUTTER ̲OUTPUT ̲RESULT
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
C̲o̲n̲v̲e̲r̲t̲e̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
INITIALIZE ̲CONVERTION
START ̲CONVERTION
CONVERT
END ̲CONVERTION
END ̲LINE ̲ACTION
GET ̲HEAD
O̲u̲t̲p̲u̲t̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
PROCESS ̲NEXT ̲CONVERTION
NEXT ̲CONVERT ̲OUTPUT
REQUEST ̲OUTPUT ̲BUFFER
NEXT ̲CONVERTION
T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
PROCESS ̲FULL
PROCESS ̲COM
PROCESS ̲ERROR
PROCESS ̲EMPTY
4.2.3.4.6 N̲T̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲M̲o̲d̲u̲l̲e̲
4.2.3.4.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module hands an asynchronous report to the SSC.
4.2.3.4.6.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The module has one functional entry
NOTIFY ̲INTERRUPT (BUFFER ̲ENTRY: POINTER) ( )
and two for INIT/DELETE
INITIALIZE ̲PROTOCOL ̲DATA (PARAM: OPEN ̲SUBDEVICE ̲PARAM)()
CLEAN ̲PROTOCOL ̲DATA\( ) ( )
4.2.3.4.6.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
NOTIFY ̲INTERRUPT
INITIALIZE ̲PROTOCOL ̲DATA
CLEAN ̲PROTOCOL ̲DATA
4.2.3.4.7 N̲T̲ ̲D̲A̲T̲A̲ ̲U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.5
4.2.3.4.8 N̲T̲ ̲D̲A̲T̲A̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
Delete calls to
CLEAN ̲SUBDEVICES
CLEAN ̲PROT ̲CONT
CLEAN ̲CONTROLLER
CLEAN ̲PROTOCOL ̲DATA
NOTIFY ̲PROT ̲CONT ̲OUTPUT ̲BUFFER
NOTIFY ̲PROT ̲CONT ̲OF ̲RESPONSE
NOTIFY ̲INTERRUPT
INITIALIZE ̲CONTROLLER
INITIALIZE ̲SUBDEVICE ̲INTERFACE
INITIALIZE ̲PROT ̲CONT
INITIALIZE ̲PROTOCOL ̲DATA
RELEASE ̲INPUT ̲BUFFER
RESERVE ̲OUTPUT ̲BUFFER
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER
RELEASE ̲OUTPUT ̲BUFFER
TRANSMIT ̲OUTPUT ̲BUFFER
WANT ̲TO ̲CLOSE
4.2.3.4.9 N̲T̲ ̲D̲A̲T̲A̲ ̲E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.1
Modify such that calls to
OPEN ̲SUBDEVICE, ENABLE ̲CONTROL ̲INPUT,
GET ̲CONTROL ̲BUFFER are answered with
CC = NOT ̲IMPLEMENTED
Delete calls to
OPEN ̲SUBDEVICE
ENABLE ̲CONTROL ̲INPUT
GET ̲CONTROL ̲BUFFER
ACK ̲CONTROL ̲INPUT
CONTROLLER ̲OUTPUT
CANCEL ̲CONTROLLER ̲OPERATION
4.2.3.4.10 C̲S̲ ̲U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.5
Modify so that input and output passes CS ̲INPUT ̲CONVERTER
and CS ̲OUTPUT ̲ CONVERTER modules respectively.
4.2.3.4.11 C̲S̲ ̲S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.2
Delete calls to
CLEAN ̲SUBDEVICES
INITIALIZE ̲SUBDEVICE ̲INTERFACE
RELEASE ̲INPUT ̲B
RESERVE ̲OUTPUT ̲BUFFER
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER
RELEASE ̲OUTPUT ̲BUFFER
TRANSMIT ̲OUTPUT ̲BUFFER
WANT ̲TO ̲CLOSE
4.2.3.4.12 C̲S̲ ̲E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
Refer 4.1.5.1
Modify sent that call to
OPEN ̲SUBDEVICE is answered CC = NOT ̲IMPLEMENTED
Delete call to
OPEN ̲SUBDEVICE
4.2.3.4.13 C̲S̲ ̲I̲N̲P̲U̲T̲ ̲C̲O̲N̲V̲E̲R̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
Refer NT INPUT CONVERTER MODULE 4.2.3.4.8.
Modify interface to access USER INTERFACE instead of
SUBDEVICE INTERFACE, and do not use Acknowledge.
4.2.3.4.14 C̲S̲ ̲O̲U̲T̲P̲U̲T̲ ̲C̲O̲N̲V̲E̲R̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
Refer NT OUTPUT CONVERTER module 4.2.3.4.9.
Modify interface to USER INTERFACE instead of
SUBDEVICE INTERFACE
4.2.3.4.15 C̲S̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲M̲o̲d̲u̲l̲e̲
4.2.3.4.15.1 F̲u̲n̲c̲t̲i̲o̲n̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module hands an asynchronous report to the SSC.
4.2.3.4.15.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The module has one functional entry
NOTIFY ̲INTERRUPT (BUFFER ̲ENTRY: POINTER) ( )
and two for init/delete
INITIALIZE ̲PROTOCOL ̲DATA (PARAM: OPEN ̲SUBDEVICE ̲PARAM)(
)
CLEAN ̲PROTOCOL ̲DATA ( ) ( )
4.2.3.4.15.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
NOTIFY ̲INTERRUPT
INITIALIZE ̲PROTOCOL ̲DATA
CLEAN ̲PROTOCOL ̲DATA
4.2.3.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Refer 4.1.4.3 IOC handler data
4.2.3.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
None
4.2.3.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The interface is described in separate
sections for
NICS-TARE LTU Functions Subpackage
CCIS-SCARS LTU Functions Subpackage
below.
4.2.3.7.1 L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲-̲ ̲N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲L̲T̲U̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲s̲
̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
H̲A̲N̲D̲L̲E̲R̲ ̲-̲ ̲L̲T̲U̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
The interface is via queues
Per NICS TARE channel one LTU-CR80D channel with a
control and a data subchannel is used.
The two Subchannels (Data and Status) are here defined
as Data Channel and as Control Channel and combined
with the direction, they are defined as:
DATA OUT
Direction: Handler
- LTU
CONTROL OUT
DATA IN Direction: LTU - Handler
CONTROL IN
Interfaces are defined according to CSS-MIC/040/FNC/0001.
It is specified by a number of parameters some according
to the common standard, some specific for this interface.
Although some parameters below are directly specified
as numbers, all constant parameters and error codes
are compile time constants with a describing name.
a) I̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲
An input request signals to the LTU, that the handler
is ready to receive a LDU of Data.
b) C̲a̲n̲c̲e̲l̲ ̲i̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲
Cancel specified input requests of DATA if pending.
c) C̲a̲n̲c̲e̲l̲ ̲o̲u̲t̲p̲u̲t̲
If a data buffer is still queued for the protocol
and transmission has not started a cancel shall
be as if the databuffer was never queued and a
response Transmission Cancelled returned.
d) R̲e̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲u̲s̲ ̲r̲e̲q̲u̲e̲s̲t̲
This command is used for command of protocol and
level 1 opening and closing.
Details below.
e) O̲p̲e̲n̲ ̲C̲h̲a̲n̲n̲e̲l̲
Used to enable the CR80-LTU interface. No parameters.
f) C̲l̲o̲s̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲
Used to disable the CR80-LTU interface.
B̲u̲f̲f̲e̲r̲s̲
Buffers for CONTROL and DATA are of the same size,
but the handler only use the part of the buffer specified
in the detailed interface below.
The LTU per channel supplies the handler with 3 buffers.
S̲e̲c̲u̲r̲i̲t̲y̲ ̲r̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲b̲u̲f̲f̲e̲r̲h̲a̲n̲d̲l̲i̲n̲g̲
The LTU overwrites databuffers for output after a successful
transmission. The LTU overwrites input data buffers
after they are returned to the LTU.
D̲A̲T̲A̲ ̲B̲U̲F̲F̲E̲R̲S̲
The interface data buffers are laid out as follows:
1.byte buffer type as of CSS-MIC/040/FNC/0001
section 3.1.2
bit 0,1 entire LDU
bit 2 transparent data
2.byte LDU sequence number
3.byte Segment-Type
4.byte =0 Spare
5 - 516 Data of one segment.
The length of the data is taken from the buffer-header.
For DATA OUT, the Handler will in most cases of type
Intermediate generate segments of 512 bytes. (For performance
estimates, it can be assumed, that the average length
of these types is at least 450.)
For DATA IN, the Handler accepts any length, but will
assume an average as above of at least 450.
The Segment-Type parameter defining the buffer as a
segment of
Intermediate segment of message = 0
Last segment of message = 1
LCB segment = 2
C̲O̲N̲T̲R̲O̲L̲ ̲B̲U̲F̲F̲E̲R̲S̲
The interface control buffers are laid out as follows:
1.byte Buffer type as of CSS-MIC/040/FNC/0001 section
3.1.2
2.byte Status type
For Control Out as defined in CSS-MIC/040/FNC/0001
section 3.1.2, where code 3: report status
request is reserved for general commands to
the protocol
3.byte through max. Parameters.
D̲e̲t̲a̲i̲l̲e̲d̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
D̲a̲t̲a̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲. The Data interface has already been
defined above except for acknowledge of input segments
(see below).
C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The Control interface is according to CSS-MIC/040/FNC/0001
for the outgoing control types.
Input request, Cancel input request, Cancel output,
Open channel and Close channel.
Commands to the protocol and level 1 are issued as
report status request with corresponding channel state
answers (see below).
For the incoming control types Transmission status
and Reception status the interface is as described
in CSS-MIC/040/FNC/0001. The Asyncronous Reports (interrupt)
are generated when asyncronous events occurs. Channel
Status are responses to commands to the protocol.
C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲ ̲(̲"̲r̲e̲p̲o̲r̲t̲ ̲s̲t̲a̲t̲u̲s̲ ̲r̲e̲q̲u̲e̲s̲t̲"̲)̲
E̲n̲a̲b̲l̲e̲ Level 1 is enabled
Protocol parameters defined
Parameters from handler:
1. - 2.byte Standard
3. byte Identifier
4. byte Command Code = 1 (ENABLE)
5. - 9.byte Level 1 parameters
5. byte Definition Local/Remote
Tare
= 0 Local Tare
= 1 Remote Tare
6. byte Baudrate
Hex 1 through 8 reserved
for 50 - 300 baud
Hex 9 600 baud
Hex A 1200 baud
Hex B 2400 baud
Hex C - Reserved
7. byte Level 1 timeout (Remote
Tare)
Specified in units
of 100 ms. 1 = 100
ms 255 = 25.5 seconds.
8. byte Retry count level 1
(Remote Tare).
Value 0 - 10.
9. byte Spare = 0
10. - 19 byte Level 2 parameters
10. byte Block size
0: 32 bytes
1: 64 bytes
2: 128 bytes
3: 256 bytes
4: 512 bytes
11. byte ACKTO Timeout in steps
of 100 ms
1 = 100 ms 255 = 25.5
seconds
12. byte ACKLTO Timeout in steps
of 100 ms
1 = 100 ms 255 = 25.5
seconds
13. byte Spare = 0
14. byte Max N count 1 - 99
15. byte Max L count 1 - 99
16. byte Max R count 1 - 99
17. - 19.byte Spare = 0
O̲p̲e̲n̲ ̲E̲D̲C̲ Correspond to open specified in SDS/006/section
4.1.3.6.3.4.
1. - 2.byte Standard
3. byte Identifier
4. byte Command Code = 2 (OPEN
̲EDC)
C̲L̲O̲S̲E̲ ̲E̲D̲C̲ Correspond to Close specified in SDS/006/section
4.1.3.6.3.4.
1. - 2. byte Standard
3. byte Identifier
4. byte Command Code = 3 (CLOSE
̲EDC)
R̲E̲D̲E̲F̲I̲N̲E̲ ̲E̲D̲C̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲ Redefines (also during
normal operation) the
EDC parameters.
1. - 2. byte Standard
3. byte Identifier
4. byte Command Code = 4 (REDEF
̲ EDC ̲PARAMS)
5. - 14.byte Correspond to byte
# 10 - 19 of the ENABLE
command.
C̲o̲l̲l̲e̲c̲t̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The EDC protocol and Level 1 shall maintain 16 bit
counters for
Number of successfully transmitted message blocks
Number of successfully transmitted LCB's
Number of received message blocks
Number of received LCB's
Number of retransmitted message blocks
Number of retransmitted LCB's
Number of transmitted RR blocks
Number of correctly received RR blocks
Number of sync retries on level 1 (Remote Tare)
Request format
1. - 2. byte Standard
3. byte Identifier
4. byte Command Code = 5 (STATISTICS)
The command shall read and reset the counters above.
P̲r̲o̲t̲o̲c̲o̲l̲ ̲s̲t̲a̲t̲u̲s̲ ̲+̲ ̲L̲e̲v̲e̲l̲ ̲1̲ ̲S̲t̲a̲t̲u̲s̲
This command requests the current state of the Protocol
and of Level 1.
1. - 2. byte Standard
3. byte Identifier
4. byte Command Code = 6 (EDC
̲STATUS)
A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲
The Handler acknowledges segments as received from
the EDC.
1. - 2. byte Standard
3. byte = 0
4. byte Command Code = 7 (Acknowledge)
5. byte LDU number of received
segment
No response on acknowledge.
R̲e̲s̲p̲o̲n̲s̲e̲s̲ ̲t̲o̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲(̲"̲c̲h̲a̲n̲n̲e̲l̲ ̲s̲t̲a̲t̲u̲s̲"̲)̲
E̲n̲a̲b̲l̲e̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲
1. - 2. byte Standard
3. byte The Identifier given
in enable
4. byte = Enable Command Code
5. byte = 0 Enable OK
0 (Erroneous parameter)
= 5 Unknown Tare type
= 6 Illegal Baud Rate
= 7 Level 1 retry
count out of range
= 8 Blocksize illegal
= 9 N count out range
= 10 L count out range
= 11 R count out range
O̲p̲e̲n̲ ̲E̲D̲C̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
1. - 2.byte Standard
3. byte The Identifier given
in Open EDC
4. byte Open EDC command code
5. byte = 0 Open EDC OK
0 error
1: Level 1 setup failed
2: Level 1 link failed
3: EDC irrecoverable
error during await
incoming startup
4: Close Command during
Open.
C̲l̲o̲s̲e̲ ̲E̲D̲C̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
1. - 2. byte Standard
3. byte The Identifier given
in CLOSE ̲EDC
4. byte CLOSE ̲EDC Command Code
5. byte = 0 Close OK.
R̲e̲d̲e̲f̲i̲n̲e̲ ̲E̲D̲C̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲
1. - 2. byte Standard
3. byte The Identifier
4. byte REDEF ̲EDC ̲PARAMS Command
Code
5. byte Error Code (See Enable
response)
C̲o̲l̲l̲e̲c̲t̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲
16 bit values are returned with the most significant
byte as higher numbered.
1. - 2. byte Standard
3. byte The Identifier
4. Byte STATISTICS Command
Code
5. - 6. byte = 0
7. - 8. byte Transmitted message
blocks
9. - 10 byte Transmitted LCB's
11. - 12 byte Received message blocks
13. - 14 byte Received LCB's
15. - 16 byte Retransmitted message
blocks
17. - 18 byte Retransmitted LCB's
19. - 20 byte Transmitted RR blocks
21. - 22 byte Received RR blocks
23. - 24 Level 1 retry count
P̲r̲o̲t̲o̲c̲o̲l̲ ̲S̲t̲a̲t̲u̲s̲ ̲+̲ ̲L̲e̲v̲e̲l̲ ̲1̲ ̲S̲t̲a̲t̲u̲s̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲
1. - 2 byte Standard
3. byte The Identifier
4. byte EDC ̲STATUS Command
Code
5. byte = 0
6. byte Level 1 status
State Numbers as of
SDS/006/4.1.3.6.3.2
for Remote Tare with
0: Not enabled
or
State numbers as of
SDS/006/4.1.3.6.3.1
for Local Tare
0: Not enabled
1: Enabled
2: Setting Up
3: Running
4: Clearing Down
7. byte EDC states
0: Disabled
Others as of CPS/SDS/006
section 4.1.3.6.3.4
S̲t̲a̲n̲d̲a̲r̲d̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲s̲
Transmission status
TX-error 2: Link failed
Reception status
1: Input request cancelled
by command
2: Input request cancelled
due to EDC reset or
Close.
A̲s̲y̲n̲c̲r̲o̲n̲o̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲ ̲f̲r̲o̲m̲ ̲E̲D̲C̲ ̲+̲ ̲L̲e̲v̲e̲l̲ ̲1̲
General format
1. byte Standard
2. byte 2: Asyncroneous Report
3. byte Code
2: Link Failure
12: EDC Failure (irrecoverable
error)
13: Manual Sync
14: Incoming reset (Set
B received)
These reports are generated as specified in SDS/006/
section 4.1.3.6.3.1 through 4.1.3.6.3.4.
The Incoming reset is reported in all cases except
open EDC and has the effect that all input requests
for the manual are cleared with code "EDC reset or
Close" cancelled (=2).
4.2.3.7.2 L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲C̲C̲I̲S̲/̲S̲C̲A̲R̲S̲ ̲L̲T̲U̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲
̲S̲U̲B̲P̲A̲C̲K̲A̲G̲E̲
I̲n̲t̲e̲r̲f̲a̲c̲e̲
The CR80 I/F-table is organized like this (see also
CSS-MIC/040/FNC/0001):
Channel 0: Debug communication between
line handler and LTU
Channel 1: General purpose LTU configuration
communication
Channel 3: Logical channel 1
Channel 5: Logical channel 2
The following control commands are implemented:
REOPEN: Change parameters in protocol
SET ̲UP ̲LINK: Connect protocol level 2
DISC ̲LINK: Disconnect protocol level 2
SET ̲UP ̲LINES: Set up statuslines according to X21 bis
DISC ̲LINES: Disconnect statuslines according to X21
bis
SET ̲V24: Set specified circuit on optional V24-connector
(2)
The following status commands are implemented:
READ ̲V24: Read specified circuit on optional V24-connector
(2)
STATISTIC: Read and reset statistic information about
the actual datatransfer in this protocol
All buffers are entire LDU's though there is no control
of this.
The following control commands are accepted:
a) Input request
b) Cancel input request
c) Cancel output
d) Report status request
e) Open channel
The following responses can be returned to CR80:
a) Transmission status
b) Interrupt
c) Channel status
A further description of how the different commands
are interpreted in the LTU and how the responses are
interpreted in the CR80 is given on the next pages.
a) I̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲:̲
No databuffers are sent to level 3 without an "Input
request" is pending. Level 3 do not have more than
7 "Input request"s pending.
b) C̲a̲n̲c̲e̲l̲ ̲i̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲s̲:̲
This will be executed of the mentioned "Input request"
has not already been used.
No response.
c) C̲a̲n̲c̲e̲l̲ ̲o̲u̲t̲p̲u̲t̲:̲
This command will only be executed if the protocol
has not taken the buffer in question (see"Transmission
status"). Response will only be returned if the
cancelling succeeds. This response will be "TX
cancelled".
d) R̲e̲p̲o̲r̲t̲ ̲s̲t̲a̲t̲u̲s̲ ̲r̲e̲q̲u̲e̲s̲t̲:̲
This command is a cover for all the special control
commands and status commands which are implemented
in the protocol. The next pages give a further
description of these.
e) O̲p̲e̲n̲ ̲c̲h̲a̲n̲n̲e̲l̲:̲
This command is the same as "REOPEN" in the "Report
status request"; only will there not be sent any
response to this command and the parameters begin
from the 1 byte after "Control code".
f) I̲n̲t̲e̲r̲r̲u̲p̲t̲
This is sent when the Rx-protocol has changes mode
(disconnected connected) or when the Tx-protocol
without CR80-command gets disconnected.
The "interrupt" will have 1 parameter, which informs
about the direction of mode-transition.
Parameter Current protocol state:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
0 Rx-protocol connected
1 Rx-protocol disconnected
2 Tx-protocol disconnected
g) T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲s̲t̲a̲t̲u̲s̲:̲
This is sent when the protocol takes a databuffer
or when a databuffer is cancelled by the "Cancel
output"-command.
When the protocol takes a databuffer, it sends
a "Tx OK" and the buffer cannot be cancelled by
the "Cancel output"-command.
When the databuffer is cancelled by the "Cancel
output"-command, the response is "Tx cancelled".
A "Report status request" - command buffer will look
like this:
1 byte Buffer type
2 byte Control type
3 byte Identifier
4 byte Status type
5 byte Spare
6 byte Parameter 1
Parameter 2
-"- -"-
The response to a "Report status request" will be a
"Channel status", which will look like this:
1 byte Buffer type
2 byte Control type
3 byte The identifier
4 byte Status type
5 byte Error-code
6 byte Parameter 1
Parameter 2
-"- -"-
A response will have the same "Status type" as the
command it is a response to.
R̲E̲O̲P̲E̲N̲:̲
1. Parameter (1 byte): Max. no. of retransmissions
2. Parameter (1 byte): Max. no. of outstanding
frames
3. Parameter (1 byte): Time out time
4. Parameter (1 byte): Baudrate out
The Tx-protocol level 2 shall be disconnected to execute
this command.
If the user does not want to change one or more of
the parameters in the protocol, these must be set to
OFFH.
Parameter Limits Default
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
Max no.of retransmissions 127 8
Max no.of outstanding frames 7 7
Time out time 200ms-50sec 10sec
Baudrate out 50-48000 4800
Timeout time = Timeout parameter * 200 msec
S̲E̲T̲ ̲U̲P̲ ̲L̲I̲N̲K̲:̲
No parameters
The Tx-protocol level 2 shall be disconnected to execute
this command.
D̲I̲S̲C̲ ̲L̲I̲N̲K̲:̲
No parameters
The Tx-protocol level 2 shall be connected or connecting
and not already be going to disconnected mode to execute
this command.
This command is the only which can result in the errortype
2.
S̲E̲T̲ ̲U̲P̲ ̲L̲I̲N̲E̲S̲
No parameters
The Tx-protocol level 2 shall be disconnected to execute
this command.
D̲I̲S̲C̲ ̲L̲I̲N̲E̲S̲:̲
No parameters.
The protocol level 2 shall be disconnected to execute
this command.
S̲E̲T̲ ̲V̲2̲4̲:̲
1. Parameter (1 byte): Set/reset/no
change of
RTS (IO5)
2. Parameter (1 byte): Set/reset/no
change of
DTR (108/1)
The protocol level 2 shall be disconnected
to execute this command.
Set current Reset curcuit no
change:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0CH 03H anything
else
R̲e̲a̲d̲ ̲V̲2̲4̲:̲
1. Parameter (1 byte): Read/no
read of
CTS (106)
2. Parameter (1 byte): Read/no
read of
DSR (107)
This command will always be executed.
Read curcuit No read of
curcuit
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0C0H anything
else
The response will be:
1. Parameter (1 byte): CTS (106)/not
read
2. Parameter (1 byte): DSR (107)/not
read
Curcuit on Curcuit off Curcuit
not read
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0CCH 0C3H 00H
S̲T̲A̲T̲I̲S̲T̲I̲C̲:̲
1.Parameter (1 byte): Reset/no reset of no.
of transmissions
2.Parameter (1 byte): Reset/no reset of no.
of retransmissions
3.Parameter (1 byte): Reset/no reset of no.
of received I-frames
without error
4.Parameter (1 byte): Reset/no reset of no.
of CRC-errors
5.Parameter (1 byte): Reset/no reset of no.
of frames too long
6.Parameter (1 byte): Reset/no reset of no.
of frames too short
7.Parameter (1 byte): Reset/no reset of no.
of DCD-drops
Reset No Reset
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
OH anything else
The response will be:
1. Parameter (2 bytes): No. of transmissions
2. Parameter (2 bytes): No. of retransmissions
3. Parameter (2 bytes): No. of received I-frames
without error
4. Parameter (1 byte): No. of CRC-errors
5. Parameter (1 byte): No. of frames too
long
6. Parameter (1 byte): No. of frames too
short
7. Parameter (1 byte): no. of DCD-drops
A 2-byte-parameter has have LSB first.
