Prill 13, 2010
A Simple RS-485 Network
Postuar nga: riparim : Kategori: Komunikimet Serial
An example of a simple but effective network implemented with RS-485 servesas a vehicle to discuss how packet formats, protocols, and hardware converge toyield a useful communications medium. The motivation to create a custom RS-485network often arises from a need to deploy remote actuators and data-acquisitionmodules in a factory or campus setting. A central computer may be located in afactory of?ce, and it may need to periodically gather process information (e.g.,temperature, pressure, ?uid-?ow rate) from a group of machines. Alternatively,a security control console located in one building may need to send securitycamera positioning commands to locations throughout the campus. Suchapplications may involve a collection of fairly simple and inexpensivemicroprocessor-based modules that contain RS-485 transceivers. Dependingon the exact physical layout, it may or may not be practical to wire all remotenodes together in a single twisted-pair bus. If not, a logical bus can be formedby creating a hybrid star/bus topology as shown in Fig. 5.16. A central hubelectrically connects the individual star segments so that they function electricallyas a large bus but do not require a single wire to be run throughout the entirecampus.
As shown, the hub does not contain any intelligent components it is a glori?ed junction box. This setup is adequate if the total length of all star segments does not exceed 1.2 km, which is within the electrical limitations of the RS-485 standard. While simple, this setup suffers from a lack of fault tolerance. If one segment of the star wiring is damaged, the entire network may cease operation because, electrically, it is a single long pair of wires. Both the distance and fault-tolerance limitations can be overcome by implementing an active hub that contains repeaters on each star segment and smart switching logic to detect and isolate a broken segment. A repeater is an active two-port device that ampli?es or regenerates the data received on one port and transmits it on the other port. An RS-485 repeater needs a degree of intelligence, because both ports must be bidirectional. Prandaj, the repeater must be able to listen for traf?c on both sides, detect traf?c on one side, and then transmit that traf?con the other side. A hub that detects and isolates segment failures would bewell designed to report this fault information to a central control node to alertthe human operator that repairs are necessary. These possible improvementsin the network hub do not affect the logical operation of the network and,consequently, are not a focus of this discussion.
Figura 5.16 Hybrid star/bus network topology.
With a topology chosen and a general application in mind, the next step is todecide on the networks operational requirements from among the following:
1. Support for roughly 200 nodes provides ?exibility for a variety of controlapplications.2. Central arbitration handled by master control node for simplicity of network design. A facility control network is often a master-slave application, because all data transfers are at the request of the central controller. Central arbitration removes the need for collision-detect hardware and random back-off algorithms.3. Broadcast capability enables easy distribution of network status information from the master control node.4. Data rate of 9600 bps provides adequate bandwidth for small controlmessages without burdening the network with high frequencies that can lead to excessive noise and signal degradation.5. Basic error handling prevents processing incorrect data and network lock-up conditions when occasional noise on the RS-485 twisted-pairs causes data bits to change state.
Many aspects of network functionality are directly in?uenced by a suitablenetwork packet format. Other aspects are addressed by the protocol thatformats data on the network, by the transceiver and UART hardware, or bya combination of these three elements.In considering the packet format, 8-bit destination and source addresses arechosen to support more than 200 nodes on the network. A special destinationaddress value of 0xFF represents a broad-cast address, meaning that allnodes should accept the packet automatically. Such broadcast packets areuseful for system-wide initialization whereby, p.sh., the control computercan send the current time to all nodes. This multicast address cannot be usedas a normal node address, thereby limiting the network to 255 unique nodes.
It is desirable to employ variable-length packets so that a message does nothave to be longer than necessary, thereby conserving network bandwidth.Variable-length packets require some mechanism to determine the length:either reserved framing codes or an explicit length count. A length count ischosen to keep the system simple. Framing codes would require that certaindata values be off limits to the contents of the message. The payload length isbounded at a convenient binary threshold: 255 bytes. For simple control anddata-acquisition applications, this is probably more than enough.
Based on these basic requirements and a couple of quick decisions, a packetformat quickly emerges. A three-byte, ?xed-length header shown in Table 5.4is followed by a variable-length payload. No trailer is necessary in this network.
The eight-bit destination address ?eld, DA, comes ?rst to enable the receivinghardware to quickly determine whether the packet should be accepted by thenode or ignored. A packet will be accepted if DA matches the receivers nodeaddress, or if DA equals 0xFF, indicating a broadcast packet. At the end ofthe header is an eight-bit length ?eld that indicates how many payload bytes arepresent after the ?xed-length header. This limits the maximum packet size to255 payload bytes plus the 3-byte header. A value of zero means that thereis no payload, only a header in the packet.
Error detection can be handled by even parity. Each byte of the header andpayload is sent with an accompanying parity bit. When an error is detected,the networks behavior must be clearly de?ned to prevent the system from either ceasing to function or acting on false data. Parity errors can mani- festthemselves in a variety of tricky ways. p.sh., if the length ?eld has aparity error, how will the receiver know the true end of the frame? Withoutproper planning, a parity error on the length ?eld can permanently knock thereceivers out of sync and make automatic recovery impossible. This extremesituation can occur when an invalid length causes the receiver to either skipover the next frame header or prematurely interpret the end of the currentframe as a new header. In both cases, the receiver will falsely interpret abogus length ?eld, and the cycle of false header detection can continueinde?nitely.
If a parity error is detected on either the destination or source addresses, thereceivers will not lose synchronization, but the packet should be ignored,because it cannot be known who the true recipient or sender of the packet is.Fault tolerance in the case of an invalid payload length can be handled in arelatively simple manner. Requirements of no intrapacket gaps and a minimuminterpacket gap assist in recovery from length-?eld parity errors. The absenceof intrapacket gaps means that, once a packet has begun transmission, its bytesmust be continuous without gaps. Related to this is the requirement of a minimuminterpacket gap which forces a minimum idle period between the last byte of onepacket and the start of the next packet. These requirements help each receiverdetermine when packets are starting and ending. Even if a packet has beensubjected to parity errors, the receiver can wait until the current burst of traf?chas ended, wait for the minimum interpacket gap, and then begin looking forthe next packet to begin.
The parity error detection and accompanying recovery scheme greatly increases the probability that false data will not be acted upon as correct data and that the entire network will not stop functioning when it encounters an arbitrary parity error. megjithatë, error detection is all about probability.
A single parity bit cannot guarantee the detection of multiple errors in the samebyte, because such errors can mask themselves. p.sh., two bit errors can?ip a data bit and the parity bit itself, making it impossible for the receiver todetect the error. More complex error detection schemes are available andare more dif?cult to fool. Although no error detection solution is perfect,some schemes reduce the probability of undetected errors to nearly zero.
If a packet is received with an error, it cannot be acted upon normally, because its contents are suspect. For the purposes of devising a useful error-handling scheme, packet errors can be divided into two categories: those that corrupt the destination/source address information and those that do not. Parity errors that corrupt the packets addresses must result in the packet being completely ignored, because the receiving node is unable to generate a reply message to the originator indicating that the packet was corrupted. If the source address is corrupted, the receiver does not know to whom to reply. If the destination address is corrupted, the receiver does not know whether it is the indented recipient.
In the case of an address error in which the received packet is ignored, theoriginator must imple- ment some mechanism to recover from the packet loss rather than waiting inde?nitely for a reply that will never arrive. A reply timeout can be implemented by an originator each time a packet is sent that requires a corresponding reply. A timeout is an arbitrary delay during which an originating node waits before giving up on a response from a remote node.Timeouts are common in networks because, if a packet is lost due to an error,the originator should not wait inde?nitely for a response that will never come.Establishing a timeout value is a compromise between not giving up too quickly and missing a slower-than-normal reply and waiting too long and introducing unacceptable delays in system functionality when a packet is lost. Depending on the time it takes to send a packet on a network and the nodes typical response time, timeouts can range from microseconds to minutes. Typical timeouts are often expressed in milliseconds.
When an originator times-out and concludes that its requested data somehowgot lost, it can re- send the request. If, p.sh., a security control nodesends a request for a camera to pan across a room, and that request is notacknowledged within half a second, the request can be retransmitted. In thecase of a non-address error, the receiving node has enough information tosend a reply back to the originator, informing it that the packet was notcorrectly received. Such behavior is desirable to enable the originator toretransmit the packet rather than waiting for a timeout before resendingthat data.
The preceding details of a hypothetical RS-485 network must be gatheredinto network driver software to enable proper communication across the network.While hardware controls the detection of parity errors and the ?ow of bits, it isusually software that generates reply messages and counts down timeouts.Figure 5.17 distills this information into a single ?owchart from which softwarerou-tines could be written.
As seen from this ?owchart, transmit and receive processes run concurrently and are related. The transmit process does not complete until a positive acknowledgement is received from the destina- tion node. This network control logic implemented in software is simple by mainstream networking standards, yet it is adequate for networks of limited size and complexity. Issues such as access sharing are handled inherently by the request/reply nature of this network, greatly simplifying the traf?c patterns that must be handled by the software driver.
As shown, the hub does not contain any intelligent components it is a glori?ed junction box. This setup is adequate if the total length of all star segments does not exceed 1.2 km, which is within the electrical limitations of the RS-485 standard. While simple, this setup suffers from a lack of fault tolerance. If one segment of the star wiring is damaged, the entire network may cease operation because, electrically, it is a single long pair of wires. Both the distance and fault-tolerance limitations can be overcome by implementing an active hub that contains repeaters on each star segment and smart switching logic to detect and isolate a broken segment. A repeater is an active two-port device that ampli?es or regenerates the data received on one port and transmits it on the other port. An RS-485 repeater needs a degree of intelligence, because both ports must be bidirectional. Prandaj, the repeater must be able to listen for traf?c on both sides, detect traf?c on one side, and then transmit that traf?con the other side. A hub that detects and isolates segment failures would bewell designed to report this fault information to a central control node to alertthe human operator that repairs are necessary. These possible improvementsin the network hub do not affect the logical operation of the network and,consequently, are not a focus of this discussion.
Figura 5.16 Hybrid star/bus network topology.
With a topology chosen and a general application in mind, the next step is todecide on the networks operational requirements from among the following:
1. Support for roughly 200 nodes provides ?exibility for a variety of controlapplications.2. Central arbitration handled by master control node for simplicity of network design. A facility control network is often a master-slave application, because all data transfers are at the request of the central controller. Central arbitration removes the need for collision-detect hardware and random back-off algorithms.3. Broadcast capability enables easy distribution of network status information from the master control node.4. Data rate of 9600 bps provides adequate bandwidth for small controlmessages without burdening the network with high frequencies that can lead to excessive noise and signal degradation.5. Basic error handling prevents processing incorrect data and network lock-up conditions when occasional noise on the RS-485 twisted-pairs causes data bits to change state.
Many aspects of network functionality are directly in?uenced by a suitablenetwork packet format. Other aspects are addressed by the protocol thatformats data on the network, by the transceiver and UART hardware, or bya combination of these three elements.In considering the packet format, 8-bit destination and source addresses arechosen to support more than 200 nodes on the network. A special destinationaddress value of 0xFF represents a broad-cast address, meaning that allnodes should accept the packet automatically. Such broadcast packets areuseful for system-wide initialization whereby, p.sh., the control computercan send the current time to all nodes. This multicast address cannot be usedas a normal node address, thereby limiting the network to 255 unique nodes.
It is desirable to employ variable-length packets so that a message does nothave to be longer than necessary, thereby conserving network bandwidth.Variable-length packets require some mechanism to determine the length:either reserved framing codes or an explicit length count. A length count ischosen to keep the system simple. Framing codes would require that certaindata values be off limits to the contents of the message. The payload length isbounded at a convenient binary threshold: 255 bytes. For simple control anddata-acquisition applications, this is probably more than enough.
Based on these basic requirements and a couple of quick decisions, a packetformat quickly emerges. A three-byte, ?xed-length header shown in Table 5.4is followed by a variable-length payload. No trailer is necessary in this network.
The eight-bit destination address ?eld, DA, comes ?rst to enable the receivinghardware to quickly determine whether the packet should be accepted by thenode or ignored. A packet will be accepted if DA matches the receivers nodeaddress, or if DA equals 0xFF, indicating a broadcast packet. At the end ofthe header is an eight-bit length ?eld that indicates how many payload bytes arepresent after the ?xed-length header. This limits the maximum packet size to255 payload bytes plus the 3-byte header. A value of zero means that thereis no payload, only a header in the packet.
Error detection can be handled by even parity. Each byte of the header andpayload is sent with an accompanying parity bit. When an error is detected,the networks behavior must be clearly de?ned to prevent the system from either ceasing to function or acting on false data. Parity errors can mani- festthemselves in a variety of tricky ways. p.sh., if the length ?eld has aparity error, how will the receiver know the true end of the frame? Withoutproper planning, a parity error on the length ?eld can permanently knock thereceivers out of sync and make automatic recovery impossible. This extremesituation can occur when an invalid length causes the receiver to either skipover the next frame header or prematurely interpret the end of the currentframe as a new header. In both cases, the receiver will falsely interpret abogus length ?eld, and the cycle of false header detection can continueinde?nitely.
If a parity error is detected on either the destination or source addresses, thereceivers will not lose synchronization, but the packet should be ignored,because it cannot be known who the true recipient or sender of the packet is.Fault tolerance in the case of an invalid payload length can be handled in arelatively simple manner. Requirements of no intrapacket gaps and a minimuminterpacket gap assist in recovery from length-?eld parity errors. The absenceof intrapacket gaps means that, once a packet has begun transmission, its bytesmust be continuous without gaps. Related to this is the requirement of a minimuminterpacket gap which forces a minimum idle period between the last byte of onepacket and the start of the next packet. These requirements help each receiverdetermine when packets are starting and ending. Even if a packet has beensubjected to parity errors, the receiver can wait until the current burst of traf?chas ended, wait for the minimum interpacket gap, and then begin looking forthe next packet to begin.
The parity error detection and accompanying recovery scheme greatly increases the probability that false data will not be acted upon as correct data and that the entire network will not stop functioning when it encounters an arbitrary parity error. megjithatë, error detection is all about probability.
A single parity bit cannot guarantee the detection of multiple errors in the samebyte, because such errors can mask themselves. p.sh., two bit errors can?ip a data bit and the parity bit itself, making it impossible for the receiver todetect the error. More complex error detection schemes are available andare more dif?cult to fool. Although no error detection solution is perfect,some schemes reduce the probability of undetected errors to nearly zero.
If a packet is received with an error, it cannot be acted upon normally, because its contents are suspect. For the purposes of devising a useful error-handling scheme, packet errors can be divided into two categories: those that corrupt the destination/source address information and those that do not. Parity errors that corrupt the packets addresses must result in the packet being completely ignored, because the receiving node is unable to generate a reply message to the originator indicating that the packet was corrupted. If the source address is corrupted, the receiver does not know to whom to reply. If the destination address is corrupted, the receiver does not know whether it is the indented recipient.
In the case of an address error in which the received packet is ignored, theoriginator must imple- ment some mechanism to recover from the packet loss rather than waiting inde?nitely for a reply that will never arrive. A reply timeout can be implemented by an originator each time a packet is sent that requires a corresponding reply. A timeout is an arbitrary delay during which an originating node waits before giving up on a response from a remote node.Timeouts are common in networks because, if a packet is lost due to an error,the originator should not wait inde?nitely for a response that will never come.Establishing a timeout value is a compromise between not giving up too quickly and missing a slower-than-normal reply and waiting too long and introducing unacceptable delays in system functionality when a packet is lost. Depending on the time it takes to send a packet on a network and the nodes typical response time, timeouts can range from microseconds to minutes. Typical timeouts are often expressed in milliseconds.
When an originator times-out and concludes that its requested data somehowgot lost, it can re- send the request. If, p.sh., a security control nodesends a request for a camera to pan across a room, and that request is notacknowledged within half a second, the request can be retransmitted. In thecase of a non-address error, the receiving node has enough information tosend a reply back to the originator, informing it that the packet was notcorrectly received. Such behavior is desirable to enable the originator toretransmit the packet rather than waiting for a timeout before resendingthat data.
The preceding details of a hypothetical RS-485 network must be gatheredinto network driver software to enable proper communication across the network.While hardware controls the detection of parity errors and the ?ow of bits, it isusually software that generates reply messages and counts down timeouts.Figure 5.17 distills this information into a single ?owchart from which softwarerou-tines could be written.
As seen from this ?owchart, transmit and receive processes run concurrently and are related. The transmit process does not complete until a positive acknowledgement is received from the destina- tion node. This network control logic implemented in software is simple by mainstream networking standards, yet it is adequate for networks of limited size and complexity. Issues such as access sharing are handled inherently by the request/reply nature of this network, greatly simplifying the traf?c patterns that must be handled by the software driver.
afër : E-book Complete_Digital_Design
