semi合集-English.pdf - 第1042页
SEMI E4-0699 © SE MI 1980, 1999 4 3.3 Data Rate — The su pported d a ta rates on sign al pins shal l be 9600, 4800, 24 00, 120 0, and 300 bau d. The same data rate shall appl y for data sent to and from the equipment. Th…
SEMI E4-0699 © SEMI 1980, 19993
2.1.27 primary/secondary attribute — the least signifi-
cant bit of the lower message ID which indicates
whether a block belongs to a primary or secondary
message.
2.1.28 R-bit — a bit in the header signifying the
direction of the message. (See Section 6.2.)
2.1.29 receiver — the end of the SECS-I link
receiving a message. (See Section 5.8.4.)
2.1.30 reply — the particular secondary message
corresponding to a primary message. (See Section 7.3.)
2.1.31 reply linking — the process of forming a
transaction out of a primary and a secondary message.
(See Section 7.3.1.)
2.1.32 retry count — the number of unsuccessful
attempts to send a block in the block transfer protocol.
(See Section 5.4.)
2.1.33 RTY — the retry limit or the number of times
the block transfer protocol will attempt to retry sending
a block before declaring a failed send. (See Section
5.4.)
2.1.34 secondary message — a message with an even
numbered message ID. Also the second message of a
transaction. (See Section 6.5.2.)
2.1.35 sender — the end of the SECS-I link sending
message. (See Section 5.8.3.)
2.1.36 slave — the block transfer designation for the
host (See Section 5.5.)
2.1.37 system bytes — a 4-byte field in the header
used for message identification. (See Section 6.8.)
2.1.38 T1 — receive inter-character timeout in the
block transfer protocol. (See Section 5.3.1.)
2.1.39 T2 — protocol timeout in the block transfer
protocol. (See Section 5.3.2.)
2.1.40 T3 — reply timeout in the message protocol.
(See Sections 5, 7.3.2)
2.1.41 T4 — inter-block timeout in the message
protocol. (See Section 7.4.3.)
2.1.42 transaction — a primary message and its
associated secondary message, if any. (See Section 7.3.)
2.1.43 W-bit — a bit in the header signifying that a
reply is expected. (See Section 6.4.)
3 Coupling
3.1 Coupling refers to the physical interface at the
equipment. The host will provide compatible signals at
this point. No restrictions are implied for any interface
other than for equipment covered by this standard.
3.2 Electrical Interface — The connection will include
a serial interface according to EIA Standard RS-232-C
for interface Type E, full duplex communication,
modified by the deletions, additions and exceptions
described in this section.
3.2.1 Connector — Either the 9-pin or 25-pin
connector described in the EIA RS232 may be used. In
the case of the 25-pin connector a female connector will
be mounted on the equipment and a male connector will
be mounted on the cable from the host. In the case of
the 9-pin connector the male connector will be mounted
on the equipment and a female connector will be
mounted on the cable. The connector on the equipment
will have female 4-40 threaded jack screw locks.
NOTE: Suitable 25-pin connectors known as Type "D" are
similar to Amphenol MIN RAC 17 series with jack screw
locks. Suitable 9-pin connector is also Type "D" with
jackscrew locks. It is the type commonly implemented on
desktop and notebook PCs.
3.2.2 Signal Pins — Pins on the connector have
functions as defined in Table 1. Pins 1, 2, 3, and 7 of
the 25-pin connector or pins 3, 2, and 5 of the 9-pin
connector are required for all equipment complying
with SECS-I. When using a 25-pin connector, the two
power supply pins, 18 and 25, are optional as indicated.
Any other pins, if used, shall comply with the RS-232-
C standard.
Table 1 Signal Connections
25-
Pin
9-Pin RS-232-C
Circuit
Circuit Description
1-- AA Shield
2 3 BA Data from Equipment
3 2 BB Data to Equipment
7 5 AB Signal Ground
18 -- -- +12 to +15 volts (opt for
the 25-pin connector)
25 -- -- -12 to -15 volts (opt for
the 25-pin connector)
3.2.3 Logic Levels — For the signal pins 2 and 3, the
logic 1 level will be a voltage less than -3 volts and the
logic 0 level will be a voltage greater than +3 volts.
Voltages will never exceed ± 25 volts. These values
correspond to those specified by the RS-232-C
standard.
3.2.4 Power Supplies — When using a 25-pin
connector, pins 18 and 25 are optional power supplies
for driving external isolation circuits. When provided,
both shall be present and must be able to supply at least
50 mA. (See Related Information R1-2 for example
use.)
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