semi合集-English.pdf - 第1043页

SEMI E4-0699 © SE MI 1980, 1999 5 5.4 Retry Limit, RTY — The retry l i mit, RTY, is the maximum number of time s the Block T ransf er Protocol will attempt to retry sending a block before declaring a failed s e nd. (See …

SEMI E4-0699 © SEMI 1980, 1999 4

3.3 Data Rate — The supported data rates on signal

pins shall be 9600, 4800, 2400, 1200, and 300 baud.

The same data rate shall apply for data sent to and from

the equipment. The data rate shall be controlled to

better than 0.5%. (See RS-269-B and RS-334.) Optional

rates of 19,200 and 150 baud may be supplied if

desired.

3.4 Physical Medium — The connection with the host

may involve any medium that provides the required RS-

232-C quality, signal levels and data rate at the equip-

ment connector. The quality of signal should be such

that the effective bit error rate is less than 1 × 10

-6

. This

rate can be achieved easily with hardwired systems.

The distance limits specified in RS-232-C apply only to

systems using the wiring technique described in RS-

232-C. Since any method may be used in SECS-I as

long as RS-232-C signals are supplied at the connector,

the distance and isolation is dependent upon the design

of the physical medium which is external to the SECS-I

standard. (See Related Information R1-2.)

4 Character Structure

4.1 Characters — Data will be transmitted or received

in a serial bit stream of 10 bits per character at one of

the specified data rates. The standard character has one

start bit (0), 8 data bits and one stop bit (1). All bit

transmissions are of the same duration. The 8 data bits

are numbered from 1 to 8 in the order sent (see Figure

1). The timing between characters is asynchronous with

respect to the data rate. The 8 data bits may be any

arbitrary code. The eight data bits will hereafter be

referred to as a byte.

Figure 1

Character Structure

4.2 Weighted Codes — For bytes having weighted

codes, bit one is the least significant and bit eight is the

most significant. The most common weighted code is

binary.

4.3 Non-Weighted Codes — For codes without

numeric value such as ASCII, the bit numbers will be

used as the entry into a standard code table for

interpretation of the code. SECS-I performs no parity or

other verification of the contents of individual bytes.

5 Block Transfer Protocol

5.1 The procedure used by the serial line to establish

the direction of communication and provide the

environment for passing message blocks is called the

block transfer protocol. Most of the protocol is

accomplished with a handshake of single bytes. When

both ends of the line try to send at the same time, a

condition known as line contention exists. The protocol

resolves contention by forcing one end of the line,

designated as the slave (always the host), to postpone

its transmission and enter the receive mode.

Retransmission of blocks is used to correct

communication errors. The block transfer protocol is

shown in flow chart form in Figure 2, and described

below. Additional information is also contained in

Related Information R1-3 and R1-4.

5.2 Handshake Bytes — The four standard handshake

codes used in the block transfer protocol are shown in

Table 2. The three letter names, ENQ, EOT, ACK, and

NAK correspond to the ASCII code having the same

pattern.

Table 2 Handshake Codes

Name Codeb8

b7.........b1

Function

ENQ 00000101 Request to Send

EOT 00000100 Ready to Receive

ACK 00000110 Correct Reception

NAK 00010101 Incorrect Reception

5.3 Timeout Parameters — Timeouts are used to de-

tect communications failures. A timeout occurs when

the measured time between two events exceeds a pre-

determined limit. Generally, the length of time that

must pass before it can be assumed that an error has oc-

curred depends upon the particular systems involved.

The time required in one situation might be excessively

long in another. Thus, the timeout values must be

"tuned" to meet the application. In the block transfer

protocol, there are two situations requiring timeout val-

ues. The two timeout values are called parameters T1

and T2.

5.3.1 Inter-Character Timeout, T1 — The inter-

character timeout, T1, limits the time between receipt of

characters within a block after the length byte has been

received and until the receipt of the second checksum

byte.

5.3.2 Protocol Timeout, T2 — The protocol timeout,

T2, limits the time between sending ENQ and receiving

EOT, sending EOT and receiving the length byte, and

sending the second checksum byte and receiving any

character.

SEMI E4-0699 © SEMI 1980, 19995

5.4 Retry Limit, RTY — The retry limit, RTY, is the

maximum number of times the Block Transfer Protocol

will attempt to retry sending a block before declaring a

failed send. (See Section 5.8.2.)

5.5 Master/Slave — The master/slave parameter is

used in the resolution of contention (see Section 5.8.2).

The host is designated as the slave. The equipment is

desig-nated as the master. This convention is based

upon the assumption that the equipment is less able to

store messages than the host.

5.6 Block Lengths — The unsigne d integer value of

the first byte sent after receipt of EOT is the length of

the block being sent. The length includes all the bytes

sent after the length byte, excluding the 2 bytes of the

checksum. The maximum block length allowed by

SECS-I is 254 bytes, and the minimum is 10 bytes.

5.7 Checksum — The checksum is calculated as the

numeric sum of the unsigned binary values of all the

bytes after the length byte and before the checksum in a

single block. The checksum is sent as 16 bits in two

bytes following the last byte of the block data. The high

order eight bits of the checksum will be sent first,

followed by the low order eight bits. The checksum is

used by the receiver to check for transmission errors.

The receiver performs the same checksum calculation

on the received header and data.

5.8 Algorithm — The operation of the block transfer

protocol is best understood by following the logic flow

in Figure 2. This flow chart depicts the operation of the

five states of the protocol - Receive, Idle, Send Line

Control, and Completion. The flow chart shown in Fig-

ure 2 is not meant to imply that a particular implemen-

tation is required under this standard. However, any

SECS-I block transfer protocol implementation must in-

clude all the logic described in Figure 2. The same

algorithm is executed on each end of the SECS-I

communications link.

5.8.1 Idle State — Both ends of the communications

link are assumed to start in the Idle state. There are two

primary activities of the protocol signified by the two

exits from the Idle state. These are:

A. SEND — a message block is to be sent.

B. RECEIVE — the other end of the communications

link has a message block to send

5.8.2 Line Control — The line control section estab-

lishes the transmission direction, resolves contention,

and handles retries. When an ENQ is received in the

Idle state, the Line Control responds with an EOT if the

Block Transfer Protocol is ready to receive. The Block

Transfer Protocol then goes to the Receive state. If a

message block is to be sent, then an ENQ is sent. If an

EOT is received in response to the ENQ within the time

limit T2, the Block Transfer Protocol goes to the Send

state.

5.8.2.1 If the slave receives an ENQ in response to the

ENQ, contention has occurred. The slave postpones the

send of its block until it receives a block from the

master. The slave prepares to receive the incoming

block and sends an EOT. When the block transfer

protocol returns to the Idle state, the postponed block

Send may be sent as if it were a new send request. After

a master sends an ENQ, it can ignore all characters

except an EOT. After a slave sends at ENQ, it can

ignore all characters except an ENQ or EOT.

5.8.2.2 When the time between sending ENQ and

receiving EOT exceeds T2, or the time between sending

the second checksum byte and receiving any character

exceeds T2, or a non-ACK character is received within

time T2 after sending the second checksum byte, the

Line Control will increment the retry count ("tries" in

the flowchart). If the retry count does not exceed the

value of the RTY parameter, then the Block Transfer

Protocol will retry sending the block beginning with

ENQ. If the retry count does exceed the value of the

RTY parameter, then a failed send has occurred.

5.8.3 Send — Once a send state is established, the first

byte sent is the length, N, of the data in the block. After

N more bytes have been sent, the two bytes of the

checksum are sent. The sender computes the checksum

based on the data in the block and the block header, but

not the length byte. When the sender receives the ACK

before time T2, the block is deemed properly sent.

However, if the sender receives a non-ACK character

before time T2, or no character within time T2, it

returns to the line control state for a possible retry. In

the Send state, characters received prior to sending the

last checksum byte can be ignored.

5.8.4 Receive — Once a receive state is established,

the first byte received is the length byte, N. The

receiver counts and saves the following N + 2 bytes.

The last two bytes are the checksum. The receiver

compares the two checksum bytes against its own

computation of the checksum. In a good block, the

computed and received checksum are the same.

5.8.5 Receive Completion — After a block is correctly

received, an ACK character is sent and the message

protocol is notified that a block has been received. If T2

is exceeded while waiting for the length character, or Tl

is exceeded between characters being received, then an

NAK is sent. If the length byte is invalid or if the re-

ceived checksum does not agree with the computed

checksum, the receiver continues to listen for characters

to ensure that the sender is finished sending. This is

detected when the inter-character time exceeds T1, at

which point the receive is aborted and a NAK is sent. In

any case when an NAK is sent, the receiver may dis-

card any data it has received for the block. The receiver

returns immediately to the Idle state after sending an

ACK or NAK.

5.8.6 Send Completion — After the second checksum

byte is sent, if an ACK is received within time T2, the

message protocol is notified that the send was success-

ful. If a failed send occurs, the message protocol is in-

formed of the failure. Application-level software must

take the possibility of a send failure into account.

Figure 2

Block Transfer Protocol