Interchip Serial Communications

Přidal: oprava  :  Kategorie: Sériové komunikace

Serial data links are not always restricted to long-distance communications.
Within a single computer system, or even a single circuit board, serial links can provide attractive bene?ts as compared to traditional parallel buses. Computer architectures often include a variety of microprocessor peripheral devices with differing bandwidth requirements. Main memory, both RAM and ROM, is a central part of computer architecture and is a relatively high-bandwidth element.
The fact that the CPU must continually access main memory requires a simple,high-bandwidth interface a parallel bus directly or indirectly driven by the CPU.
Other devices may not be accessed as often as main memory and therefore
have a substantially lower bandwidth requirement. Peripherals such as data
acquisition ICs (e.g., temperature sensors), serial number EEPROMs, or liquid crystal display (LCD) controllers might be accessed only several times each second instead of millions of times per second. These peripherals can be
directly mapped into the CPUs address space and occupy a spot on its parallel bus, but as the number of these low-bandwidth peripherals increases, the complexity of attaching so many devices increases.

FIGURE 5.17 Hypothetical network driver ?owchart.

OBR 5.17 Hypothetical network driver ?owchart.

Short-distance serial data links can reduce the cost and complexity of a computer system by reducing interchip wiring, minimizing address decoding logic, and saving pins on IC packages. In such a system, the CPU is connected to a serial controller via its parallel bus, and most other peripherals are connected to the controller via several wires in a bus topology as shown in Fig. 5.18.Such peripherals must be speci?cally designed with serial interfaces, and many are.

It is common for low-bandwidth peripheral ICs to be designed in both
parallel and serial variants. In fact, some devices are manufactured with only
serial interfaces, because their economics overwhelmingly favors the reduction in logic, wiring, and pins of a serial data link. A temperature sensor with a serial
interface can be manufactured with just one or two signal pins plus power.
That same sensor might require 16 or more signal pins with a byte-wide parallel
interface. Not only is the package cost re-duced, its greatly reduced size
enables the IC to be located in very con?ned spaces. Products including cell
phones and handheld computers bene?t tremendously from small IC packages
that enable small, consumer-friendly form factors.

FIGURE 5.18 Generic interchip serial bus topology.

OBR 5.18 Generic interchip serial bus topology.

Interchip serial interfaces must be kept fairly simple to retain their advantages of low cost and ease of use. Industry standard interfaces exist so that semiconductor manufacturers can incorporate mainstream interfaces into their ICs, and engineers can easily connect multiple manufacturers ICs
together without redesigning the serial interface for each application. Many
of these standard inter- faces are actually proprietary solutions, developed
by individual semiconductor manufacturers, that have gained wide acceptance.
Two of the most commonly used industry standards for interchip serial
communications are Philips inter-IC bus (I2c) and Motorolas serial peripheral interface (SPI). Both Philips and Motorola have long been leaders in the ?eldof small, single-chip computers called microcontrollers that incorporate microprocessors, small amounts of memory, and basic peripherals such as UARTs. It was therefore a natural progression for these companies to add inexpensive interchip serial data links to their microcontrollers and associated peripheral products.

I2C and SPI support moderate data rates ranging from several hundred kilobits to a few megabits per second. Because of their target applications, these networks usually involve a single CPU master connected to multiple slave peripherals. I2C supports multiple masters and requires only two wires, as compared to SPIs four-plus wires.

FIGURE 5.19 I2C open-collector schematic representation.

OBR 5.19 I2C open-collector schematic representation.

I2C consists of a clock signal, SCL, and a data signal, SDA. Both are open-collector signals, meaning that the ICs do not actively drive the signals high, only low. An open-collector driver is similar to a tri-state buffer, al-though no active high state is driven. Instead, the output is at either a low- or high-impedance state. The open-col-lector con?guration is schematically illustrated in Fig. 5.19. The term open-collector originates from the days of bipolar logic when NPN output transistors inside thechips had no element connected to their collectors to assert a logic high. This terminology is still used for CMOS logic, although open-drain is the technically correct term when working with MOSFETs.
A pullup resistor is required on each signal (e.g., SCL and SDA) to pull it to
a logic 1 when the ICs release the actively driven logic 0. This open-collector
arrangement enables multiple IC drivers to share the same wire without
concern over electrical contention.

Under an idle condition, SCL and SDA are pulled high by their pullup resistors. When a particular IC wants to communicate, it drives a clock onto SCL and a pattern of data onto SDA. SCL may be as fast as 100 kHz for standard I2C and up to 400 kHz for fast I2C buses. I2C is a real network that assigns a unique node address to each chip connected to the bus. As such, each transfer begins with a start sequence followed by seven-bit destination address. A read/write and data follow the address. There is a carefully dened
protocol that provides for acknowledgement of write transactions and returning data for read transactions. In a multimaster configuration, collision detection can be implemented along with an appropriate access arbitration algorithm.

I2C is implemented using only two wires, but this apparent simplicity belies its exibility. The protocol is rich in handling special situations such as multiple masters, slow slaves that cannot respond to requests at the masters SCL frequency, and error acknowledgements. Some manufacturers that incorporate I2C into their products pay Philips a licensing fee and are therefore able to use the trademark name in their documentation. Other manufacturers try to save some money by designing what is clearly an I2C interface but referring to it by some generic or proprietary name such as standard two-wire serial interface. If you come across such a product, spend a few minutes reading its documentation to make sure whether a true I2C interface is supported.

