Z85233 Datasheet, PDF (268/317 Pages) Zilog, Inc. – The Zilog SCC Serial Communication Controller

Application Note
Technical Considerations When Implementing LocalTalk Link Access Protocol
Dynamic Node ID
The source node uses the physical layer to detect the
LLAP requires the use of an 8-bit node identifier number
(node ID) for each node on the link. Apple had decided that
all LLAP nodes must have a dynamically assigned node
ID. A node would assign itself its unique address upon
activation. It is then up to that particular node to ascertain
that the address it had chosen is unique. A node randomly
chooses an 8-bit address (for example, the refresh register
value on the Z80181 is added to a randomly chosen value
on the receive buffer to obtain a pseudo random 8-bit
address).
presence or the absence of data packets on the link. The
node will wait until the line is no longer busy before
attempting to send its packets. If the node senses that the
line is indeed busy, then this node must defer. When the
node senses that the line is idle, then the node waits the
minimum IDG plus some randomly generated time before
sending the packet (the line must remain idle throughout
this period before attempting to send the packet). The
initial packets to be sent are handshaking packets. The
first packet sent by the source node to its destination node
is the RTS packet. The receiver of this RTS packet must
1
The node then sends out an LLAP Enquiry control packet
to all the other nodes and waits for the prescribed
interframe gap of 200 µsec. If another node is already
return a CTS packet within the allowable maximum IFG.
The source node then starts transmitting the rest of its data
packet upon receiving this CTS.
using this node ID, then that node must respond within 200
µsec with a LLAP Acknowledgment control packet. The
new node must then rebroadcast a new guess for its node
ID. If a LLAP Acknowledgment packet is not received
within 200 µsec then the new node assumes that the
address is indeed unique. The new node must rebroadcast
the LLAP enquiry packet several more times to account for
cases when the packet could have been lost or when the
guessed node ID is busy and could have missed the
Enquiry packet.
Collisions are more likely to occur during the handshaking
phase of the dialog. The randomly generated time that is
added to the IDG tends to help spread out the use of the
link among all the transmitters. A successful RTS to CTS
handshake signifies that a collision did not take place. An
RTS packet that collides with another frame has corrupt
data that shows up as a CRC error on the receiving or the
destination node. Upon receiving this, the destination node
infers that a collision must have taken place and abstains
from sending its CTS packet. The source or the
LLAP Packet
transmitting node sees that the CTS packet was not
received during the IFG and also infers that a collision did
LLAP packets are made up of three header bytes _{take place. The sending node then backs off and retries.}
(destination ID, source ID and LLAP type) and 0 to 600
bytes of variable length data. The LLAP type indicates the The LLAP keeps two history bytes that log the number of
type of packet that is being sent. 80H to FFH are reserved deferrals and collisions during a dialog. These history
as LLAP control packets. The four LLAP control packets bytes help determine the randomly generated time that is
that are currently being used are: The lapENQ, which is added to the IDG. The randomly generated time is
used as enquiry packet for dynamic node assignments; readjusted according to the traffic conditions that are
the lapACK, which is the acknowledgment to the lapENQ; present on the link. If collisions or deferrals have just
the lapRTS, which is the request to send packet that occurred on the most recently sent packets, then it can be
notifies the destination of a pending transmission; and the assumed that the link has heavier than usual traffic. Here,
lapCTS, which is the clear-to-send packet in response to the randomly generated number should be a larger
the RTS packet. Control packets do not contain data fields. number in order to help spread out the transmission
attempts. Similarly, if the traffic is not so great, then the
LLAP Packet Transmission
randomly generated number should be smaller, thus
LLAP distinguishes between two types of transmissions: a ^{reducing the dispersion of the transmission attempts.}
directed packet is sent from the source node to a specific
destination node through a directed transmission dialog; a
LocalTalk Physical Layer
broadcast packet is sent from the source node to all nodes LocalTalk uses the SDLC format and the FM0 bit encoding
on the link (destination ID is FFH) through a broadcast technique. The RS-422 signalling standard for
transmission dialog. All dialogs must be separated by a transmission and reception was chosen over the RS-232
minimum Inter Dialog Gap (IDG) of 400 µsec. Frames because a higher data rate over a longer physical distance
within these dialogs must be separated from each other is required. LocalTalk requires signals at 230.4 Kbits per
with a maximum Inter Frame Gap (IFG) of 200 µsec.
second over a distance of 300 meters.
UM010901-0601
6-133