NextPreviousContents
- Serial Hardware Flow Control Systems
- Serial Hardware Flow Controller
- Serial Hardware Flow Control Diagram
- Linux Serial Enable Hardware Flow Control
- Prolific Usb To Serial Hardware Flow Control
I have a SerialPort with a setup with flow control to be 1. How to set it in c#. I have newline char in my port setup and I assume that different to the flow control. My port setup so far is as below. Can anyone help me with setting the flow control please? Nov 09, 2009 Hi, I am attempting to communicate with a piece of hardware connected to a serial port. The ports settings need to be: Baud = 9600 Bits = 8 Parity = None Stop Bits = 1 Flow control = Hardware If i set this up in HyperTerminal all works well. However when I try to setup a serial port using C# with the same settings i get no response or at best an echo.
Flow control (= handshaking = pacing) is to prevent too fast of aflow of bytes from overrunning a terminal, computer, modem or otherdevice. Overrunning is when a device can't process what it isreceiving quickly enough and thus loses bytes and/or makes otherserious errors. What flow control does is to halt the flow of bytesuntil the terminal (for example) is ready for some more bytes. Flowcontrol sends its signal to halt the flow in a direction opposite tothe flow of bytes it wants to stop. Flow control must both be set atthe terminal and at the computer.
There are 2 types of flow control: hardware and software (Xon/Xoff orDC1/DC3). Hardware flow control uses dedicated signal wires such asRTS/CTS or DTR/DSR while software flow control signals by sending DC1or DC3 control bytes in the normal data wires. For hardware flowcontrol, the cable must be correctly wired.
The flow of data bytes in the cable between 2 serial ports isbi-directional so there are 2 different flows (and wires) to consider:
Hardware flow control is sometimes referred to as RTS / CTS flow control. This term mentions the extra input and outputs used on the serial device to perform this type of handshaking. RTS / CTS in its original outlook is used for handshaking between a computer and a device connected to it such as a modem. Some software, like the Windmill COMIML serial driver, use the DTR line for handshaking (flow control), setting it high to indicate that it is ready to receive data. Some instruments, though, need DTR to be low and RTS to be high before they will provide data. In this situation you need to change the connections on the RS232 cable. For hardware flow control, the cable must be correctly wired. The flow of data bytes in the cable between 2 serial ports is bi-directional so there are 2 different flows (and wires) to consider: Byte flow from the computer to the terminal Byte flow from the terminal keyboard to the computer. Aug 14, 2013 Hi all. I've got a general question concerning serial connection (I'm sort of a newbe in hardware and am having trouble managing a serial connection for a while now ): does anyone know what holdrx and holdtx signals might stand for? The datasheet I've got doesn't give enough information on that It just says the hold. input pins are used to impelement hardware handshake of transmit. In computing, a serial port is a serial communication interface through which information transfers in or out one bit at a time (in contrast to a parallel port). Throughout most of the history of personal computers, data was transferred through serial ports to devices such.
- Byte flow from the computer to the terminal
- Byte flow from the terminal keyboard to the computer.
You might ask: 'Why not send at a speed slow enough so that thedevice will not be overrun and then flow control is not needed?' Thisis possible but it's usually significantly slower than sending fasterand using flow control. One reason for this is that one can't justset the serial port baud rate at any desired speed such as 14,500,since only a discrete number of choices are available. The bestchoice is to select a rate that is a little higher than the device cankeep up with but then use flow control to make things work right.
If one decides to not use flow control, then the speed must be set lowenough to cope with the worst case situation. For a terminal, this iswhen one sends escape sequences to it to do complex tasks that take moretime than normal. In the case of a modem (with data compression butno flow control) the speed from the computer to the modem must be slowenough so that this same speed is usable on the phone line, since inthe worst case the data is random and can't be compressed. If onefailed to use flow control, the speed (with data compression turnedon) would be no faster than without using any compression at all.
Buffers are of some help in handling worst case situations of shortduration. The buffer stores bytes that come in too fast to beprocessed at once, and saves them for processing later.
Another way to handle a 'worst case' situation (without using flowcontrol or buffers) is to add a bunch of nulls (bytes of value zero) toescape sequences. Sometimes DEL's are used instead provided they haveno other function. See Recognize Del.
The escape sequence starts the terminal doing something, and while theterminal is busy doing it, it receives a bunch of nulls which itignores. When it gets the last null, it has completed its task and isready for the next command. This is called null padding. These nullsformerly were called 'fill characters'. These nulls are added just to'waste' time, but it's not all wasted since the terminal is usuallykept busy doing something else while the nulls are being received. Itwas much used in the past before flow control became popular. To beefficient, just the right amount of nulls should be added and figuringout this is tedious. It was often done by trial and error sinceterminal manuals are of little or no help. If flow control doesn'twork right or is not implemented, padding is one solution. Some ofthe options to the stty command involve padding.
One might wonder how overrunning is possible at a serial portsince both the sending and receiving serial ports involved in atransmission of data bytes are set for the same speed (in bits/sec)such as 19,200. The reason is that although the receiving serial portelectronics can handle the incoming flow rate, the hardware/softwarethat fetches and processes the bytes from the serial port sometimescan't cope with the high flow rate.
One cause of this is that the serial port's hardware buffer isquite small. Older serial ports had a hardware buffer size of onlyone byte (inside the UART chip). If that one received byte of data inthe buffer is not removed (fetched) by CPU instructions before thenext byte arrives, that byte is lost (the buffer is overrun). NewerUART's, namely most 16550's, have 16-byte buffers (but may be set toemulate a one-byte buffer) and are less likely to overrun. It may beset to issue an interrupt when the number of bytes in its bufferreaches 1, 4, 8, or 14 bytes. It's the job of another computer chip(usually the main CPU chip for a computer) to take these incomingbytes out of this small hardware buffer and process them (as well asperform other tasks).
When contents of this small hardware receive buffer reaches thespecified limit (one byte for old UART'S) an interrupt is issued.Then the computer interrupts what it was doing and software checks tofind out what happened. It finally determines that it needs to fetcha byte (or more) from the serial port's buffer. It takes thesebyte(s) and puts them into a larger buffer (also a serial port buffer)that the kernel maintains in main memory. For the transmit buffer,the serial hardware issues an interrupt when the buffer is empty (ornearly so) to tell the CPU to put some more bytes into it to send out.
Terminals also have serial ports and buffers similar to the computer.Since the flow rate of bytes to the terminal is usually much greaterthan the flow in the reverse direction from the keyboard to the hostcomputer, it's the terminal that is most likely to suffer overrunning.Of course, if you're using a computer as a terminal (by emulation),then it is likewise subject to overrunning.
Risky situations where overrunning is more likely are: 1. Whenanother process has disabled interrupts (for a computer). 2. When theserial port buffer in main (or terminal) memory is about to overflow.
When its appears that the receiver is about to be overwhelmed byincoming bytes, it sends a signal to the sender to stop sending. Thatis flow control and the flow control signals are always sent in adirection opposite to the flow of data which they control (althoughnot in the same channel or wire). This signal may either be a controlcharacter (^S = DC3 = Xoff) sent as an ordinary data byte on the datawire (in-band signalling), or a voltage transition from positive tonegative in the dtr-to-cts (or other) signal wire (out-of-bandsignalling). Using Xoff is called 'software flow control' and usingthe voltage transition in a dedicated signal wire (inside the cable)is called hardware flow control.
With terminals, the most common case of 'stop sending' is wherethe terminal can't keep up with the characters being sent to it and itissues a 'stop' to the PC. Another case of this is where someonepresses control-S. Much less common is the opposite case where the PCcan't keep up with your typing speed and tells the terminal to stopsending. The terminal 'locks' its keyboard and a message or lightshould inform you of this. Anything you type at a locked keyboard isignored. When the PC catches up on it's work, then the keyboardshould unlock. When it doesn't, there is likely some sort of deadlockgoing on.
Another type of keyboard lock happens when a certain escape sequence(or just the ^O control character for Wyse 60) is sent to theterminal. While the previous type of lock is done by the serialdriver, this type of lock is done by the hardware of a real terminal.It's a catch-22 situation if this happens since you can't type anycommands to escape out of this lock. Going into setup and resettingmight work (but it failed on my Wyse 60 and I had to cycle power toescape). One could also send an 'unlock keyboard' escape sequencefrom another terminal.
The term 'locked' is also sometimes used for the common case of wherethe computer is told to stop sending to a terminal. The keyboard isnot locked so that whatever you type goes to the computer. Since thecomputer can't send anything back to you, characters you type don'tdisplay on the screen and it may seem like the keyboard is locked.Scrolling is locked (scroll lock) but the keyboard is not locked.
Serial Hardware Flow Control Systems
When the receiver has caught up with its processing and is readyto receive more data bytes it signals the sender. For software flowcontrol this signal is the control character ^Q = DC1 = Xon which issent on the regular data line. For hardware flow control the voltagein a signal line goes from negative (negated) to positive (asserted).If a terminal is told to resume sending the keyboard is then unlockedand ready to use.
Some older terminals have no hardware flow control while othersused a wide assortment of different pins on the serial port for this.For a list of various pins and their names see Standard Null Modem Cable Pin-out. Themost popular pin to use seems to be the DTR pin (or both the DTR pinand the DSR pin).
RTS/CTS, DTR, and DTR/DSR Flow Control
Linux PC's use RTS/CTS flow control, but DTR/DSR flow control(used by some terminals) behaves similarly. DTR flow control (in onedirection only and also used by some terminals) is only the DTR partof DTR/DSR flow control.
RTS/CTS uses the pins RTS and CTS on the serial (EIA-232) connector.RTS means 'Request To Send'. When this pin stays asserted (positivevoltage) at the receiver it means: keep sending data to me. If RTS isnegated (voltage goes negative) it negates 'Request To Send' whichmeans: request not to send to me (stop sending). When the receiver isready for more input, it asserts RTS requesting the other side toresume sending. For computers and terminals (both DTE type equipment)the RTS pin sends the flow control signal to the CTS pin (Clear ToSend) on the other end of the cable. That is, the RTS pin on one endof the cable is connected to the CTS pin at the other end.
For a modem (DCE equipment) it's a different scheme since the modem'sRTS pin receives the signal and its CTS pin sends. While this mayseem confusing, there are valid historical reasons for this which aretoo involved to discuss here.
Terminals usually have either DTR or DTR/DSR flow control. DTR flowcontrol is the same as DTR/DSR flow control but it's only one-way andthe DSR pin is not used. For DTR/DSR flow control at a terminal, theDTR signal is like the signal sent from the RTS pin and the DSR pin isjust like the CTS pin.
Connecting up DTR or DTR/DSR Flow Control
Some terminals use only DTR flow control. This is only one-wayflow control to keep the terminal from being overrun. It doesn'tprotect the computer from someone typing too fast for the computer tohandle it. In a standard file-transfer serial cable the DTR pin atthe terminal is connected to the DSR pin at the computer. But Linuxdoesn't support DTR/DSR flow control (although drivers for somemultiport boards may support DTR/DSR flow control.) A way around thisproblem is to simply wire the DTR pin at the terminal to connect tothe CTS pin at the computer and set RTS/CTS flow control (sttycrtscts). The fact that it's only one way will not affect anything solong as the host doesn't get overwhelmed by your typing speed and dropRTS in a vain attempt to lock your keyboard. See Keyboard Lock. For DTR/DSR flow control (ifyour terminal supports this two-way flow control) you do the above.But you also connect the DSR pin at the terminal to the RTS pin at thecomputer. Then you are protected if you type too fast.
Old RTS/CTS handshaking is different
What is confusing is that there is the original use of RTS whereit means about the opposite of the previous explanation above. Thisoriginal meaning is: I Request To Send to you. This request wasintended to be sent from a terminal (or computer) to a modem which, ifit decided to grant the request, would send back an asserted CTS fromits CTS pin to the CTS pin of the computer: You are Cleared To Send tome. Note that in contrast to the modern RTS/CTS bi-directional flowcontrol, this only protects the flow in one direction: from thecomputer (or terminal) to the modem.
For older terminals, RTS may have this meaning and goes high when theterminal has data to send out. The above use is a form of flowcontrol since if the modem wants the computer to stop sending it dropsCTS (connected to CTS at the computer) and the computer stops sending.
Reverse Channel
Old hard-copy terminals may have a reverse channel pin (such aspin 19) which behaves like the RTS pin in RTS/CTS flow control. Thispin but will also be negated if paper or ribbon runs out. It's oftenfeasible to connect this pin to the CTS pin of the host computer.There may be a dip switch to set the polarity of this signal.
Some think that hardware flow control is done by hardware butonly a small part of it is done by hardware. Most of it is actuallydone by your operating system software. UART chips and associatedhardware usually know nothing at all about hardware flow control.When a hardware flow control signal is received (due to the signalwire flipping polarity) the hardware gives an electrical interruptsignal to the CPU. However, the hardware has no idea what thisinterrupt means. The CPU stops what it was doing and jumps to a tablein main memory that tells the CPU where to go to find a program whichwill find out what happened and determine what to do about it. Inthis case this program stops the outgoing flow of bytes.
Serial Hardware Flow Controller
But even before this program stops the flow, it was already stopped bythe interrupt which interrupted the work of the CPU. This is onereason why hardware flow control stops the flow faster. It doesn'tneed to wait for a program to do it. But if that program didn'tcommand that the flow be stopped, the flow would resume oncethat program exited. So the program is essential to stop the floweven though it is not the first to actually stop the flow. After theinterrupt happens any bytes (up to 16) which were already in theserial port's hardware transmit buffer will still get transmitted. Soeven with hardware flow control the flow doesn't instantly stop.
Using software flow control requires that each incoming byte bechecked to see if it's an 'off' byte. These bytes are delayed bypassing thru the 16-byte receive buffer. If the 'off' byte was thefirst byte into this buffer, there could be a wait while 15 more byteswere received. Then the 16 bytes would get read and the 'off' bytefound. This extra delay doesn't happen with hardware flow control.
This is also software flow control and requires a device driverthat knows about it. Bytes are sent in packets (via the async serialport) with each packet terminated by an ETX (End of Text) controlcharacter. When the terminal gets an ETX it waits till it is ready toreceive the next packet and then returns an ACK (Acknowledge). Whenthe computer gets the ACK, it then send the next packet. And so on.This is not supported by Linux ?? Some HP terminals use the samescheme but use ENQ instead of ETX.
NextPreviousContentsI have a SerialPort with a setup with flow control to be 1. How to set it in c#. I have newline char in my port setup and I assume that different to the flow control. My port setup so far is as below. Can anyone help me with setting the flow control please ? Thank you.
Serial Hardware Flow Control Diagram
NishaNisha2 Answers
You can use Handshake for that to control flow control
In myproject I used below code for serial port initialization.
sowjanya attaluri