Motorolas SPI consists of a clock signal, SCK, two unidirectional data signals,
and multiple slave select signals, SS* as shown in Fig. 5.20. One data signal
runs from the master to each slave and is called MOSI: master-out, slave-in.
The other data signal is shared by the slaves to send data back to the master
and is called MISO: master-in, slave-out. SCK is always driven by the master
and can be up to several megahertz. Rather than assigning a unique address to
each slave, the master must assert a unique SS* to the particular device with
which it wants to exchange data. On observing SS* being asserted, a slave
loads the bits on the MOSI signal into an internal shift register. If a read is
being performed, the slave can reply with data shifted out onto the MISO
signal. Because MISO is shared by multiple slaves, they must implement some type of contention-avoidance mechanism such as tri-state or open-collector outputs.

Each of these interchip buses proves extremely useful in simplifying many
system designs. It is beyond the scope of this discussion to explain the detailed workings of either I2C or SPI. For more information, consult the technical resources available from Philips and Motorola on their web sites or in their printed data sheets.

FIGURE 5.20 SPI bus organization.

OBR 5.20 SPI bus organization.

podle : E-book Complete_Digital_Design

A Simple RS-485 Network

Přidal: oprava  :  Kategorie: Sériové komunikace
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, tlak, ?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.
jak je znázorněno, 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. Therefore, 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.
OBR 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, for example, 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. For example, 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. However, 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. For example, 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, for example, 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.
podle : E-book Complete_Digital_Design

RS-485

Přidal: oprava  :  Kategorie: Sériové komunikace
Whereas RS-232 and RS-422 enable point-to-point serial links, the RS-485standard enables multiple-node networks. Like RS-422, RS-485 providesdifferential signaling to enable communications across spans of twisted-pairwire exceeding 1.2 km. Unlike RS-422, the RS-485 standard allows upto 32 transmit/receive nodes on a single twisted pair that is terminated at eachend as shown in Fig. 5.14. Modern low-load receivers that draw very littlecurrent from the RS-485 bus can be used to increase the number of nodeson an RS-485 network well beyond the original 32-node limit to 256 nodesor more. A single pair of wires is used for both transmit and receive, meaningthat the system is capable of half-duplex (one-way) operation rather thanfull-duplex operation (both directions at the same time). Half-duplex operationrestricts the network to one-way exchange of information at any given time.When node A is sending a packet to node B, node B cannot simultaneouslysend a packet to node A.
RS-485 directly supports the implementation of bus networks. Bus topologiesare easy to work with, because nodes can directly communicate with eachother without having to pass through other nodes or semi-intelligent hubs.However, a bus network requires provisions for sharing access to be builtinto the network protocol. In a centralized arbitration scheme, a master nodegives permission for any other node to transmit data. This permission can bea request-reply scheme whereby slave nodes do not respond unless a requestfor data is issued. Alternatively, slave nodes can be periodically queried bythe master for transmit requests, and the master can grant permissions on anindividual-node basis. There are many centralized arbitration schemes thathave been worked out over the years.A common distributed arbitration scheme on a bus network is collision detectionwith random back-off. When a node wants to transmit data, it ?rst waits untilthe bus becomes idle. Once idle, the node begins transmitting data. However,when the node begins transmitting, there is a chance that one or more nodeshave been waiting for an opportunity to begin transmitting and that they willbegin transmitting at the same time. Collision detection circuits at each nodedetermine that more than one node is transmitting, and this causes all activetransmitters to stop. OBR 5.15 shows the implementation of an RS-485transceiver with external collision detection logic. A transmit enable signalexists to turn off the transmitter when the UART is not actively sending data.Unlike an RS-422 transmitter that does not have to share access with others,the RS-485 transmitter must turn itself off when not sending data to enableothers to transmit.

FIGURE 5.14 RS-485 bus topology.

OBR 5.14 RS-485 bus topology.

FIGURE 5.15 RS-485 collision detection transceiver.

OBR 5.15 RS-485 collision detection transceiver.
When transmitting, the receiver returns the logical state of the twisted-pair bus.If the bus is not at the same state as the transmitted data, a collision is mostlikely being caused by another transmitter trying to drive the opposite logicstate. An XOR gate implements this collection detect, and the XOR outputmust be sampled only after allowing adequate time for the bus to settle to astable state following the assertion of each bit from the transmitter.
Once a collision has been detected by each node and the transmitters aredisabled, each node waits a different length of time before retransmitting. Ifall delays were equal, multiple nodes would get caught in a deadlock situationwherein each node keeps trying to transmit after the same delay interval.Random back-off delays are pseudo-random so as to not unfairly burdensome nodes with consistently longer delays than other nodes. At the end ofthe delay, one of the nodes begins transmitting ?rst and gains control of thebus by default. The other waiting nodes eventually exit from their delaysand observe that the bus is already busy, indicating that they must wait theirturn until the current packet has been completed. If, by coincidence, anothernode begins transmitting at the same time that the ?rst node begins, theback-off process begins again. It is statistically possible for this processto occur several times in a row, although the probability of this being afrequent event is small in a properly designed network. A bus networkconstructed with too many nodes trying to send too much data at the sametime can exhibit very poor performance, because it would be quite proneto collisions. In such a case, the solution may be to either reduce the networktraf?c or increase the networks bandwidth.
podle : E-book Complete_Digital_Design