Networking is increasingly becoming a feature of industrial and commercial systems, such as those for medical and security mon- itoring fire detection, pro-cess and HVAC (heating, ventilation, and air-conditioning) control, and retail POS (point-of-sale) transaction entry. Because many such systems depend on minimal embedded-control hardware, mainstream networking approaches are often too complex or expensive.
The prevalence of Ethernet in offices notwithstanding, asynchronous serial ports and their associated UARTs can form the basis for networks of embedded systems. The low cost of the hardware is the main reason for basing embedded-system networks on UARTs. Adding Ethernet or Arcnet to an embedded controller usually requires installing two or more complex ICs or hybrids. However, most microcontrollers include UARTs and require only a transceiver or modem. By using a UART-based network, you can tailor the network-protocol software to the application, making the software as complex as you wish. When an embedded processor has no available UART, you can add a UART IC at a relatively low cost. Or, if circuit-board space is limited, you can implement the UART in software.
However, compared with other networking technologies, UART-based network protocols do have some potential disadvantages. The devices operate more slowly, with typical speeds of less than 200 kbps. The UARTs provide significantly less network capability than Ethernet or Arcnet chip sets. To implement any useful communication via UARTs, you must supply software, and the µP must execute it; Ethernet and Arcnet chip sets often avoid the need for additional software. Finally, in most cases, processor interrupts occur more often.
System designers considering UART-based networking schemes often ask whether they can use any industry-standard network protocols with UARTs and whether those protocols work in embedded systems. The answer is, "yes, but...". So far, attempts to standardize network protocols have been largely industry-specific. For example, several "fieldbus" standards are under development; one is being developed for HVAC, another for networking audio equipment, and another for plastics manufacturing. Some of these "standard" protocols could use UARTs, and some require other hardware. However, most are not complete, and how widely they will be adopted isn't clear. Several widely used proprietary protocols also use UARTs; however, none of them has a commanding share in a particular industry.
This situation leaves system designers with a dilemma: UART-based networks are cost-effective for embedded systems, but the lack of standard networking protocols means that designers of UART-based networks can't simply rely on techniques developed by others. A wise choice of technology requires an understanding of the issues involved in evaluating and designing networks based on several technologies. Studying UART-based networks is worthwhile for another reason: Many of the issues related to such networks also apply to networks that use different technologies.
A network is a shared communication channel. To communicate with one another, the interconnected computers (network nodes) must follow some rules concerning which node can transmit at which time. If the messages transmitted over the network are to be intelligible, their syntax and semantics must conform to a set of rules. These rules, along with electrical and physical interconnection specifications, constitute a network protocol.
The Open Systems Interconnection (OSI) reference model provides a standard framework for specifying network protocols. The OSI scheme divides network functions and services into seven layers, in which the upper layers use lower layer services to perform specific tasks. Various organizations, including IEEE, ANSI, ECMA (Electronic-Computer Manufacturers' Association), CCITT (Consultative Committee on International Telephone and Telegraph), and ISO, have proposed protocols that fit the OSI model. These protocols specify the functions of particular layers at some length but do so in abstract terms, leaving the implementation details to users and OEMs supporting the protocols.
Most UART protocols in embedded systems are simpler than the network protocols that form the basis for the OSI reference model. Usually, the functions described by UART protocols correspond to the physical, data-link, and application layers of the OSI model (Fig 1).
The UART-protocol application layer provides services of interest to application programmers. In data acquisition, an application-layer service might let an operator workstation read a remote temperature sensor. The application layer uses data-link-layer services to send and receive packetized network messages. The physical layer deals with the actual communication medium. A review of the function of the OSI model's layers offers an insight into how protocols operate. A good place to start is with the lowest layer-the physical layer.
UARTs generate a serial digital signal consisting of two values: MARK (usually TTL high) and SPACE (TTL low). The physical layer must specify how these values are represented on the network. The interface between a UART and the network can be as simple as a TTL open-collector buffer in an "inside-the-box" network (one that never leaves a single piece of equipment). A special line transceiver or modem that generates an amplified signal appropriate for the chosen communication medium is more common. Table 1 presents a partial list of signaling standards and methodologies often used with UART protocols.
For the designer of a relatively simple UART protocol for embedded systems, the data-link layer usually presents the most challenges. The data-link layer conveys messages, usually packetized, between network nodes, on behalf of a simple protocol's application layer (or a more complex protocol's upper layers). A data-link-layer specification must include
Before considering the roles of these elements, think about the role of the application layer.
Whereas the data-link layer performs a task not unlike that of a package-delivery service, the application layer is responsible for the application-specific message content. Familiar Internet application protocols that function within the application layer include SMTP (Simple Message Transfer Protocol), FTP (File Transfer Protocol), and Telnet (for remote log-in). Embedded-systems application protocols generally have different uses. For example, process-control applications would more likely use a network to perform such functions as reading sensors, turning pumps on and off, and operating valves. In short, developers add value to their products by customizing protocols for specific applications.
You can think of an application layer in terms of the services it provides and uses. Service providers are called "servers"; devices or processes that use network services are called "clients." Unlike office networks, in which clients usually outnumber servers, embedded-system networks usually have more servers than clients. Services can be simple, such as reading a single binary sensor. A more complex service might allow changing the control-loop parameters of automation equipment. Event-oriented services are useful: A server sends a message to a client when a situation occurs. Typical clients are operator workstations and autonomous controllers that monitor or control multiple devices. A single device can provide and use network services.
Another useful concept is that of the network object. Network objects are fundamentally similar to objects in object-oriented languages and add a powerful level of abstraction to network-protocol design. A network object is a data structure that lets you treat some part of a device as a higher level control object instead of as a collection of registers, buffers, and other logical elements. This approach makes protocol design more complex but more flexible (Ref 1).
You can take two approaches to application-layer design. One approach involves defining concise messages that have specific meanings (for example, "read sensor #2''). The other approach uses shared memory. Each network node has a block of memory; other nodes can read from and write to this memory using network commands. Of course, you must define how each type of device uses the memory block. Some standards committees (for example, SP50 of the ISA-Instrument Society of America, and SPC135 of the American Society of Heating, Refrigerating, and Air-Conditioning Engineers-ASHRAE) take a more ambitious approach. Each organization is attempting to build protocols that are industry-specific and flexible. The goal is to promote true interoperability among different vendors' products. The BACnet protocol is an example (see box, "What on earth is BACnet?").
When designing an application layer, you should consider your future needs. Designing a simple application-layer protocol to meet the needs of one project isn't difficult, but designing a protocol that ages gracefully takes some thought. For example, if you will need to connect new or upgraded devices, you should at least include commands for inquiring about a node's type and capabilities.
Network traffic is divided into discrete packets, each of which is a string of characters. In UART protocols, the packets and the characters have particular formats.
Figure 2 illustrates a packet structure that some UART networks use. This packet structure works with a half-duplex master-slave protocol within a UART-based, 9-bit RS-485 multidrop network. One node acts as the master, and the other nodes function as slaves. Slaves communicate with the master only when the master initiates communication. Slaves cannot talk directly to other slaves. This simple network design suits multiple embedded controllers in limited applications.
A packet is a serial data stream with a predetermined format. The sequence of data in the packet begins with 1 byte to identify the slave by its address. A control byte is next, followed by the message and the error-detection data. The protocol defines the packet construction, transmission, and reception as the duty of the data-link layer. Application-layer messages go into the data subfield of the packet's information field. The error-detection scheme appends a 16-bit CRC (cyclic-redundancy-check) value to each packet. Slaves discard any packet in which they detect a data-transmission error. If the slave's acknowledgment does not arrive within a suitable period, the master retransmits the packet. A 1-bit sequence number identifies duplicate transmissions.
When transmitting a character, a UART sends synchronization signals in the form of start and stop bits. In some cases, there is a parity bit. In UART-based embedded-system networks, the most common character formats use 8 or 9 data bits, no parity, and 1 stop bit. When you choose a character format, you must consider the capabilities of the UARTs you connect to the network, the nature of the data, and the packet-delimiting method.
Sometimes, these requirements conflict. For example, suppose you want to transmit arbitrary 8-bit data, but the character format has fewer than 8 data bits. In this situation, you could convert each 8-bit character into its two-digit hexadecimal equivalent, and transmit each 8-bit character as two ASCII characters, each representing one digit. You might also consider UUencoding, a more efficient technique used to encode 8-bit binary data into 7-bit ASCII text for inclusion in Internet e-mail messages. UUencoding converts groups of three successive 8-bit binary characters into four 6-bit characters, which map into decimal ASCII characters 32 through 95.
| Table 1 -- Major characteristics of several common protocols | |
|---|---|
| Signaling method | Description |
| RS-232C (V.28) | For low-speed, short-distance point-to-point links |
| RS-422 (V.11) | Uses differential signaling for higher speeds and longer distances |
| RS-485 | Similar to RS-422; allows up to 32 network nodesto be connected to each cable segment (multidrop); most commonly used in data-acquisition and distributed-control applications |
| Bell 103, Bell 202, | Used by telephone modems V.32, etc |
| RF modems | Bell 202 and other standards |
| Fiber optic | Standards vary |
| IR | Standards vary |
As mentioned, the characters in a packet form several groups, called "fields." As in a database record, each field contains a particular type of information. The fields typically found in a packet in the data-link layer are
The first field must identify the node being addressed. Network addresses are necessary for networks of more than two nodes. In some polling protocols, if the other node is always known, a packet may contain only one node address.
The second field is found in most protocols and contains information that the data-link layer uses for flow control and error recovery. If these tasks are not the responsibility of the data-link layer, you can omit this field.
The third field can be the largest in the packet. The data comprise a message (or part of a message) generated by an upper protocol layer, such as the application layer. In some protocols, certain packets may not have a data field. In any case, the contents of this field do not concern the data-link layer.
The checksum or CRC field is used for detecting transmission errors. You'll find a detailed discussion of this topic later in this article.
A network protocol should have some method for identifying the beginning and end of each packet. The appropriate method depends on the format of the information within the packet. Generally, some symbol indicates the beginning of a packet, and, in most cases, another symbol marks the end of a packet. To avoid confusion, these delimiting symbols should not appear elsewhere in a packet.
As an example, assume that all of the information to be transmitted consists of ASCII text. Of the 128 ASCII characters, two traditionally function as packet-delimiting symbols: STX (start of text) indicates the beginning of a packet, and ETX (end of text) denotes the end of a packet. Because no packet contains any other STX or ETX characters (normal text does not), the delimiting scheme is simple: STX and ETX can be unambiguously interpreted as packet delimiters.
But, if you want to send arbitrary 8-bit binary data using an 8-bit character format and you choose STX and ETX as delimiters, you run into an ambiguity problem: You can't tell whether an ETX character signifies the end of the packet or represents data within the packet. Fortunately, there are several solutions to this problem.
A popular method of delimiting packets uses special character sequences at the beginning and end of the packet. Assume that the packet must contain arbitrary data patterns. In that case, the beginning- and end-of-packet sequences could appear in the packet interior and be misinterpreted as packet delimiters. IBM's Bisync (BSC) protocol (Refs 3 and 8) provides one solution to this problem.
A simplified version of Bisync's packet delimiting involves placing the DLE character (ASCII 16) before the flow-control characters, STX and ETX. The two-character sequence, DLE STX, represents the beginning of a packet; DLE ETX represents the end. Within the packet, all characters are transmitted without modification, except for ASCII 16, which is transmitted as the two-character sequence DLE DLE. Consequently, assuming a 7-bit character format, a packet can use 130 symbols, three of which comprise two characters (start-of-packet, end-of-packet, and ASCII 16) and 127 of which consist of a single character (ASCII 0 to 15 and 17 to 127).
By design, some protocols can tolerate packet-delimiter character sequences within packets. Such protocols usually use a packet-length field for finding the end of the packet, and an error-checking field (CRC or checksum). If the packet passes the error check, any packet delimiters within the packet are interpreted as data. The sample packet of Fig 2 was designed for a 9-bit protocol where the ninth bit indicates the beginning of the packet. The packet design uses a data-subfield length number to indicate the end of the information field. The 16-bit CRC serves as the error-checking mechanism for validating the packet.
You can also use a break signal, SPACE, as a packet delimiter, for at least one character at a time. (This is SPACE as in MARK and SPACE; not ASCII 32, the SPACE character.) Note: Not all UARTs can generate and detect a break signal. Therefore, this approach imposes hardware restrictions on the system design.
Another non-character-based delimiting method is to enforce an idle period of a certain minimum duration between packets. This approach requires some kind of timing mechanism. Moreover, the software must assure that, within packets, no idle periods occur that are long enough to appear as interpacket intervals. The UART hardware of Motorola 6800-series µCs supports this delimiting method. Motorola documentation calls the feature "idle-line wake- up".
A simple delimiting method that is popular in µC network protocols uses a 9-bit character format. The protocol uses a ninth bit, sometimes called the address bit, exclusively to indicate the first character of a packet. In some protocols, the ninth address bit also indicates the last character. The other 8 bits of each character can contain packet data. The first character of each packet is usually the address of the destination network node. Many systems that use 9-bit characters use the packet design in Fig 2 .
Hardware support for the 9-bit character format is widespread in µCs, including most Intel and Motorola parts. Many µCs' UARTs offer a 9-bit mode that can substantially reduce the frequency of µC interrupts and the CPU time devoted to network processing. A few UART ICs, such as Intel's 82510, have a 9-bit mode with similar features. Others can generate 9-bit characters in software.
What on earth is BACnet?BACnet defines several network-object types representing common functions of embedded controllers in building automation. Some examples of network-object types are binary output, analog input, file, calendar, schedule, and loop (for feedback-loop control). Some services are event and alarm notification. Network nodes can use the ReadProperty service to read several properties of each network-object type. For example, analog-input objects can have the properties Present_Value, Units, and Resolution. In some cases, nodes can also use the WriteProperty service to modify objects' properties. A manufacturer designing a BACnet-compliant device selects objects and services that represent a device's network-accessible functions. A simple sensor may require only one binary-input or analog-input object and may support only the ReadProperty service; a more complex device may have many objects and support several services. Proprietary extensions represent functions that the standard BACnet object types and services can't handle.
|
A symbol similar to the one at the beginning of a packet can denote the end of a packet. However, this approach is not always necessary; you may be able to find the end by using the information in the packet to calculate the packet length.
Among the factors that can cause errors are messages distorted during transmission; hardware failures; resource bottlenecks, such as running out of memory buffers; software incompatibility; and software bugs. Although error control can hold the frequency and type of uncorrected errors within acceptable limits, you can't design a system in which errors never occur. Many network protocols, not just UART protocols, use the error-control techniques discussed in this section.
Two of the most common techniques for detecting transmission errors are checksum and CRC. The techniques add redundant information to the packet, allowing the receiving station to perform an internal consistency check on the packet. The sending station computes the checksum or CRC from the contents of the packet and appends the resulting value to the end of the packet. The receiving station does the same computation on the packet contents and compares the computed value to the received value. If the two values are not equal, a transmission error has occurred. Character-based parity is considered an ineffective error-detection mechanism for network protocols.
A simple 8-bit checksum can be computed from the modulo-256 sum of all of the message bytes. Computationally, this approach is inexpensive, but it does not provide good protection against multiple-bit errors within a packet. The more common technique uses a CRC procedure to compute a 16-bit checkword. Although this computation is more complex than determining a simple arithmetic checksum, it gives better protection against a wide range of errors. Some protocols use even longer checkwords: Ethernet and FDDI packets include 32-bit CRCs, which detect certain corrupted packets that a 16-bit CRC would miss.
The best method of error detection for a particular application depends on the degree of reliability required, the nature and frequency of errors that the underlying communication media introduce, and the available communication resources. In some applications, an occasional undetected error is not a significant problem. However, in other applications, an undetected error can have serious and unacceptable consequences. Nevertheless, for many applications, a 16-bit CRC is a good compromise between communication reliability and consumption of system resources. Many books discuss transmission-error detection methods in more detail (See Refs 9, 7, and 11).
Table 2 lists the three levels of data-link-layer service reliability. UART protocols use many of the same error-control techniques as other classes of network protocols. UART protocols must implement these techniques in software, whereas hardware sometimes helps out in other protocols. For example, an Ethernet chip set, by itself, provides transmission and reception services at reliability level 3 entirely within the data-link layer. Providing greater reliability to Ethernet is the task of higher level software services. On its own, an Arcnet chip set provides level-2 reliability but requires additional higher level software services to achieve increased reliability.
When a receiving node detects an error, it must take corrective action. Usually this means having the sending node retransmit corrupted packets. The transmitting station must get feedback about whether the receiving station received a packet correctly. In some protocols, the receiving station sends a positive acknowledgment if it detects no error in a received message and a negative acknowledgment if it detects an error. In other protocols, the receiver acknowledges good packets but not bad ones. If the transmitting station does not receive an acknowledgment within a specified time, it retransmits the packet. After a specified number of retransmissions, the transmitting station gives up. This technique achieves level-2 reliability.
Achieving level-1 reliability involves combining feedback error-control techniques with a sequence-number mechanism that works like page numbers in a book. Sequence numbers can handle missing, duplicate, and out-of-order packets. To use sequence numbers, two network nodes first establish a virtual connection, which initializes the sequence numbers to some specified value. Each packet that one node transmits to another specific node includes a sequence number that is one greater than the number in the previous packet. The receiving station can request the retransmission of particular packets by number, if necessary. In the packet design of Fig 2 , a sequence bit can indicate a duplicate transmission.
Some protocols require this mechanism; some don't. Requiring an acknowledgment for each packet before transmitting the next packet can avoid missing and out-of-order packets. However, a corrupted acknowledgment packet can still result in retransmission of an original packet and cause duplication. Depending on their content, duplicate packets are sometimes a problem and are sometimes tolerable. Think about your application: Ask yourself whether executing a particular command twice produces the same effect as executing it once. (The term for commands whose effect does not change with the number of sequential executions is "idempotent.") If the answer is "no," you probably need to use sequence numbers. For example, when you use an ATM to withdraw $100 from your bank account, you want to be sure that your balance goes down by only $100, not $200 or $300. In contrast, a command to turn a device on could probably execute repeatedly with the same effect as executing once.
In some situations, you should include enough redundant information in a packet to let the receiving station correct some errors without requiring retransmission of the message. This technique, forward error control, is often used in applications where retransmission of corrupted messages is impractical or impossible, such as broadcast transmissions and communication with deep-space exploration vehicles. You can use forward error control for communication channels with high error rates (Ref 9).
Another factor that any network protocol must define is how the communication medium is shared. In embedded systems, three popular medium-access-control methods are polling, token-bus, and CSMA (carrier-sense/multiple access).
Polling is probably the simplest mechanism: The network node designated as the master controls which node transmits when. All other nodes are slaves. The master polls each slave periodically. When polled, a slave can transmit a message. In some protocols, slaves can send messages to any network node; in others, the slaves can send messages only to the master.
Token-bus is similar to polling in that only one node has permission to transmit at any time. That permission takes the form of a "token." The node possessing the token can transmit a packet to any other node. The token passes from node to node in a special packet-as if the nodes were connected in a ring or a circular queue. A node that has nothing to transmit passes the token to the next node. The complex part of token-bus protocols is handling transient conditions and errors: how the system starts up, what happens if a token is lost, and procedures for allowing nodes to enter or leave the network. Arcnet and IEEE 802.4 are token-bus protocols.
Some protocols combine aspects of polling and token-bus. As in polling, these protocols assign nodes to master and slave categories, but allow multiple masters. The masters pass a token among themselves. A master can poll the slaves when it has the token.
In CSMA protocols, a network node that is ready to transmit a packet must first sense if another node is currently transmitting. If not, the first node can begin transmitting either immediately or after a short waiting period. If two or more nodes decide to start transmitting at almost the same time, a "collision" results. This situation usually causes corruption of one or more packets. Most CSMA protocols include collision-avoidance, -detection, or -resolution procedures, which can be complex. One common collision-avoidance scheme requires nodes to wait for a period of time before beginning a transmission, while listening for transmissions from other nodes. Ethernet and the similar IEEE 802.3 are CSMA protocols.
| Table 2 -- Three standard packet-transmission reliability levels | |
|---|---|
| Packet-transmission reliability level | Description |
| 1 | Guaranteed delivery of exactly one copy of each message in the order transmitted |
| 2 | Guaranteed delivery of at least one copy of each message |
| 3 | Delivery is not guarenteed |
Factors that affect performance include the medium-access-control method, the number of network nodes, the amount of traffic, and-perhaps most important-which nodes generate traffic and when. Several possible performance measures are possible; their relative importance depends on the application.
The medium-access-control method affects the network-access time, which is the length of time a node requires to gain network access and successfully transmit a message. Obviously, network-access time varies, but you can make qualitative estimates of the maximum and the average. If, from network parameters, you can calculate a finite maximum value for a particular protocol, the protocol is deterministic. Determinism is a desirable property for networks that carry real-time control messages. Polling protocols that periodically poll every slave are deterministic, as are token-bus protocols under normal circumstances. In contrast, many CSMA protocols are not strictly deterministic (Ref 2).
The distribution and timing of network traffic can have a great impact on the relative performance of medium-access methods. Consider one situation that occurs frequently in embedded systems: One central control and monitoring station (the master) sends commands to the other nodes. The other nodes respond to the commands but never initiate any network traffic of their own. If you modify the basic polling protocol so that the master polls a particular slave only when there is a message for that slave, the performance can be good. In this case, a CSMA protocol would also perform well because collisions would never occur. But this situation is not a good match for token-bus protocols because the master must wait until it gets the token before it can transmit a command. The slaves must wait for the token before replying.
However, if network traffic occurs in a more random fashion, the scenario changes. When the traffic is relatively light, CSMA emerges as the likely winner because nodes do not often need to wait for long to transmit, and collisions are few. The performance of round-robin polling and token-bus protocols depends on the number of network nodes. Because of the time required for passing the token around the network, the performance decreases as the number of nodes increases, even if the amount of traffic does not increase. However, when network traffic is relatively heavy, most CSMA protocols suffer from a substantial increase in collisions, which do not occur in polling and token-bus protocols (Ref 10).
The media-access-control method affects system reliability. For example, if the master node fails in a polling protocol, network communication ceases unless another node can fill the role of master. Token-bus protocols have a somewhat less severe problem: When a node goes dead, the token is lost, requiring the network to reconfigure itself. Depending on the protocol, reconfiguration can take awhile. A system can fail in ways unrelated to the media-access-control method: A shorted or broken cable can cause at least a partial network failure. Likewise, a jabbering network node can cause serious problems.
Polling is the most popular medium-access-control method in UART networks because it is the simplest to define and implement. Strict master-slave polling protocols confine most of the protocol complexity to the master-node software, so the slave-node software can be very small. One protocol we implemented required less than 1 kbyte of executable code and 50 bytes of RAM in the slaves. Because it is responsible for error recovery, the master-node software requires a timer. However, if the slaves merely reply to queries from the master, the slave code needs no timer. Of course, the slaves must still detect and respond to errors.
Token bus is significantly more complicated. The code for recovering from lost-token errors is especially complex. All nodes require a timer, which complicates the hardware. The nodes must be equally capable of detecting and recovering from errors, including loss of the token.
CSMA protocols are complex. For example, the kind of CSMA employed in Ethernet includes collision detection and a complex back-off procedure that requires a timer. Obviously, collision avoidance requires a reliable method of detecting transmissions in progress. We are not aware of any UARTs that indicate when another node is transmitting. Thus, collision detection requires hardware, which usually includes a timer, and software to detect transmission by other nodes. Depending on the communication medium, collision detection can be difficult, so it is often omitted. However, collision detection is more practical with some media than with others. For example, many radio modems have a carrier-detect output that indicates that the transmission channel is in use.
When you implement a serial protocol, you usually have some kind of interrupt handler to manage sending and receiving characters. For reception, the serial ports of simple embedded controllers have, at best, one- or two-deep FIFO buffers. Thus, every character received causes a processor interrupt. Obviously, the higher the bit rate, the more often these interrupts occur. The system software must allow for effective interrupt servicing to guarantee that received characters are removed from the FIFO before being overwritten by the next character. Once removed from the FIFO, characters go to a safe memory location, usually to a buffer space. There, the system may perform some preliminary message processing.
You may wish to determine how much overhead is involved and how fast you can run the serial port. Our experience suggests that in a typical application for an embedded controller, for example, one based on an 8-bit µC such as the 8051, you can comfortably operate the port at speeds to 62.5 kbps. In this situation, the networking kernel consumes just over half of the processor's capacity. The speed varies depending on the processor and the networking-kernel design. Controllers based on 16-bit processors should handle 100 kbps with no special problems.
You can determine the overhead by examining the time required to process each received character. This example shows how to make the calculation: A common speed for POS terminal systems is 187.5 kbps. Suppose a system that operates at this speed uses a character format of 1 start bit, 8 data bits, no parity, and 1 stop bit (a total of 10 bits/character). When fully loaded, the system must process 18,750 cps, which is equivalent to 53 µsec/character. Figure 3 shows the relationship between the data rate and the required speed of character processing for the most common range of bit rates.
For a typical 8051-based embedded controller, clearing characters out of the FIFO can cause a processing bottleneck. Although the serial port can probably handle communications at rates above 187.5 kbps (to 375 kbps with a 12-MHz 8051), 53 µsec is a short time for the processor to handle the interrupt. Moreover, other interrupts can compete for the processor's time. Therefore, the processor's availability or the overhead imposed by other processing functions directly affects the risk of losing characters. You must consider all of this when calculating the best transmission rate for your network.
In a fully saturated network-one in which messages are going out constantly-the higher you make the bit rate, the greater the network processing-time requirement. A system operating at 62.5 kbps must process more messages per unit time than a system operating at 9600 bps. The processing time increases in direct proportion to the data rate.
Network-processing delays can interfere with processing tasks occurring simultaneously. Interrupts with a lower priority than the serial port's may have to wait for significant periods before they are handled. Although an interrupt's function determines the delay's importance, you must anticipate the problems that delays can cause. To alleviate network-processing delays, especially at higher bit rates, minimize the amount of immediate message processing. Wait until the complete message has been received; then process it outside of any interrupt handler.
Many network protocols and application functions need timers. In embedded controllers, hardware-based timers are usually scarce. Protocols that require a time-out in every network node leave one fewer timer for other functions. One advantage of master-slave protocols is that the slaves' network functions do not require timers.
Implementing a simple 8-bit arithmetic checksum is easy and doesn't take much processor time. Essentially, you add all of the bytes in the packet modulo 256. Of course, this approach isn't very powerful. The 16-bit CRC is more powerful and not as slow as you might think. You can implement the checksum by using a table-look-up scheme, in which the table requires 512 bytes of ROM. You can also use a modulo-2 division, which takes much less memory but is slower than table look-up (Ref 7).
You must usually define how reliable a network will be. A good way to describe network reliability is to use one of the three orders of reliability discussed earlier. If you don't have to guarantee message delivery, the system can be simple. But guaranteeing delivery of at least one copy of each message requires a timer to limit the wait for an acknowledgment. The sending node must store messages in case they have to be retransmitted. To implement the highest level of reliability, you must allocate some memory in each node for tracking the state of communication with every other node with which a virtual connection is maintained. Protocols that allow the transmission of multiple messages before the sender receives an acknowledgment require more buffer space. The complexity and size of the code increases along with the required reliability.
Cimetrics Technology's 9-Bit Solution network software implements a master-slave protocol with only 8 to 10 kbytes of code for the master and 2 to 3 kbytes of code for the slaves. This protocol provides a choice of all three levels of reliability and 16-bit CRC error checking.
UART-based networks represent an attractive alternative in embedded distributed-control and data-acquisition. UART-based networks require less hardware than many other networking technologies and give system designers flexibility in optimizing cost-effective embedded systems. Although UART-based protocols are software-intensive, they can incorporate all of the elements of effective, reliable networks. Moreover, UART-based networks' popularity assures the availability of proven techniques and tools. Meanwhile, several proposed standards let designers follow established approaches.
Jim Butler is director of software engineering at Cimetrics Technology (Boston), where he has worked for almost four years. Butler manages all software development and wrote the code for the company's 9-Bit Solution network software and RS-485 products. Butler holds bachelors' and masters' degrees in aeronautics and astronautics from the Massachusetts Institute of Technology, Cambridge, MA. His hobbies include music and overseas travel.