2needed by an experiment H.break R.literal \ Data analysis f Calibration/Testing p Run control z Error logging  (+ program development) .end literal .skip might be distributed in any possible way between the available machines, depending on the specific needs of the experiment.  The distribution of these functions arbitrarily and flexibly requires the use of the link (a half-duplex communications device) in a full duplex fashion. It may also require that the link be 'shared' between several different 'tasks' or applications in one machine. The very act of interconnecting machines itself generates further uses of the link - file transfer, message broadcasts, central error reporting, etc. immediately become desirable features.  For this reason, ^&for an RSX system\& a Communications driver has been envisaged. This will allow several applications to use and share the link in a controlled way. See IN-57 for design details.  However the overhead involved in performing a system I/O request for $^&each message\& to be transferred across the link is high (1.6-2.0 ms) ., and in case a) conflicts with the goals of high rate, low dead-time 8data acquisition. BSo, in cases where such 'fast' data acquisition is the Lprimary goal, a mechanism needs to be provided for temporarily giving Vdedicated use of the link to the software responsible for: `.break j.literal t ~ - transmitting the data from a DA machine to a concatenation one  - receiving and assembling the data from one or more DA machines  ready to be logged on tape  .end literal  Such a mechanism has been discussed in DS-68, and IN-57, for an RSX system.  We cannot definitely say what types of machines will be used in a particular connected configuration, or which operating systems each of the machines will use. Therefore ^&it is desirable to define the basic protocol by which messages are transferred over the link\&, regardless of which piece of software may be responsible for the transfer: a driver, a dedicated process, or  The needs are different however. The dedicated use of the link for a single function, with a well defined set of rules (e.g. between the Event receiver and the Event transmitter), is a considerably (simpler environment in which to define an adequate protocol 2than that of using the <link for a multitude of different functions. FIn the latter case the various higher level protocols between the Pcommunicating entities are unknown, and so cannot be utilised, Zfor example in assumptions about error recovery procedures. dIn what follows we attempt to define a protocol suitable for nboth environments. x.page .hl 1 USE OF THE DR11W AS A DIRECT DATA LINK The DR11W is a general purpose UNIBUS DMA device. A DR11W on one UNIBUS can be connected to another DR11W by means of a suitable interface cable, not exceeding 50ft. Data transfers are 16 bit word (parallel transfer) in either a programmed I/O (single word) mode or in a DMA mode. The DMA may be on a 2 cycle (standard) per bus grant, termed block mode; or on N cycles per bus grant termed burst mode. Burst mode is not supported for a VAX/DR11W link.  The DR11W uses six programmable registers .literal  WCR - Word count register (read/write)  BAR - Bus address register (read/write)  IDR/ODR- Input/Output data register (read/write)  CSR/EIR- Control and status register (write only)  Error and Information register (read only) ".end literal , The DR11W may interrupt the processor, provided this interrupt 6capability is enabled @ The DR11W hardware is described in Digital's " DR11W JDirect Memory Interface Module User's guide". T When the DR11W is used as a link device to interconnect machines ^the actual communication between the linked systems is established hthrough manipulation of some of the CSR bits of the DR11W. rSetting and clearing of bits 1-3 in one DR11W causes setting |and clearing of some corresponding bits of the CSR of the partner DR11W. By this means one machine may indicate which mode of data transfer it wishes to use and may interrupt the partner machine. The ODR functions as a write-only register for data transmitted to the other computer.  The link operates in a half duplex communications mode; i.e. it has the capability of transmitting data bi-directionally, but in only one direction at a time.  Each computer has independent control of its own DR11W, so that the pieces of software in each computer, which are responsible for data transfer over the link, must be compatible, i.e. They must have suitable agreements about which of them is manipulating the relevant 'connected' bits of the CSR at any time; which is interrupting the other next. They must ensure that suitable word counts are set up for DMA operation and that the DMA is properly synchronised. &It is this 0^&protocol\&, at the level of transmission of a single message :over the link, which is described in the following sections. DWhat is described is the protocol between the two pieces of software N(link managers) controlling the DR11W , in order to transmit a Xsingle packet of data, or single message. bIt is not necessarily the end-to-end protocol between any 2 lprocesses in the two machines which wish to communicate over the vlink. Two processes which communicate using the DR11W-link driver, or Communications driver, will use a higher level protocol described in the Communications Driver documentation. We assume that we will be using a 'layered' approach in using the link, in which higher level protocol(s) between processes must be clearly defined. The link transmission protocol provides a limited set of functions, which are summarised below. Other levels of protocol will have to provide the required retries, checking that they do not have the same request twice, data integrity checks, insurances against lockout and deadly embrace situations etc. .hl 2 PROTOCOL DESIGN CRITERIA .ls .le;Data blocks of any type of data, and arbitrary number of 16 bit words (up to 32K maximum) may be transferred on the link in either direction. .le;There will be no check on the integrity of the data block, i.e. no checksum or CRC. Although not ideal, this is in keeping with the general level of data integrity in a data acquisition environment, *where CAMAC, and often memory, have no parity. Applications needing 4to ensure data integrity must put suitable checks into their higher >level protocol. For example, file transfer utilities would probably Himplement file checksums. R.le;It should be possible to transfer data \by a direct DMA from end-user buffer fto end-user buffer, for high speed and low CPU usage. p.le;The link transmission protocol will be considered to be zapplicable only to DR11W transmission on UNIBUS machines. .le;Although a final goal of flexible and transparent use of the link for any purpose should be kept in mind, it should not compromise the need for a fairly 'light' low level protocol, for use in the event transmission. Here the choice is between extra DMA(s) between partners for each block of data to be sent, or single word data transfers and handshakes. .le;The protocol should allow for adequate distinction between real hardware errors, and software/timing problems and should permit knowledge of the type of error encountered to be given to the partner. It should not however attempt error recovery. Each end of the link knows only that the message was either sent successfully or failed, with a reason. The handling of retries, and problems that  retries bring such as detecting duplicate requests is the responsibility  of the higher level protocol.  .le;The link transmission protocol will only be used in cases $ of directly connected transmitters and receivers (no route-through). . .le;The hardware will be assumed to be relatively error-free (unlike 8 a longer-range serial link). Although all errors due to intermittent B hardware errors, persistent hardware errors or software bugs must L be handled, they will be assumed to be fairly rare events. V .els ` .page j .hl 1 SINGLE WORD DATA TRANSFERS ON THE LINK t Single 16 bit data words are transferred between machines for all ~ control and status information. The sender of such information writes it to his output data register and informs the partner by interrupting him. 16 bit data words are used for .literal - requests to the partner - ACKS and NACKS - End-of-Message status returns - Word Counts - Single data word messages - SIGNALS .end literal In general a single data word exchanged between machines has the following format: .break .skip ^&High Byte\&  .break  .literal ( - control information 2 Bit 7 - NOTWC - If clear data word is a word count < 6 - PTC - If set data byte is a packet type code F 5 - ACK - If set data byte is an ACK or NACK of PTC or WC P 6 - EOM - If set data byte is the end-of-message status Z 3 - REQLK - If set sender is requesting the link d 2 - START - If set sender is requesting to start or re-start n the protocol x 1 - SIGNAL- If set data byte is a Signal 0 - DELAY- If set sender request partner to delay before starting to transmit next message .end literal ^&Low byte\& .break .literal If NOTWC bit of high byte is set the low byte is a data byte with a value between 0 and 255. If the SIGNAL bit is set the data byte may take any value between 0 and 255. Otherwise the value of the data byte is restricted to certain legal limits depending on the control byte. 1-7 ACKS and NACKS  1 - PTC ACK  2 - PTC NACK  3 - START ACK " 4 - WC NACK , 5 - LINK ACK 6 8-31 End-of-message error statuses @ 32 End-of-message - success code J 0-255 Packet type codes. T ^ .end literal h The use of the data word in this way serves two purposes r .ls | .le;Provides some degree of security against corrupt codes and statuses. Relationships between the allowable bits of the control byte exist and correct correlation between the data byte value and the control byte information can be checked. An end-of-message status can not be transformed from a success to a failure or vice-versa without the addition of one bit and the removal of another bit. .le;Allows status codes to be combined with request. In particular request for link mastership or request for restart of protocol or request to delay next message transmission can be combined with an end-of-message status. .els  .hl 1 STARTING THE LINK PROTOCOL  .literal  & Initiator 0 Start Protocol : ==============> D N Start protocol ACK X <============== b .end literal l The link protocol must be started whenever a link controller wishes v to initialise, or to resynchronise with its partner after an error in the protocol. This starting of the protocol also establishes a primary/secondary relationship between the partners. The initiator sends a single word Start-protocol code and interrupts its partner. It then waits to receive an acknowledge of protocol startup The receiver of a start-protocol code, who is not itself waiting for a start-protocol acknowledge will send a single word start protocol acknowledge code and interrupt its partner. It then considers the protocol to be active and itself as the secondary machine. When the initiator receives the Start-protocol-acknowledge it also considers the protocol to be active, and itself to be the  primary machine. In the case where both partners attempt to start the protocol  simultaneously, one or both will receive a start request when waiting for a start acknowledge. Each ignores the request and * retries after a ^&random delay\& 4 Until the next start-protocol code is sent by one of the partners > the primary/secondary relationship remains in effect and determines H which machine gains mastership of the link in a conflict case. R .hl 1 TRANSMITTING A SINGLE MESSAGE \ .hl 2 MESSAGE FORMAT f Each message consists of a single data packet and a packet type. p A data packet may contain up to 32K 16 bit words. z The sender of a message must initiate the transfer. The protocol for the transfer of messages over the link comprises 4 phases: .break .ls .le;Initiation - to gain mastership of the link for the sender .le;Sending of a packet type code (PTC) .le;Sending of a single data word which is either a Word count (N) for a DMA to follow, or a single word message, termed a Signal. .le;Optionally a block transfer (DMA) of N data words. .els There are acknowledgements in all phases. .hl 2 INITIATION .literal   Transmitter Receiver $ Request Link . ==============> 8 B Link ACK L <============== V.end literal ` The transmitter bids for mastership of the link by transmitting ja single word, in word mode, and interrupting the receiver. t The receiver grants mastership of the link to the transmitter by ~sending a single word acknowledge code, in word mode, and interrupting the transmitter.  If the receiver is in any state other than IDLE or attempting to itself gain mastership of the link, when it receives the request for link mastership, then it will return an error status to the transmitter together with a request to re-start the protocol.  If the transmitter does not receive the link acknowledge within a specified time limit, or receives an unexpected code it terminates its bid and the request for the link will be eventually retried.  If both computers bid for mastership of the link at the same, or nearly the same time, then one or both requesting mastership. Then the primary machine will ignore the request and the secondary machine will back-down from its bid and send a link ACK code to its (partner. 2 Once the initiation phase has been successfully completed <then phase 2 of the transfer may proceed. F.hl 2 SENDING OF A PACKET TYPE CODE P.literal Z d Transmitter Receiver n Packet type code (PTC) x ==============>   PTC ACK or PTC NACK  <============== .end literal  The packet type code is a simple form of packet header. It contains routing information.  The transmitter sends a single data word to the receiver,which describes the packet type.(PTC)  PTC's are symbolically defined in the macro prefix file DR11WDEF.MAC and in a Fortran Include file.  The PTC contains the information by which the receiver may decide whether or not to allow the transfer of data to take place. How this information is used is really a function of the higher level protocol between communicating processes. On the level of transmission protocol it need not be used at all, other than "checking for validity , If the receiver is prepared to accept the data, 6it acknowledges @the PTC by sending a single word PTC acknowledge Jcode and interrupting the transmitter. T If the receiver is not prepared to accept data from the transmitter ^then it sends a single word NACK of the PTC hand interrupts the transmitter. This terminates the message transfer rwith an error condition, for both transmitter and receiver. | If either the receiver or the transmitter does not recieve the expected PTC, or PTC acknowledge within a certain time, it times out and considers the message transmission terminated with an error condition.  If either receiver or transmitter receives a request or status code other than that expected, it also terminates the message transmission with an error condition.  In both cases of error the terminator sends a single word end-of-message error code together with a request for restart of the protocol. .hl 2 SEND WORD COUNT OR SIGNAL .literal   Transmitter Receiver  Word count or Signal  ==============>  & Receiver's Word count or Signal ACK 0 or WC NACK : <============== D.end literal N Once the willingness of the receiver to accept data from the Xtransmitter has been established, an agreement must be made babout the amount of data to be sent. l The transmitter sends a single data word and interrupts the receiver. vThis data word may be one of two possible indications: .ls .le;A word count for the DMA data transfer which will follow .le;A single word message or 'Signal' .els  All positive values of the data word are word counts.  All negative values of the data word are interpreted as Signals and must therefore conform to the format for Signals They are thus distinguishable from link request codes, packet type codes, and various acknowledge codes.  When a Word count has been passed to the receiver it must be followed by either an acknowledgement, or a refusal (WC NACK).  In the normal transfer case, the receiver sets up the DR11W DMA ready to receive data and then sends, as an acknowledgement, its receiver word count to the transmitter, and interrupts the transmitter. The receiver's word count is sent as a single word data transfer and is a positive value not exceeding the transmitter's word count. * If a signal had been passed to the receiver then it must acknowledge 4receipt of the signal, thus terminating the message transfer. > Both a Signal Acknowledge and a Word count NACK are given by Hsending a single word end-of-message status code, Iin word mode, and interrupting Rthe transmitter. \ If either receiver or transmitter times-out on waiting for fa word count or word count acknowledge, or receives any invalid pdata word then the message transfer terminates with an error zcondition. A request to restart the protocol is sent to the partner {together with an end-of-message status error code. .hl 2 DMA TRANSFER OF DATA .literal   Transmitter Receiver  N data words  -------------->   End-of-message status  <===============   .end literal When the transmitter has received a WC acknowledge, it may then actually start the DMA of data from its output buffer.  The receiver has already set up its DMA from the DR11W into its input data buffer and so the DMA will proceed. $ When the receiver DMA ends (or times out) the receiver sends a .single word End-of-message status and interrupts the transmitter. 8Because of the nature of the DR11W device, an interrupt to the Btransmitter which arrived before the end of DMA interrupt had Lbeen serviced by the transmitter would be lost. The transmitter Vmust be aware of this possibility and check the input data register `for an end-of-message code immediately before clearing the interrupt. j The receiver is free to immediately try to gain mastership of the tlink to transmit, after sending the end-of-message status code. ~Since the interrupt request for link mastership could similarly arrive before the end-of-message status interrupt has been handled, the receiver must always retransmit the end-of-message status together with the link request. This combined request can in fact be sent straightaway at end-of-message by the receiver, if it already knows that it will need to transmit. Alternatively the end-of-message status can be combined with a delay request, if the receiver wishes to hold off further messages from the transmitter whilst it performs other functions. .hl 1 SYNCHRONISATION OF TRANSMITTER AND RECEIVER  Each end of the link transmission protocol is a state machine with 11 possible states. .s 1 .literal  -1 Waiting for protocol start  0 IDLE  1 Requesting link ( 2 Waiting for PTC 2 3 Waiting for PTC ACK < 4 Waiting for WC or Signal F 5 Waiting for Receiver WC or WC NACK P 6 Waiting for end-of-message (or Signal) status Z 7 Transmitting d 8 Receiving n.end literal o.s 1 xThe state transitions are initiated by 'events' occurring. These are either a DR11W interrupt, or a time-out on waiting for an interrupt. In the protocol, the occurrence of any event other than the one expected in a particular state causes an abandonment of the current message transfer by that partner, with an error condition. If the unexpected event is a timeout or the receipt of any single word code other than a re-start protocol request then an error status code combined with a restart request is sent to the partner.  If the unexpected event is the receipt of a re-start-protocol request (with some end-of-message status code) then the situation procedes as for the Link Start Protocol procedure.  It can be seen that the resynchronisation mechanism is to restart the protocol whenever there is an unexpected error in the protocol, informing the partner in doing so of what error was detected by you. After sending a re-start-protocol request, the link is in the state of Waiting-to-start-protocol. Persistent "failures to receive a start-protocol acknowledge will result in ,the link being put in the state 'link down'. 6 In every state one possible "event" ^&MUST\& be a time-out occurring. @ All transitions back to the IDLE state imply termination of the Jmessage transfer. The transmiter and receiver may independently Treturn to the IDLE state in one of the following conditions: ^.ls h.le;all data transferred successfully r.le;some or all data transferred but with error. |.le;no data transferred - error condition. .els .skip   All transitions back to the link DOWN state imply termination of the message in a condition where either hardware or software failure has caused complete failure of the protocol, necessitating a resynchronisation by restarting the protocol.  The overall timeout for a transmitter should normally be longer than that of a receiver. This is to ensure that a receiver who is unable to receive a message informs the transmitter of this with a suitable WC NACK, before the transmitter times out. This case is then not a failure in the protocol, only a normal failure to deliver a message. .hl 1 State diagrams  The transitions between states of a process controlling link data transfer are shown diagramatically in Figs 1,2 and 3. &Receipt of interrupt or timeout is indicated by a single arrow, 0Sending of data to the partner is indicated by double arrows. :.break;OTHER indicates that an event other than the ones on the Dalternative event lines has occurred. This may be a time-out or Nany other not expected interrupt. X.page Y.title b.hl 1 START OF TRANSMISSION AND INTERRUPT HANDLER FLOW CHARTS l These show in detail how the state transitions are handled as vwell as how the actual transmission of data and interrupting of the partner is carried out. .lm 23 .rm 53 .c ;^&Initiating a DR11W Transmit Operation\& .s 2 .c ;Start .c ;| .c ;| Raise processor priority high enough to prevent DR11W interrupts .c ;| .c ;| .c ;-----<----------------DR11W state = idle ?###################### .c ;| .c ;####| yes .c ;Start transmit timer .c ;| .c ;| *Load link-request-code into DR11W output data register 4.c ;| >.c ;| H.c ;DR11W state <- waiting-for-link-acknowledge R.c ;| \.c ;| f.c ;CSR-template <- FNCT1 p.c ;! z.c ;! .c ; .c ;| .c ;| .c ;Lower processor priority .c ;| .c ;| .c ;Exit .s 4 .c ;----->--------------------------################################ .c ;! .c ;Lower processor priority .c ;| .c ;| .c ;Try again later .page .c ;^&DR11W Interrupt Service Routine\& $.s 1 ;(Executed at a processor priority high enough to prevent .additional DR11W interrupts) 8.c ;| B.c ;| L.c ; V.c ;! `.c ;! j.c ;Start t.c ;| ~.c ;| .c ;-----<----------------DR11W state = idle ?###################### .c ;| .c ;####| yes .c ;###########DR11W input data reg. = request-link-code ?---> ERROR .c ;| .c ;####| yes .c ;DR11W output data reg. <- link-acknowledge-code .c ;| .c ;| .c ;DR11W state <- waiting-for-packet-type-code .c ;| .c ;| .c ;! .c ;! .c ;Start receive timer (.c ;| 2.c ;| <.c ; F.c ;| P.c ;| Z.c ;Exit d.s 4 n.c ;----->--------------------------################################ x.c ; | .c ;-----<----DR11W state = waiting-for-link-acknowledge ?########## .c ;| .c ;####| yes .c ;#########DR11W input data register = link-acknowledge-code ? --> ERROR .c ;| .c ;####| yes .c ;DR11W output data reg. <- packet-type-code .c ;| .c ;| .c ;DR11W state <- waiting-for-packet-type-code-ack. .c ;| .c ;| .c ;CSR-template <- FNCT1 .c ;! .c ;! .c ; ".c ;| ,.c ;| 6.c ;Exit @.s 4 J.c ;----->--------------------------################################ T.c ; | ^.c ;-----<--DR11W state = waiting-for-packet-type-code-ack. ?####### h.c ;| r.c ;####| yes |.c ;########DR11W input data reg. = packet-type-code-ack-code ?--> ERROR .c ;| .c ;####| yes .c ;DR11W output data reg. <- transmit word count .c ;| .c ;| .c ;-----<----------Transmit word count < 0 ?################# .c ;| .c ;###| no .c ;DR11W state <- waiting-for-end-of-message status code .c ;| .c ;| .c ;CSR-template <- FNCT1 .c ;! .c ;! .c ; .c ;| &.c ;| 0.c ;Exit :.s 4 D.c ;----->-----------------------############################# N.c ;! X.c ;DR11W state <- waiting-for-word-count-acknowledge b.c ;| l.c ;| v.c ;CSR-template <- FNCT1 .c ;! .c ;! .c ; .c ;| .c ;| .c ;Exit .s 4 .c ;----->--------------------------################################ .c ; | .c ;---<--DR11W state = waiting-for-end-of-message status code###### .c ;| .c ;####| yes .c ;########DR11W input data reg. = end-of-message status code ?-> ERROR .c ;| .c ;####| yes .c ;Cancel receive timer .c ;| *.c ;| 4.c ;DR11W state <- idle >.c ;| H.c ;| RIndicate to program that transmission has been successfully completed \.c ;| f.c ;| p.c ;Exit z.s 4 .c ;----->--------------------------################################ .c ; | .c ;--<----DR11W state = waiting-for-word-count-acknowledge ?####### .c ;| .c ;####| yes .c ;#######DR11W input data reg. = valid receivers word count ?-> ERROR .c ;| .c ;####| yes .c ;Transmit word count <- DR11W input data reg. .c ;! .c ;! .c ;DR11W address reg. <- lower 16 bits of buffer address .c ;| .c ;| .c ;CSR-template <- upper two bits of buffer address .c ;| $.c ;| ..c ;DR11W word count reg. <- transmit word count 8.c ;| B.c ;| L.c ;DR11W state <- waiting-for-transmit-completion V.c ;| `.c ;| j.c ;CSR-template <- FNCT1 + FNCT3 + GO + CYCLE t.c ;! ~.c ;! .c ; .c ;| .c ;| .c ;Exit .s 4 .c ;----->--------------------------################################ .c ;! .c ;---<----DR11W state = waiting-for-transmit-completion ?######## .c ;| .c ;####| yes Are any DR11W error bits set or does the DR11W word count register contain a nonzero value ? .c ;| .c ;####| yes Indicate to the program that a transmission has been completed, but (that there was an error 2.c ;| <.c ;| F.c ;DR11W state <- waiting-for-end-of-message status code P.c ;| Z.c ;| d.c ;Exit e.s 3 f.c ;! i.c ;----->-----------------------############################# n.s 3 ;Indicate to program that a transmission has been successfully completed. .c ;| .c ;| .c ;DR11W state <- waiting-for-end-of-message status code .c ;| .c ;| .c ;Exit .s 4 .c ;----->--------------------------################################ .c ; | .c ;-----<----DR11W state = waiting-for-packet-type-code ?########## .c ;| .c ;####| yes .c ;Packet-type-code <- DR11W input data reg. .c ;| .c ;| ".c ;###########Is packet-type-code a legal value ? ---> ERROR ,.c ;! 6.c ;####! yes @.c ;-----<------Is packet-type-code acceptable ?############ J.c ;| T.c ;###! no ^.c ;Cancel receive timer h.c ;| r.c ;| |.c ;DR11W output data reg. <- packet-type-code-nak .c ;| .c ;| .c ;DR11W state <- idle .c ;! .c ;! .c ;########################-------------->------------ .s 2 .c ;----->----------------------############################ .c ;! .c ;DR11W output data reg. <- packet-type-code-ack .c ;| .c ;| .c ;DR11W state <- waiting-for-word-count  .c ;| .c ;########################--------------<------------  .c ;|  .c ;CSR-template <- FNCT1 & .c ;! 0 .c ;! : .c ; D .c ;| N .c ;| X .c ;Exit b .s 4 l .c ;----->--------------------------################################ v .c ;! .c ;---<---------DR11W state = waiting-for-word-count ?############# .c ;| .c ;####| yes .c ;word-count <- DR11W input data reg. .c ;| .c ;| .c ;---------------------word-count < 0 ?##################### .c ;| .c ;####| yes .c ;Cancel receive timer .c ;| .c ;| .c ;Signal <- word-count !.c ;| !.c ;| !.c ;DR11W state <- idle !.c ;| *!.c ;| 4!.c ;Inform program that a signal has been received >!.c ;| H!.c ;| R!.c ;DR11W output data reg. <- end-of-message code \!.c ;| f!.c ;| p!.c ;CSR-template <- FNCT1 z!.c ;! !.c ;! !.c ; !.c ;| !.c ;| !.c ;Exit !.s 4 ; !.c ;--->-----------------------############################# !.c ;! !Does the receiving program (for whatever reason) wish to !cancel the message transmission ? !.c ;---<-----------------------############################# !.c ;! !.c ;| ".c ;####| yes ".c ;Cancel receive timer ".c ;| $".c ;| .".c ;DR11W state <- idle 8".c ;| B".c ;| L".c ;DR11W output data reg. <- word-count-nak-code V".c ;| `".c ;| j".c ;CSR-template <- FNCT1 t".c ;! ~".c ;! ".c ; ".c ;| ".c ;| ".c ;Exit ".s 4 ".c ;--->-----------------------############################# ".c ;! ".c ;DR11W output data reg. <- receivers-word-count ".c ;| ".c ;| ".c ;DR11W address reg. <- lower 16 bits of buffer address ".c ;| #.c ;DR11W word count reg. <- word-count #.c ;| #.c ;| (#Set upper two address bits into CSR-template. 2#.c ;| <#.c ;| F#.c ;CSR-template <- FNCT1 + FNCT3 + GO P#.c ;| Z#.c ;| d#.c ;DR11W state <- waiting-for-receive-completion n#.c ;| x#.c ;| #.c ; #.c ;! #.c ;! #.c ;Exit #.s 4 #.c ;--------------------------------################################ #.c ;! #.c ;--<----DR11W state = waiting-for-receive-completion ?############ #.c ;| #.c ;####| yes #.c ;DR11W state <- idle #.c ;| #.c ;| $.c ;Cancel receive timer $.c ;| $.c ;| "$Are any DR11W error bits set or does the DR11W word count reg. ,$contain a nonzero value ? 6$.c ;---<-----------------------############################# @$.c ;| J$.c ;| T$Notify program that a receive has been completed, but ^$that there was an error h$.c ;#########################-------------->---------# r$.s 1 |$.c ;--->-----------------------############################# $.c ;! $.s 3 $Notify program that a receive has been successfully completed $.c ;#########################--------------<---------# $.c ;| $.c ;| $.c ;DR11W output data register <- end-of-message status code $.c ;! $.c ;! $.c ;CSR-template <- FNCT1 $.c ;! $.c ;! $.c ; $.c ;! $.c ;! $.c ;Exit $.s 4 $.c ;----->--------------------------################################ $.c ;! $.c ;-----<--------------DR11W state = link-down ?#################### $.c ;| $.c ;####| yes $.c ;###########DR11W input data reg. = start-protocol-code---> ERROR $.c ;| %.c ;####| yes %.c ;DR11W output data reg. <- start-acknowledge-code %.c ;| &%.c ;| 0%.c ;DR11W state <- waiting-for-start-protocol :%.c ;| D%.c ;| N%.c ;CSR-template <- FNCT1 X%.c ;! b%.c ;! l%.c ;Start initialisation timer v%.c ;| %.c ;| %.c ; %.c ;| %.c ;| %.c ;Exit %.s 4 %.c ;----->--------------------------################################ %.c ;! %.c ;##############DR11W state = waiting-start-protocol ? --> ERROR %.c ;| %.c ;####| yes %.c ;---<-----DR11W input data reg. = start-acknowledge-code ?####### %.c ;| %.c ;####| yes &.c ;DR11W state <- idle *&.c ;! +&.c ;---->---------------------------################################ ,&.c ;! 4&.c ;! >&.c ;Exit N.page *N.c ;^&Error condition\& 4N.c ;or ^&Transmit or Receive timer time out\& >N.s 3 HN.c ;| RN.c ;| \NPrint an error message or notify some program that an error fNhas occured pN.c ;| zN.c ;| N.c ;If the transmit timer had been started, cancel it N.c ;| N.c ;| N.c ;If the receive timer had been started, cancel it N.c ;| N.c ;| N.c ;DR11W state <- link-down N.c ;! N.c ;! N.c ;---<--DR11W input data register = restart-link-protocol code ?###### N.c ;! N.c ;####| yes N.c ;DR11W output data reg. <- start-acknowledge-code O.c ;! O.c ;! O.c ;CSR-template <- FNCT1 $O.c ;! .O.c ;! 8O.c ;DR11W state <- idle BO.c ;! LO.c ;! MO.c ;! NO.c ;! OO.c ;cancel initialisation timer VO.c ; `O.c ;! jO.c ;! tO.c ;Exit ~O.s 4 O.c ;--->----------------------------################################ O.c ;! O.c ;! O.c ;DR11W output data reg. <- end-of-message status + start protocol O.c ;! O.c ;! O.c ;DR11W state <- waiting-to-start-protocol O.c ;! O.c ;! O.c ;CSR-template <- FNCT1 O.c ;! O.c ;! O.c ;! O.c ;! P.c ;! P.c ;! P.c ;Exit (P.lm 0 .rm 80 *P.title DR11W as a link device - The Transmission Protocol 2P.page S.hl 2 Example Routines which manipulate the CSR bits HS The following two routines are examples of the routines used RSin the Flow charts of the previous section. \S.hl 3;Clear Interrupt and Check Errors fS.skip pS.literal zS; S; routine to reset the CSR after an interrupt, saving all S; relevant registers. S; S MOV CSR,CSRSAV ;save CSR contents S MOV CSRSAV,CSRTMP ; S BIS #ERROR,CSR ;write ERROR bit to read out EIR S MOV EIR,EIRSAV ;save EIR contents S; S; error condition can be analysed, either hardware error, non S; existent memory,parity, power fail or just ATTN bit set by partner S; can see which from the bits of the CSR and EIR S; can look at this now or later S; - now clear error condition T; T BIC #^C,CSRTMP ;clear all but T ;function and IE bit $T MOV IDR,IDRSAV ;save input data register .T MOV CSRTMP,CSR ;reset CSR 8T MOV CSR,CSRTMP ;read back CSR BT BIT #ERROR,CSRTMP ;check that error condition cleared LT BEQ 100$ VT; `T; else hard error, either try again to clear or signal error jT; and disable interrupt on DR11W - error exit tT; ~T100$: T.end literal T.skip 2 T.hl 3;Interrupt Partner DR11W T.literal T; T; on entry to this routine suitable FNCT1,FNCT3,,CYCLE and GO bits have T; been set up in CSRTMP for whatever operation is to be performed T; - a single word transfer T; - a DMA receive data set-up T; - a DMA transmit data T; T BIS #IE,CSRTMP ;interrupts enabled throughout U BIS #FNCT2,CSRTMP ;will set partners ATTN bit U BIC #,CSRTMP ;dont want to start yet, just U ;propagate function bits to partner (U MOV CSRTMP,CSR ;sets up FNCT bits and causes 2U ;ATTN bit of partner to be set