top - download
⟦85960017d⟧ Wang Wps File
Length: 45699 (0xb283)
Types: Wang Wps File
Notes: CPS/SDS/028
Names: »1668A «
Derivation
└─⟦0c861a53d⟧ Bits:30006079 8" Wang WCS floppy, CR 0122A
└─ ⟦this⟧ »1668A «
WangText
…00……00……00……00……00…,…02……00……00…,
+…09…+…0e…+…0f…+…00…+…06…*…0a…*…0e…*
)…09…)…0f…)
)…07…(…0e……86…1 …02… …02… …02…
…02…CPS/SDS/028
…02…840901…02……02…
I/O CONTROL
DETAILED DESIGN SPECIFICATION ISSUE 1 CAMPS
4.1.5 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
In this section components of a generalized handler
are described. In the subpackage specifications, protocol
handlers are then described referring to the description
of the generalized handler components.
IOC implements protocol handlers of two types, namely:
- High level protocols with full data I/O interface
to TMS.
- Mid level protocols with control interface to TMS
and data interface to high level protocols.
For further description of this hierarchy of protocols
(called subdevices) please refer to the product specifications
for the DAMOS components:
Terminal Management System,
LTU Handler,
TDX Handler.
The generalized handler consists of the following components:
Inputter, receiving data on an LTU, LTUX channel or
from a mid-level protocol.
Outputter, sending data on an LTU, LTUX channel or
to
a mid-level protocol.
Protocol Controller (PROT ̲CONT) sending protocol
commands to, receiving responses from LTU,
LTUX firmware or to/from a mid-level protocol.
Controller implementing the TMS control interface.
User interface implementing the TMS data I/O interface
(high level protocols only).
Subdevice interface implementing the interface to high
level protocols (mid level protocols only).
Inputter, Outputter, Protocol Controller and Controller
are totally generalized and named as member in a General
Handler Subpackage.
Communication between protocol layers is performed
by means of data buffers linked together in socalled
LDUs, refer fig. 4.1.5-1 and 4.1.5-2.
The buffers are described by a descriptor BUFFER ̲ENTRY
(refer section 4.1.4).
The actual size of a buffer at time of hand-over to
another protocol level is loaded in the BUFFER ̲ENTRY
field BUFFER ̲SIZE.
The data transferred may be of type CONTROL or of type
DATA. In this design control is always transferred
in single buffers (type ENTIRE ̲LDU) where data may
be transferred in single buffers or in linked buffers.
DATA transferred has the first byte reserved, this
is the socalled LDU header, used to hold a sequence
number called LDU.
CONTROL transferred to a lower level may be of various
types indicated in the first byte.
- Input request, requesting lower level for next
LDU. The input request may contain information
specifying the request.
Fig. 4.1.5-1…01…Buffer Linkage
Fig. 4.1.5-2…01…Single Buffer
- Protocol Command, used to configure the lower level
or the LTU/LTUX firmware.
- Cancel input request used to cancel already requested
input.
- Cancel output request used to cancel output in
transfer.
Control transferred from a lower level (called Status)
may be of one of the following types:
- Transmission status, giving result of a transmitted
LDU.
- Reception status, giving abnormal result on input
or
- Protocol status being the lower level response
to a Protocol Command.
- Interrupt giving asynchronous information about
an event.
Below the generalized handler is presented in the form
of a module description. Whereever a component is
used in the description of a protocol handler, the
module name is reused with a prefix.
4.1.5.0 C̲o̲m̲m̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲M̲o̲d̲u̲l̲e̲s̲
In this module are collected procedures wich are used
in other modules and are to be common for these.
The implemented functions are:
Queue
Queue ̲prioritized
Get ̲TMS ̲buffer ̲type
Get ̲LTU ̲buffer ̲type
Send ̲operations ̲reply
Allow ̲status ̲report
Send ̲status ̲report
Load ̲buffer ̲return
Return ̲first ̲databuffer
Return ̲next ̲databuffer
Load ̲cancel ̲reply
Return ̲buffer
Init ̲buffer ̲entry
Send
Get ̲page ̲page ̲add
4.1.5.1 E̲H̲P̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.1.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 EHP module implements the TMS interface and converts
the request into requests for other modules of the
generalized handler.
The implemented functions are:
OPEN ̲SUBDEVICE
CLOSE ̲SUBDEVICE
ENABLE ̲INPUT
ENABLE ̲CONTROL ̲INPUT
ACKNOWLEDGE ̲INPUT
GET ̲OUTPUT ̲BUFFER
GET ̲CONTROL ̲BUFFER
INIT ̲OUTPUT
CANCEL ̲OPERATION
ENABLE ̲STATUS ̲RESPONSE
These are all standard functions required by TMS.
4.1.5.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The EHP module is entered by TMS via the EHP entry
with the following convention.
R̲e̲g̲i̲s̲t̲e̲r̲s̲ ̲a̲t̲ ̲c̲a̲l̲l̲
R1 FUNCTION (D)
R3 CAPABILITY (D)
R4 Pointer to the data-area of
subdevice (OWN ̲SDID) (K)
R5 Pointer to interface
parameters (see below) (K)
R̲e̲g̲i̲s̲t̲e̲r̲s̲ ̲a̲t̲ ̲r̲e̲t̲u̲r̲n̲
R7 CC
R0 - R3, R6 DESTROYED
At return, the parameter area pointed by R5 is modified.
The parameters pointed by R5 have a layout depending
on the function. The conventions are:
OPEN ̲SUBDEVICE:
OPEN ̲SUBDEVICE ̲PARAM
CLOSE ̲SUBDEVICE:
CLOSE ̲SUBDEVICE ̲PARAM
ENABLE ̲INPUT,ENABLE ̲CONTROL ̲INPUT:
ENABLE ̲PARAM
ACKNOWLEDGE ̲INPUT: ACK ̲OR ̲CANCEL ̲PARAM
GET ̲OUTPUT ̲BUFFER, GET ̲CONTROL ̲BUFFER:
GET ̲BUFFER ̲PARAM
INIT ̲OUTPUT: INIT ̲OUTPUT ̲PARAM
CANCEL ̲OPERATION: ACK ̲OR ̲CANCEL PARAM
ENABLE ̲STATUS ̲RESPONSE: ENABLE ̲STATUS ̲PARAM
The asynchronous responses are sent formatted as of:
H ̲OP ̲REPLY ̲MESSAGE
4.1.5.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The EHP module consists of:
- EHP ̲ENTRY implementing the TMS interface.
4.1.5.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The data for a protocol is described in section 4.1.4.
The EHP ̲ENTRY accesses the "Common data" part to verify
access and accesses plus the following
CONTROLLER.INPUT.QEL (R)
CONTROLLER.OUTPUT.QEL (R)
Any IO ̲QEL the field
QEL.REQUESTOR (R)
OPENER (R)
These accesses are only used as a selector to see which
other modules shall be invoked based on and operation
reference given by TMS.
4.1.5.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
4.1.5.1.5.1 E̲H̲P̲ ̲E̲n̲t̲r̲y̲
The EHP entry is only a selector of functions of other
modules.
It should be noted that R4 is treated as common data
not touched by any module of a handler. R4 points
to SDID of the actual subdevice and is everywhere named
OWN ̲SDID.
The return from the EHP entry is not a normal return,
but a call to the standard handler function RETURN
̲FROM ̲SUBDEVICE.
4.1.5.2 S̲P̲I̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.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̲
The SPI module (SPI = Special Protocol
Interface) implements the standard functions
required for DAMOS inter-protocol communication
except for the CONTROL ̲PROTOCOL, which
is optional; for flexibility, this control
is implemented by control buffers.
The SPI functions can logically be divided
into two groups, those required for Mid-level
protocols for interfacing to High-level
protocols and those required for all protocols.
F̲o̲r̲ ̲a̲l̲l̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲s̲:
OPEN ̲PROTOCOL Initialization
of protocol data
is performed.
This entry is
called after
the parent has
reserved the
data area.
NOTIFY ̲INPUT ̲BUFFER The Parent has
obtained an input
buffer from LTU/LTUX
and hands it
on to the CHILD
through this
call.
NOTIFY ̲OUTPUT ̲BUFFER The protocol
has earlier requested
an output buffer
at the Parent
and got the reply
"request ̲queued",
now the Parent
has an output
buffer ready
NOTIFY ̲TRANSMISSION The Parent informs
that a single
buffer has been
transmitted.
In this design,
this interface
is dummy since
complete LDUs
are acknowledged.
CLEAN ̲UP ̲ALL The Parent asks
the protocol
to clean all
subdevices and
release all buffer
resources.
CLEAN ̲UP ̲USER The parent asks
the protocol
to remove all
requests for
a certain user.
In this design,
the creator is
the only one
allowed access
so if the caller
is the creator,
the function
is identical
to CLEAN ̲UP ̲ALL.
F̲o̲r̲ ̲m̲i̲d̲ ̲l̲e̲v̲e̲l̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲s̲:
RELEASE ̲INPUT ̲BUFFER…02…A Child has received
the input
and
handed
the
data
further
on
(e.g.
to
TMS)
RESERVE ̲OUTPUT ̲BUFFER A Child has data
to output due
to a request
from higher level
or TMS. The
protocol asks
its parent for
a buffer and
if obtained,
the Child gets
immediate response
with buffer reference.
If no buffer
available, the
Child is informed
"request-queued".
CANCEL ̲RESERVE ̲OUTPUT ̲
BUFFER A
Child
has
received
a
cancel
request
from
a
higher
level
(e.g.
TMS)
and
has
changed
mind,
does
not
want
to
perform
this
output
(or
the
transfer
has
been
cancelled).
The
protocol
cleans
up
for
this
request
and
processes
possible
pending
requests.
RELEASE ̲OUTPUT ̲BUFFER A Child has already
obtained an output
buffer, but due
to a cancel,
does not want
to use it.
TRANSMIT ̲OUTPUT ̲BUFFER A Child has filled
a buffer and
sends it. The
protocol saves
the Child identification
and puts its
own identification.
WANT ̲TO ̲CLOSE A Child has been
called by TMS
CLOSE ̲SUBDEVICE
and asks the
protocol to be
removed.
OPEN ̲SUBDEVICE TMS wants to
create a new
subdevice.
4.1.5.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The SPI entry is entered by standard handler
software whenever a parent or a child
calls ACTIVATE ̲SPI. The register setup
at entry is as follows (Note difference
from call to ACTIVATE ̲SPI).
R̲e̲g̲i̲s̲t̲e̲r̲s̲ ̲a̲t̲ ̲c̲a̲l̲l̲
R1 FUNCTION (D)
R4 Pointer to data-area of subdevice
(OWN ̲SDID) (K)
R5 Pointer to IF ̲PARAM
(of type SPI ̲PARAM) (K)
R̲e̲g̲i̲s̲t̲e̲r̲s̲ ̲a̲t̲ ̲r̲e̲t̲u̲r̲n̲
R7 CC
R0 - R3, R6 (Dest.)
At the moment of return IF ̲PARAM is updated
according to the invoked function to REQUEST
̲QUEUED or OK.
4.1.5.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
SPI ̲ENTRY
CLEAN This procedure
is common for
functions CLEAN
̲UP ̲USER, CLEAN
̲UP ̲ALL
4.1.5.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The data for a protocol is described in
section 4.1.4.
The SPI ̲ENTRY accesses data to detect
which module to invoke as follows:
OUTPUTTER.REQ ̲RECORD (R)
INPUTTER.REQ ̲RECORD (R)
PROT ̲CONT.REQ ̲RECORD (R)
F̲u̲r̲t̲h̲e̲r̲
OPENER (M-Initialization)
(R-CLEAN
̲UP
̲USER)
PARENT ̲SDID (M
-
at
init)
STATUS ̲SE (M
-
at
init)
STATUS (M)
4.1.5.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
4.1.5.2.5.1 S̲P̲I̲ ̲E̲N̲T̲R̲Y̲ ̲D̲e̲s̲i̲g̲n̲
The SUBDEV points to the parent work area
of the subdevice, for Children, this is
the protocols work area.
4.1.5.2.5.4 C̲L̲E̲A̲N̲ ̲D̲e̲s̲i̲g̲n̲
The CLEAN procedure is responsible for
removing all subdevices of this protocol
plus release all resources.
Subdevices are first removed to have the
same processing as when a single subdevice
is removed.
The actual cleaning is performed by a
call to the module in question.
4.1.5.3 I̲N̲P̲U̲T̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.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̲
The INPUTTER schedules input requests
from USER ̲INTERFACE module, CONTROLLER
module, SUBDEVICE module and PROTOCOL
module in such a way that inputs are performed
one by one and according to the priority
inserted by the requesting module. In
this way, the CONTROLLER may have a priority
higher than any subdevice and the subdevices
may be prioritized among themselves.
To schedule the input activity, the INPUTTER
maintains two queues, one for pending
input and another containing the actually
ongoing input. The queue elements are
delivered by the requestors.
The processing for a single input is:
1. A control buffer is requested at the
Parent.
2. When the control buffer is available
it is handed back to the requestor
of input.
3. The requestor fills the buffer with
the input request data and hands it
to the INPUTTER.
4. The inputter writes its own LDU identification
and marks the buffer as input request.
5. The inputter sends the buffer to the
parent which either processes it or
sends it to LTU/LTUX and the INPUTTER
awaits data for the requested LDU.
6. Any data arriving, when the inputter
does not expect data or from a different
LDU is ignored (this data may belong
to a cancelled input).
7. When good data arrives, the inputter
hands it back to the requestor, which
is responsible for returning the data
to TMS or a child.
8. When END ̲OF ̲LDU is received from Parent,
this input is considered completed,
so when this data is handed to the
requestor he will reuse the queue
element.
…86…1…02… …02… …02… …02… …02… …02… …02…
9. The current input is also terminated
when a RECEPTION ̲STATUS buffer is
received from the Parent.
The INPUTTER hands the buffer to the
requestor through the requestors RESULT
entry.
10. A requestor may cancel an input request
by calling CANCEL ̲INPUT. The requestors
resources are released by the INPUTTER
upon return.
The functions of the INPUTTER module are
identified by entry points (see module
interface).
4.1.5.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The INPUTTER is called via on of the following:
INITIALIZE ̲INPUTTER (PARAM: OPEN ̲SUBDEVICE
̲PARAM) ( )
NOTIFY ̲INPUTTER ̲OF ̲DATA (BUFFER ̲ENTRY:
POINTER) ( )
NOTIFY ̲INPUTTER ̲OF ̲RECEPTION (BUFFER ̲ENTRY)
( )
NOTIFY ̲INPUTTER ̲OUTPUT ̲BUFFER (BUFFER
̲ENTRY) ( )
CLEAN ̲INPUTTER ( ) ( )
SEND ̲INPUT ̲REQUEST (SIZE: INTEGER) (
)
REQUEST ̲DATA ̲INPUT (QEL: IO ̲QEL, PRIORITY:
PRIORITY ̲TYPE)
(CC: COMPLETION
̲CODE, BUFFER
̲REF: POINTER)
RELEASE ̲INPUT ̲BUFFER(BUFFER ̲ENTRY: POINTER)
( )
CANCEL ̲INPUT (QEL: IO ̲QEL) ( )
…86…1…02… …02… …02… …02… …02… …02… …02…
The INPUTTER calls the following functional
entries to other modules:
USER ̲INPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲ENTRY: POINTER)
CONTROLLER ̲INPUT ̲RESULT (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER)
SUBDEVICE ̲INPUT ̲RESULT (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER)
PROTOCOL ̲INPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲ENTRY: POINTER)
NOTIFY ̲USER ̲INPUT ̲REQUEST ̲BUFFER (QEL:
IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲SUBDEVICE ̲INPUT ̲REQUEST ̲BUFFER
(QEL: IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲INPUT ̲REQUEST ̲BUFFER
(QEL: IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲PROTOCOL ̲INPUT ̲REQUEST ̲BUFFER (QEL:
IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲USER ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲INPUT ̲DATA (QEL: IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲SUBDEVICE ̲INPUT ̲DATA (QEL: IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲PROTOCOL ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲USER ̲FIRST ̲INPUT ̲DATA (QEL: IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲FIRST ̲INPUT ̲DATA (QEL:
IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲SUBDEVICE ̲FIRST ̲INPUT ̲DATA (QEL:
IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲PROTOCOL ̲FIRST ̲INPUT ̲DATA (QEL:
IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
Furthermore,
PROTOCOL ̲ERROR
ACTIVATE ̲SPI
QUEUE ̲PRIORITIZED
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
EXTRACT ̲SPECIFIED
4.1.5.3.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 INPUTTER
CLEAN ̲INPUTTER
R̲e̲q̲u̲e̲s̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲DATA ̲INPUT
CANCEL ̲INPUT
SEND ̲INPUT ̲REQUEST
P̲a̲r̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲INPUTTER ̲OF ̲RECEPTION
NOTIFY ̲INPUTTER ̲OUTPUT ̲BUFFER
NOTIFY ̲INPUTTER ̲OF ̲DATA
G̲e̲n̲e̲r̲a̲l̲
RELEASE ̲INPUT ̲BUFFER
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
I̲n̲p̲u̲t̲ ̲c̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
PROCESS ̲FOR ̲END ̲OF ̲INPUT
NEXT ̲INPUT
PROCESS ̲FOR ̲NEXT ̲INPUT
R̲e̲q̲u̲e̲s̲t̲o̲r̲ ̲n̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
RETURN ̲INPUT ̲REQUEST ̲BUFFER
RETURN ̲INPUT ̲RESULT
C̲a̲n̲c̲e̲l̲ ̲s̲u̲p̲p̲o̲r̲t̲
CANCEL ̲PENDING ̲INPUT
CANCEL ̲ONGOING ̲INPUT
SHIP ̲CANCEL ̲INPUT
4.1.5.4 O̲U̲T̲P̲U̲T̲T̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.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 OUTPUTTER schedules output requests from USER ̲INTERFACE
module CONTROLLER module, SUBDEVICE module, and PROTOCOL
module in such a way, that LDUs for output are sent
one by one and according to priority defined by the
requestor. In this way, the CONTROLLER may be given
higher priority than any subdevice, and the subdevices
may be prioritized among themselves.
The OUTPUTTER maintains three queues. In the PENDING
queue requests for output allowance are queued, in
the ONGOING queue, the request currently processed
is, and in the AWAIT ̲COMPLETION queue output requests
are held after output of the entire LDU until the LTU/LTUX
has sent back a transmission status for the LDU.
The priority mechanism works as follows. Whenever
a request is inserted in the PENDING queue, this is
done according to the priority of the request so the
first element in the PENDING queue will always be the
request of highest priority.
Whenever a request has been activated, the possible
occurrence of requests of higher priority has no effect,
i.e. the requestor may get as many output buffers as
required for the present LDU. Only when the last buffer
of an LDU has been handed to the Parent protocol, the
ongoing request is moved to the WAIT ̲COMPLETION queue
and the next pending request activated.
The processing for one outgoing request is:
1) A data buffer is requested at the Parent.
2) When the buffer is available, it is handed to the
requestor.
3) The requestor fills the buffer with output data
and hands it to the OUTPUTTER.
4) If the buffer is the first within an LDU, the OUTPUTTER
gets next LDU and stores this ID in the LDU header
of the buffer and in the queue element of the ongoing
output.
5) Subsequent buffers are just marked "data" and handed
to the Parent.
6) Output of last buffer by the requestor sets the
OUTPUTTER idle and the ongoing request is moved
to the AWAIT ̲COMPLETION queue.
7) The OUTPUTTER may process other output requests.
8) Whenever a transmission status is received from
the Parent, the OUTPUTTER looks in the WAIT ̲COMPLETION
queue to find the queue element of the request
and our requestor is notified.
The functions of the OUTPUTTER are directly identified
by the entry pointer of the same name (see module interface).
4.1.5.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The Outputter is called via one of the following:
INITIALIZE ̲OUTPUTTER (PARAM: OPEN ̲SUBDEVICE ̲PARAM)
( )
REQUEST ̲DATA ̲OUTPUT (QEL: IO ̲QEL, PRIORITY:
PRIORITY ̲TYPE)
(CC: COMPLETION
̲CODE, BUFFER
̲REF: POINTER)
NOTIFY ̲OUTPUTTER ̲OUTPUT ̲BUFFER (BUFFER
̲ENTRY: POINTER) ( )
REQUEST ̲NEXT ̲BUFFER ( ) (CC: COMPLETION
̲CODE,
BUFFER
̲REF:
POINTER)
NOTIFY ̲OUTPUTTER ̲OF ̲STATUS(BUFFER ̲ENTRY:
POINTER) ( )
SEND ̲OUTPUT ̲BUFFER(TYPE: BUFFER ̲TYPES,BYTE
̲COUNT: INTEGER) ( )
CLEAN ̲OUTPUTTER ( ) ( )
CANCEL ̲OUTPUT (QEL: IO ̲QEL) ( )
The outputter calls the following functional entries
to other modules.
NOTIFY ̲USER ̲FIRST ̲OUTPUT ̲BUFFER (QEL: IO
̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲USER ̲SUBSEQUENT ̲OUTPUT ̲BUFFER (QEL:
IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
USER ̲OUTPUT ̲RESULT (QEL: IO ̲QEL, BUFFER ̲REF:
POINTER) ( )
Same with USER replaced by SUBDEVICE
Same with USER replaced by CONTROLLER
Same with USER replaced by PROTOCOL
Furthermore,
PROTOCOL ̲ERROR
ACTIVATE ̲SPI
QUEUE ̲PRIORITIZED
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
EXTRACT ̲SPECIFIED
4.1.5.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 ̲OUTPUTTER
CLEAN ̲OUTPUTTER
R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲DATA ̲OUTPUT
REQUEST ̲NEXT ̲BUFFER
CANCEL ̲OUTPUT
SEND ̲OUTPUT ̲BUFFER
P̲a̲r̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲OUTPUTTER ̲OF ̲STATUS
NOTIFY ̲OUTPUTTER ̲OUTPUT ̲BUFFER
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
O̲u̲t̲p̲u̲t̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
PROC ̲FOR ̲END ̲OF ̲OUTPUT
NEXT ̲OUTPUT
PROC ̲FOR ̲NEXT ̲OUTPUT
R̲e̲q̲u̲e̲s̲t̲o̲r̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
RETURN ̲OUTPUT ̲BUFFER
C̲a̲n̲c̲e̲l̲ ̲S̲u̲p̲p̲o̲r̲t̲
CANCEL ̲PENDING ̲OUTPUT
CANCEL ̲ONGOING ̲OUTPUT
CANCEL ̲WAIT ̲COMPLETION ̲OUTPUT
SHIP ̲CANCEL ̲OUTPUT
4.1.5.5 U̲S̲E̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.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̲
The USER ̲INTERFACE handles the TMS requests for input
and output. INPUT to TMS is performed by TMS calling
the protocol handler through the entry ENABLE ̲INPUT.
On the first call of ENABLE ̲INPUT the USER ̲INTERFACE
Module calls the INPUTTER to obtain an input request
buffer. The INPUTTER may queue the request or may deliver
the buffer immediately. When the buffer for input request
is available the USER ̲INTERFACE loads it with information
specifying the request and sends it to the INPUTTER.
From now on the USER ̲INTERFACE simply awaits input.
Whenever input data for this requested LDU arrives
it is handed to TMS if TMS has a pending request or
the data is queued on the DATA ̲Q. TMS issues series
of ENABLE-INPUT request each indicating the amount
of data requested. The USER ̲INTERFACE either hands
full input buffer to TMS or if the request calls for
less data than a full buffer, part of a buffer. When
part of a buffer has been returned the next request
get either a new part of the buffer or the rest of
the buffer.
Whenever type END ̲OF ̲LDU or ENTIRE ̲LDU has been returned
to TMS, or the input has been abnormally terminated
(result) the next ENABLE ̲INPUT is considered as the
socalled first (see above).
Whenever TMS has cancelled an input request the USER-INTERFACE
calls the INPUTTER with cancel and releases any data
in the DATA ̲Q. A possible input request buffer is released
by the INPUTTER. Upon a cancel TMS shall be notified
asynchronously if the last TMS request was answered
request queued.
OUTPUT from TMS is performed by TMS calling GET ̲OUTPUT
̲
BUFFER. Upon the first call of GET ̲OUTPUT ̲BUFFER (i.e.
initialization, a completed output or a cancelled output)
the USER ̲INTERFACE calls the OUTPUTTER by REQUEST ̲DATA
̲OUTPUT. The OUTPUTTER may queue the request or hand
an output buffer immediately. In the first buffer obtained
the USER ̲INTERFACE must have room for LDU header and
therefore modify buffer address and size before returning
it to TMS. Buffers are immediately returned to TMS
in the call of GET ̲OUTPUT ̲
BUFFER if they are available. If the USER ̲INTERFACE
is asynchronously notified of the buffer, it is handled
to TMS by asynchronous response.
Whenever the USER ̲INTERFACE has obtained the first
output buffer and until the last part of a LDU is sent
the OUTPUTTER only outputs data for the USER ̲INTERFACE.
Subsequent buffers are reserved by calling REQUEST
̲NEXT ̲
BUFFER.
When the output of one LDU is completed, the USER ̲
INTERFACE may immediately start the next output. There
may be as many outstanding outputs as there are queue
elements in the EMPTY queue.
Whenever later on LTU/LTUX has successfully transmitted
the LDU the transmission status buffer completing the
LDU is handed by the OUTPUTTER and TMS is informed
of the result.
The functions performed are identified by the entry
points (Refer section 4.1.5.5.2).
4.1.5.5.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The USER ̲INTERFACE is called via one of the following:
ENABLE ̲INPUT(PARS:ENABLE ̲PARAM)(CC:COMPLETION ̲CODE)
ACK ̲DATA ̲INPUT () ()
NOTIFY ̲USER ̲INPUT ̲REQUEST ̲BUFFER(QEL:IO ̲QEL,BUFFER
̲REF:POINTER) ()
USER ̲INPUT ̲RESULT(QEL:IO ̲QEL,BUFFER ̲REF:POINTER) ()
GET ̲OUTPUT ̲BUFFER(PARS:GET ̲BUFFER ̲PARAM) (CC:COMPLETION
̲CODE)
NOTIFY ̲USER ̲FIRST ̲OUTPUT ̲BUFFER(QEL:IO ̲QEL,BUFFER ̲REF:POINTER)
()
NOTIFY ̲USER ̲SUBSEQUENT ̲OUTPUT ̲BUFFER(QEL:IO ̲QEL,BUFFER
̲REF:POINTER) ()
USER ̲OUTPUT(PARAMS:INIT ̲OUTPUT ̲PARAM)(CC:COMPLETION
̲CODE)
USER ̲OUTPUT ̲RESULT(QEL:IO ̲QEL,RESULT:COMPLETION ̲CODE)
()
NOTIFY ̲USER ̲FIRST ̲INPUT ̲DATA(QEL:IO ̲QEL,BUFFER ̲ENTRY:POINTER)
()
NOTIFY ̲USER ̲INPUT ̲DATA(QEL:IO ̲QEL,BUFFER ̲ENTRY:POINTER)()
CANCEL ̲USER ̲OPERATION(QEL) ()
INITIALIZE ̲USER ̲DATA(PARAMS:OPEN ̲SUBDEVICE ̲PARAM)()
CLEAN ̲USER ̲DATA ()()
The USER ̲INTERFACE calls following functional entries
to other modules:
REQUEST ̲DATA ̲INPUT(QEL:IO ̲QEL,PRIORITY:PRIORITY ̲TYPE)
(CC:COMPLETION ̲CODE,BUFFER ̲REF:POINTER)
SEND ̲INPUT ̲REQUEST(SIZE:INTEGER) ()
RELEASE ̲INPUT ̲BUFFER(BUFFER ̲REF:POINTER) ()
LOAD ̲BUFFER ̲RETURN(PARS:GET ̲BUFFER ̲PARAM) ()
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(TYPE:BUFFER ̲TYPES,BYTE ̲COUNT:INTEGER)()
Furthermore:
PROTOCOL ̲ERROR
SEND ̲OPERATIONS ̲REPLY
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
RETURN ̲FIRST ̲DATABUFFER
RETURN ̲NEXT ̲DATABUFFER
LOAD ̲CANCEL ̲REPLY
4.1.5.5.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 ̲USER ̲DATA
CLEAN ̲USER ̲DATA
I̲n̲p̲u̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
ENABLE ̲INPUT
ACK ̲DATA ̲INPUT
O̲u̲t̲p̲u̲t̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
GET ̲OUTPUT ̲BUFFER
USER ̲OUTPUT
C̲a̲n̲c̲e̲l̲
CANCEL ̲USER ̲OPERATION
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 ̲USER ̲FIRST ̲OUTPUT ̲BUFFER
NOTIFY ̲USER ̲SUBSEQUENT ̲OUTPUT ̲BUFFER
USER ̲OUTPUT RESULT
I̲N̲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 ̲USER ̲INPUT ̲REQUEST ̲BUFFER
NOTIFY ̲USER ̲FIRST ̲INPUT ̲DATA
NOTIFY ̲USER ̲INPUT ̲DATA
USER ̲INPUT ̲RESULT
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
I̲n̲p̲u̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
SETUP ̲INPUT ̲REQUEST
RETURN ̲DATA
RETURN ̲RESULT
NEXT ̲DATA ̲QEL
O̲u̲t̲p̲u̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
RETURN-OUTPUT ̲RESULT
C̲a̲n̲c̲e̲l̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
CANCEL ̲USER ̲INPUT
CANCEL ̲USER ̲OUTPUT
EMPTY ̲DATA ̲Q
4.1.5.5.4.10 O̲p̲t̲i̲o̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
For protocols having the USER ̲INTERFACE module generating
protocol commands to the parent protocol/LTU/LTUX,
the response interface for the PROT ̲CONT module must
be implemented i.e.:
NOTIFY ̲USER ̲PROT ̲CONT ̲BUFFER and
USER ̲PROT ̲CONT ̲RESULT
must be included.
Protocols where this interface is missing must omit
the calls in the PROT ̲CONT module to avoid software
linkage errors.
4.1.5.6 C̲O̲N̲T̲R̲O̲L̲L̲E̲R̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.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̲
The CONTROLLER handles the TMS requests for control
of the protocol including asynchronous error reporting.
The CONTROLLER need not be present in all protocols.
Examples in CAMPS where omitted, are VDU ̲DATA protocol
and VDU ̲CONTROL protocol.
Three types of control may be performed.
- Subdevice control giving the requestor the possibility
to interact directly with the running protocol
for example to let the subdevice protocol execute
complex series of control commands to lower levels.
- Lower protocol control (which may be OUTPUT or
OUTPUT + INPUT) to let the control interface send
and receive control buffers of type "Protocol command",
"Protocol status" to/from LTU/LTUX firmware.
- External device. This gives full data communication
capability to the external device, like initialization
of VDU split settings, setting of MSP tabulation.
The error reporting function of the CONTROLLER schedules
errors by priority. It has a queue of one error, any
error with higher priority will overwrite this error.
The CONTROLLER interfaces with the SSC package of CAMPS
through data buffers, where the first word is the control
type.
Based on the control type, the CONTROLLER detects the
action to be taken. For type SUBDEVICE, it requests
the PROTOCOL module to take action, for type LOWER
̲PROTOCOL, the PROT ̲CONT module is requested to deliver
a control buffer for type EXTERNAL ̲DEVICE ̲INPUT, the
INPUTTER is activated, for type EXTERNAL ̲DEVICE ̲OUTPUT,
the OUTPUTTER is activated.
Control requests may output only or combined output-input.
External device input and lower protocol control are
always combined, others depend on the function. Wherever
input is required, the input request must be issued
by SSC before the output.
S̲U̲B̲D̲E̲V̲I̲C̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The CONTROLLER requests the PROTOCOL module for a buffer
where to load the requestors data. When TMS requests
transmission, the PROTOCOL module is informed.
After having processed the data, the PROTOCOL activates
the CONTROLLER giving completion information. If the
completion information is more than just a completion
code and there is no pending input, the Control output
is considered failed.
"Missing input request".
For further details refer each protocol of the PROTOCOL
module.
L̲O̲W̲E̲R̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Lower protocol control processing. The controller
requests a buffer at the PROT ̲CONT module, hands it
to TMS, which after filling it sends it via CONTROLLER
and PROT ̲CONT to the Parent subdevice. If the control
is of type output only, the CONTROLLER notifies TMS
of the successful completion, if the control is of
type output + input, the CONTROLLER waits for response.
E̲X̲T̲E̲R̲N̲A̲L̲ ̲D̲E̲V̲I̲C̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
External device processing is very similar to the USER
̲INTERFACE module processing for data transport except
that an input request is generated after the control
header has been output and that the control header
is not handed on to INPUTTER or OUTPUTTER.
4.1.5.6.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The CONTROLLER is called via one of the following:
INITIALIZE ̲CONTROLLER (PARAM: OPEN ̲SUBDEVICE
̲PARAM) ( )
GET ̲CONTROL ̲BUFFER (PARS: GET ̲BUFFER ̲PARAM)(CC:
COMPLETION ̲CODE)
CONTROLLER ̲OUTPUT (PARAMS: INIT ̲OUTPUT
̲PARAM)(CC: COMPLETION ̲CODE)
ENABLE ̲CONTROL ̲INPUT(PARS: ENABLE ̲PARAM)(CC:
COMPLETION ̲CODE)
NOTIFY ̲CONTROLLER ̲FIRST ̲OUTPUT ̲BUFFER
(QEL: IO ̲QEL,
BUFFER
̲REF:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲SUBSEQUENT ̲OUTPUT ̲BUFFER
(QEL:
IO
̲QEL,
BUFFER
̲REF:
POINTER)
(
)
CONTROLLER ̲INPUT ̲RESULT (QEL: IO ̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲INPUT ̲REQUEST ̲BUFFER
(QEL:
IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲FIRST ̲INPUT ̲DATA
(QEL:
IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲INPUT ̲DATA
(QEL:
IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
CONTROLLER ̲OUTPUT ̲RESULT
(QEL:
IO
̲QEL,
BUFFER
̲ENTRY:
POINTER)
(
)
NOTIFY ̲CONTROLLER ̲PROT ̲CONT ̲BUFFER
(QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ( )
ACK ̲CONTROL ̲INPUT ( ) ( )
NOTIFY ̲CONTROLLER ̲PROTOCOL ̲BUFFER
(QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ( )
CONTROLLER ̲PROT ̲CONT ̲RESULT (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER) ( )
CONTROLLER ̲PROTOCOL ̲RESULT (QEL: IO ̲QEL,
BUFFER ̲ENTRY: POINTER)()
CANCEL ̲CONTROLLER ̲OPERATION (QEL: IO ̲QEL)
( )
The CONTROLLER calls the following functional
entries to other protocol modules:
REQUEST ̲DATA ̲INPUT (QEL: IO ̲QEL, PRIORITY:
PRIORITY ̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER
̲REF: POINTER)
SEND ̲INPUT ̲REQUEST (SIZE: INTEGER) ( )
CANCEL ̲INPUT (QEL: IO ̲QEL) ( )
RELEASE ̲INPUT ̲BUFFER (BUFFER ̲REF: POINTER)
( )
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 (TYPE: BUFFER ̲TYPES, BYTE
̲COUNT: INTEGER) ( )
CANCEL ̲OUTPUT (QEL: IO ̲QEL) ( )
REQUEST ̲PROT ̲CONT (QEL: IO ̲QEL, PRIORITY:
PRIORITY ̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER
̲REF: POINTER)
SEND ̲PROT ̲CONT (RESPONSE: BOOLEAN, SIZE: INTEGER)
( )
CANCEL ̲PROT ̲CONT (QEL: IO ̲QEL) ( )
REQUEST ̲PROTOCOL (QEL: IO ̲QEL, PRIORITY: PRIORITY
̲TYPE)
(CC: COMPLETION ̲CODE, BUFFER
̲REF: POINTER)
SEND ̲PROTOCOL (CC: COMPLETION ̲CODE, BUFFER
̲REF: POINTER)()
CANCEL ̲PROTOCOL (QEL: IO ̲QEL) ( )
Furthermore
PROTOCOL ̲ERROR
SEND ̲OPERATIONS ̲REPLY
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
RETURN ̲FIRST ̲DATA BUFFER
RETURN ̲NEXT ̲DATA BUFFER
LOAD ̲CANCEL ̲REPLY
RETURN ̲BUFFER
4.1.5.6.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 ̲CONTROLLER
CLEAN ̲CONTROLLER
I̲n̲p̲u̲t̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
ENABLE ̲CONTROL ̲INPUT
ACK ̲CONTROL ̲INPUT
O̲u̲t̲p̲u̲t̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
GET ̲CONTROL ̲BUFFER
CONTROLLER ̲OUTPUT
C̲a̲n̲c̲e̲l̲
CANCEL ̲CONTROLLER ̲OPERATION
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 ̲CONTROLLER ̲FIRST ̲OUTPUT ̲BUFFER
NOTIFY ̲CONTROLLER ̲SUBSEQUENT ̲OUTPUT BUFFER
CONTROLLER ̲OUTPUT ̲RESULT
I̲N̲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 ̲CONTROLLER ̲INPUT ̲REQUEST ̲BUFFER
NOTIFY ̲CONTROLLER ̲FIRST ̲INPUT ̲DATA
NOTIFY ̲CONTROLLER ̲INPUT ̲DATA
CONTROLLER ̲INPUT ̲RESULT
P̲R̲O̲T̲ ̲C̲O̲N̲T̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲CONTROLLER ̲PROT ̲CONT ̲BUFFER
CONTROLLER ̲PROT ̲CONT ̲RESULT
P̲R̲O̲T̲O̲C̲O̲L̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲CONTROLLER ̲PROTOCOL ̲BUFFER
CONTROLLER ̲PROTOCOL ̲RESULT
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
I̲n̲p̲u̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
TERMINATE ̲CONTROL ̲INPUT
RETURN ̲CONTROLLER ̲DATA
RETURN ̲CONTROLLER ̲INPUT ̲RESULT
RETURN ̲PROT ̲CONT ̲DATA
RETURN ̲PROTOCOL ̲DATA
O̲u̲t̲p̲u̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
RETURN ̲INPUT ̲REQUEST ̲BUFFER
RETURN ̲PROT ̲CONT ̲BUFFER
RETURN ̲PROTOCOL ̲BUFFER
RETURN ̲CONTROL ̲OUTPUT ̲RESULT
C̲a̲n̲c̲e̲l̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
EMPTY ̲CONTROLLER ̲DATA ̲Q
CANCEL ̲CONTROLLER ̲INPUT
CANCEL ̲CONTROLLER ̲PROT ̲CONT
CANCEL ̲CONTROLLER ̲PROTOCOL
CANCEL ̲CONTROLLER ̲OUTPUT
EMPTY ̲CONTROLLER ̲PROT ̲CONT ̲DATA ̲Q
EMPTY ̲CONTROLLER ̲PROTOCOL ̲DATA ̲Q
4.1.5.7 S̲U̲B̲D̲E̲V̲I̲C̲E̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲M̲O̲D̲U̲L̲E̲
4.1.5.7.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 SUBDEVICE INTERFACE module implements the scheduling
of request among the subdevices, an example is scheduling
of split communication for the VDU protocol.
The SUBDEVICE INTERFACE interfaces to the higher level
protocols of the subdevices through the SPI entries
of these protocols. Within one protocol it interfaces
to the INPUTTER, OUTPUTTER, and PROT ̲CONT ̲modules
The task of the SUBDEVICE INTERFACE is to add subdevice
address to output data and input request as appropriate
for the protocol.
The processing for an input request received from a
subdevice is:
1. A queue element is fetched from the protocol's
local subdevice data. The input request data is
stored and the subdevice LDU is saved in the queue
element.
2. The INPUTTER is requested for permission to perform
input.
3. When an input request buffer is available it is
loaded with the request and sent.
4. When data arrives it is marked with the subdevice
LDU identification and handed to the subdevice.
5. The input is complete when END ̲OF ̲LDU or ENTIRE
̲LDU has been handed to the subdevice.
Input requests are only accepted one by one from a
subdevice.
The processing for an output request is as follows:
1. The SUBDEVICE INTERFACE is called by the subdevice
RESERVE ̲OUTPUT ̲BUFFER.
2. A queue element is fetched from the protocols SUBDEV
̲DATA for the subdevice and the OUTPUTTER module
is called to schedule the output.
3. When higher priority output requests have been
served or an ongoing lower priority request is
completed the SUBDEVICE INTERFACE is notified of
the availability of an output buffer.
4. The output buffer is handed to the subdevice. First
buffer is shortened to have room for the protocol
to load addressing information.
5. When the subdevice has loaded the data the protocol
picks up the subdevice LDU identification and saves
it in the queue element.
6. Addressing information is loaded in the buffer
as appropriate and the buffer is handed to the
outputter for transmission.
7. The OUTPUTTER is reserved for this subdevice until
completion of output for one LDU.
8. Eventually the SUBDEVICE INTERFACE is notified
by a buffer of the result. The subdevice identification
of the request is loaded from the queue element
and the subdevice is notified.
The processing for a control buffer request from a
subdevice is:
1. The subdevice calls the protocol via RESERVE ̲OUTPUT
̲BUFFER with control priority.
2. If the SUBDEVICE INTERFACE has no outgoing control
the control buffer is immediately handed to the
requestor else the request is queued by means of
the requestor's own request buffer.
3. After having obtained the buffer the subdevice
loads the control information and hands it back
to the SUBDEVICE INTERFACE. The control buffer
may now contain an input request or a cancel request
or a protocol control command. Input requests have
already been described. Cancel request and protocol
control commands are described below.
The processing for a cancel of a request is as follows:
1. The subdevice has sent a control buffer to the
SUBDEVICE interface with a request to cancel either
an input or an output.
2. The SUBDEVICE INTERFACE calls the INPUTTER or OUTPUTTER
to cancel the request and upon completion of the
call the same control buffer is loaded with transmission
status or reception status and the buffer is returned
to the subdevice.
The processing for a protocol control command is as
follows:
1. The subdevice has sent a control buffer with a
control command to the SUBDEVICE INTERFACE.
2. The control may concern the SUBDEVICE INTERFACE
locally. In this case the request is processed
and the buffer used to return completion immediately.
3. The request may be to the PROTOCOL module. In this
case the PROTOCOL module is requested to deliver
a buffer whereinto the request is copied and handed
to the PROTOCOL module.
4. When the PROTOCOL module has completed it returns
a buffer as response. This buffer is used to notify
the subdevice of the result.
4.1.5.7.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The SUBDEVICE INTERFACE is called via one of the following:
TRANSMIT ̲OUTPUT ̲BUFFER (IF ̲PARAM: SPI ̲PARAM,
SUBDEV: SUBDEV ̲DATA)
(CC: COMPLETION ̲CODE)
RELEASE ̲OUTPUT ̲BUFFER (IF ̲PARAM: SPI ̲PARAM,
SUBDEV: SUBDEV ̲DATA)
(CC: COMPLETION ̲CODE)
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER (IF ̲PARAM: SPI ̲PARAM,
SUBDEV: SUBDEV ̲DATA)
(CC: COMPLETION ̲CODE)
RELEASE ̲INPUT ̲B (IF ̲PARAM: SPI ̲PARAM,
SUBDEV: SUBDEV ̲DATA)
(CC: COMPLETION ̲CODE)
RESERVE ̲OUTPUT ̲BUFFER (IF ̲PARAM: SPI ̲PARAM,
SUBDEV: SUBDEV ̲DATA)
(CC: COMPLETION ̲CODE)
NOTIFY ̲SUBDEVICE ̲FIRST ̲OUTPUT ̲BUFFER
(QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲SUBSEQUENT ̲OUTPUT ̲BUFFER
(QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
SUBDEVICE ̲OUTPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲REF:
POINTER)()
SUBDEVICE ̲INPUT ̲RESULT (QEL: IO ̲QEL, BUFFER
̲REF:
POINTER)()
NOTIFY ̲SUBDEVICE ̲INPUT ̲REQUEST ̲BUFFER
(QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲INPUT ̲DATA
(QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲FIRST ̲INPUT ̲DATA
(QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
INITIALIZE ̲SUBDEVICE ̲INTERFACE
(PARAM: OPEN ̲SUBDEVICE ̲PARAM)()
CLEAN ̲SUBDEVICES()()
SUBDEVICE ̲OUTPUT ̲RESULT (QEL: IO ̲QEL,
BUFFER-̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲FIRST ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲INPUT ̲DATA (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲INPUT ̲REQUEST ̲BUFFER (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)()
SUBDEVICE ̲INPUT ̲RESULT (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)()
NOTIFY ̲SUBDEVICE ̲FIRST ̲OUTPUT ̲BUFFER (QEL: IO ̲QEL,
BUFFER ̲REF: POINTER)
()
NOTIFY ̲SUBDEVICE ̲SUBSEQUENT ̲OUTPUT ̲BUFFER (QEL: IO
̲QEL,
BUFFER ̲REF: POINTER)()
OPEN ̲SUBDEVICE (PARAM: OPEN ̲SUBDEVICE
̲PARAM) (CC: COMPLETION
̲CODE)
WANT ̲TO ̲CLOSE (SUBDEV: SUBDEV ̲DATA)()
The SUBDEVICE INTERFACE calls the following functional
entries of other modules:
REQUEST ̲DATA ̲INPUT (QEL: IO ̲QEL,
PRIORITY: PRIORITY ̲TYPE)
(CC: COMPLETION ̲CODE,
BUFFER ̲REF: POINTER)
SEND ̲INPUT ̲REQUEST (BUFFER ̲REF: POINTER)()
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 (TYPE: BUFFER ̲TYPES,
BYTE ̲COUNT: INTEGER)()
Furthermore
PROTOCOL ̲ERROR
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
4.1.5.7.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 ̲SUBDEVICE ̲INTERFACE
CLEAN ̲SUBDEVICES
I̲n̲p̲u̲t̲-̲o̲u̲t̲p̲u̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
RELEASE ̲INPUT ̲B
RESERVE ̲OUTPUT ̲BUFFER
CANCEL ̲RESERVE ̲OUTPUT ̲BUFFER
RELEASE ̲OUTPUT ̲BUFFER
TRANSMIT ̲OUTPUT ̲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 ̲SUBDEVICE ̲FIRST ̲OUTPUT ̲BUFFER
NOTIFY ̲SUBDEVICE ̲SUBSEQUENT ̲OUTPUT
BUFFER
SUBDEVICE ̲OUTPUT ̲RESULT
I̲N̲P̲U̲T̲T̲E̲R̲ ̲n̲o̲t̲i̲c̲i̲f̲a̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲SUBDEVICE ̲INPUT ̲REQUEST ̲BUFFER
NOTIFY ̲SUBDEVICE ̲FIRST ̲INPUT ̲DATA
NOTIFY ̲SUBDEVICE ̲INPUT ̲DATA
SUBDEVICE ̲INPUT ̲RESULT
S̲u̲b̲d̲e̲v̲i̲c̲e̲ ̲c̲o̲n̲t̲r̲o̲l̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
OPEN ̲SUBDEVICE
WANT ̲TO ̲CLOSE
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
I̲n̲p̲u̲t̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
LOAD ̲INPUT ̲REQUEST
RETURN ̲INPUT ̲DATA
O̲u̲t̲p̲u̲t̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
SETUP ̲FIRST ̲OUTPUT ̲BUFFER
SETUP ̲NEXT ̲OUTPUT ̲BUFFER
RETURN ̲OUTPUT ̲BUFFER
S̲u̲b̲d̲e̲v̲i̲c̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
CLEAN ̲SUBDEVICE
INITIALIZE ̲SUBDEVICE ̲DATA
C̲o̲n̲t̲r̲o̲l̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲CONTROL ̲BUFFER
NEXT ̲CONTROL
TERMINATE ̲ONGOING ̲CONTROL
4.1.5.8 P̲R̲O̲T̲ ̲C̲O̲N̲T̲ ̲M̲o̲d̲u̲l̲e̲
4.1.5.8.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 PROT ̲CONT module controls the exchange of Protocol
command/Protocol status buffers with the Parent protocol.
Especially the CONTROLLER and the PROTOCOL modules
make use of this.
The processing is as follows:
The PROT ̲CONT module controls that only one Protocol
Command to LTU/LTUX is in execution at any time.
The requestor calls REQUEST ̲PROT ̲CONT and may either
be queued or immediately be supplied with a buffer.
When the requestor gets a control buffer he loads it
with the command and hands it to the PROT ̲CONT module
for transmission.
The requestor may here specify that no response is
expected and the request is complete. If a response
is expected, the PROT ̲CONT module awaits the arrival
and hands back the buffer to the requestor. From now
on the requestor is in charge of the buffer (e.g. for
cancel processing) and the PROT ̲CONT module executes
next request.
4.1.5.8.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The PROT ̲CONT is called via one of the following entries:
INITIALIZE ̲PROT ̲CONT (PARAM: OPEN ̲SUBDEVICE ̲PARAM)()
REQUEST ̲PROT ̲CONT (QEL: IO ̲QEL,
PRIORITY: PRIORITY ̲TYPE)
(CC: COMPLETION ̲CODE,
BUFFER ̲REF: POINTER)
NOTIFY ̲PROT ̲CONT ̲OUTPUT ̲BUFFER (BUFFER ̲REF: POINTER)()
NOTIFY ̲PROT ̲CONT ̲OF ̲RESPONSE (BUFFER ̲REF: POINTER)()
SEND ̲PROT ̲CONT (RESPONSE: BOOLEAN,
SIZE: INTEGER)()
CANCEL ̲PROT ̲CONT (QEL: IO ̲QEL)()
CLEAN ̲PROT ̲CONT()()
The PROT ̲CONT module calls the following functional
entries of other modules:
USER ̲PROT ̲CONT ̲RESULT (QEL: IO ̲QEL, BUFFER ̲REF: POINTER)()
CONTROLLER ̲PROT ̲CONT ̲RESULT (QEL: IO ̲QEL,BUFFER ̲REF:POINTER)()
PROTOCOL ̲PROT ̲CONT ̲RESULT (QEL:IO ̲QEL,BUFFER ̲REF:POINTER)()
NOTIFY ̲USER ̲PROT ̲CONT ̲BUFFER (QEL:IO ̲QEL,BUFFER ̲REF:POINTER)()
NOTIFY ̲CONTROLLER ̲PROT ̲CONT ̲BUFFER (QEL:IO ̲QEL, BUFFER
̲REF:
POINTER)()
NOTIFY ̲PROTOCOL ̲PROT ̲CONT ̲BUFFER (QEL:IO ̲QEL,BUFFER
̲REF:
POINTER)()
Furthermore:
PROTOCOL ̲ERROR
ACTIVATE ̲SPI
QUEUE ̲PRIORITIZED
QUEUE
INIT ̲QD
EXTRACT ̲FIRST
EXTRACT ̲SPECIFIED
4.1.5.8.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 ̲PROT ̲CONT
CLEAN ̲PROT ̲CONT
R̲e̲q̲u̲e̲s̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
REQUEST ̲PROT ̲CONT
CANCEL ̲PROT ̲CONT
SEND ̲PROT ̲CONT
P̲a̲r̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NOTIFY ̲PROT ̲CONT ̲OUTPUT ̲BUFFER
NOTIFY ̲PROT ̲CONT ̲OF ̲RESPONSE
C̲o̲m̲p̲o̲n̲e̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
R̲e̲q̲u̲e̲s̲t̲o̲r̲ ̲n̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
RETURN ̲PROT ̲CONT ̲BUFFER
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
NEXT ̲PROT ̲CONT
RELEASE ̲PROT ̲CONT ̲BUFFER
PROC ̲FOR ̲END ̲OF ̲PROT ̲CONT
