Xref: utzoo comp.sys.ibm.pc:30457 comp.periphs:1844 comp.misc:6385 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!sdsu!ucsdhub!hp-sdd!megatek!zeta!hollen From: hollen@zeta.megatek.uucp (Dion Hollenbeck) Newsgroups: comp.sys.ibm.pc,comp.periphs,comp.misc Subject: RS-232 protocol primer (long) Message-ID: <589@megatek.UUCP> Date: 22 Jun 89 15:01:09 GMT Sender: news@megatek.UUCP Reply-To: hollen@megatek.UUCP () Organization: Megatek Corporation, San Diego, Ca. Lines: 170 Serial Protocols I have had several requests to post more information about RS-232 software flow control protocols, notably, XON/XOFF and ETX/ACK. I will, on purpose, not address hardware handshaking methods such as RTS/CTS. Some general questions which have been asked will also be answered. For the most part, standard PC/XT/AT BIOS's do not implement any software flow control protocols (questions about this was what originally prompted this discussion). The BIOS only has the ability to set the UART to a particular baud rate, data bits, stop bits and parity. If any BIOS's implement flow control, I would appreciate hearing about them. There are, however, device drivers which can be installed to implement software flow control and interrupt driven, buffered serial IO. They are available as independent packages as well as part of various C libraries (other languages, too). XON/XOFF XON/XOFF protocol is a protocol implemented using two unprintable ASCII characters, XON = 11h (aka DC1) and XOFF = 13h (aka DC3). This protocol is typically implemented in both directions between terminal and computer, or two computers. It may, however, be only implemented in one direction. For ease of description, let us assume this protocol implemented between a host computer and a terminal which is an output only device (no keyboard) and therefore, the XON/XOFF protocol is implemented in one direction only. We will also assume that the terminal has a buffer of some size (1k for example) and cannot accept and display data as fast as the host can generate it, thus flow control is necessary. It is the responsibility of the terminal to notify the host to stop sending data enough BEFORE the terminal's buffer is full that the host can stop sending before overflowing the terminal's buffer. Generally, two independent processes happen on the host. For simplicity, I will pseudocode them into a simple polled loop, but in reality for efficiency, the check for flow control on the host side would be interrupt driven (not usually done on a PC, but can be). Host send a char function if no input char pending and xoff flag clear send char return WAIT_FOR_XON: if xoff flag set wait until input char rec'd = XON clear xoff flag send char return endif if input char pending get input char if not XOFF buffer for later use send char return else set xoff flag go to WAIT_FOR_XON endif endif It is assumed that there is an overlap when the host may have sent characters to the terminal AFTER the terminal has sent XOFF to the host, but before the host has received it. Therefore, on the terminal's side it is wise to send XOFF to the host when the terminal receive buffer is about 3/4 full. This depends on the size of the buffer, the baud rate, and the latency in the host response to received characters. The terminal is responsible for sending XON to the host when it is again ready to receive more characters. This generally might be when it has emptied its buffer to the 1/4 full mark, thus allowing for overlap and never having an empty buffer. A scheme such as this can keep both the host and the terminal busy as much as possible, and not waste a lot of time in transmission when nothing is being processed. ETX/ACK ETX/ACK protocol is generally used between host computers and printers. Although it may be used in other instances, it generally is not too common. The disadvantage of ETX/ACK is that the host implementation must either know how big a buffer the receiving device has, or only send buffers of a sufficiently small size that it could never overrun a buffer of any device it may be sending to. The other disadvantage is that unlike XON/XOFF which can overlap sending and processing, ETX/ACK leaves very little room for overlap, although some does occur. In the example pseudocode, we will assume a 1k buffer on the device. Host send char function if rec'd char pending get char if char = ACK set ACK flag else buffer char endif endif CHECK_FOR_ACK: if ACK flag set send char increment counter if counter = 800 send ETX clear ACK flag reset counter to 0 endif return else wait for ACK to be rec'd set ACK flag go to CHECK_FOR_ACK endif This means that the host sends a buffer with an ETX (03h) tacked on the end of it. As the printer processes characters, it examines every one to see if it is an ETX. When it receives the ETX, it tosses it and sends the host an ACK (06h) and resumes looking for input characters to process. Once the host has sent the buffer, it must wait until the printer has processed every one of the characters until it can recognize the ETX and send and ACK. This reduces the amount of overlap in sending that can occur. The only overlap can occur while the host is sending the buffer. The printer has no way to inform the host to begin sending again while it still has some buffer left to process, it must empty the buffer before starting the hsot again. Question received > Other than XON/XOFF and ETX/ACK, are there any other "common" > protocols? (i.e - I have heard of STX/ETX = start of > text / end of text). Not including hardware handshaking, not to my knowledge. STX/ETX are markers which are commonly used to surround a block of transmitted data for purposes of indicating block start and end. Typically used so that a block can be check-summed and re-transmitted if necessary. Just keep in mind that in dealing with RS232, there are no hard and fast rules. The RS232 "standard" is merely a document which designates the accepted use of the 25 wires in a cable and the physical configuration of the size and shape of the connector (DB-25). Many implementors make unique use of the signals on the wires, and of the data sent over them. There are some commonly accepted followed conventions, but always be aware of someone having implemented them "almost" like you would expect. I hope that this primer will be useful to many of you out there. Do not hesitate to mail me directly with questions. If there are such questions of general interest, I will post follow-ups to the net so all can benefit. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 seismo!s3sun!megatek!hollen ames!scubed/