UARTs often let you choose between 1, 1.5 and 2 stop bits. With 1 stop bit payload efficiency is 80% (8/10), with 2 stop bits that drops to 72.7% (8/11). So what's the advantage of the second stop bit?
|
Extra stop bits can be a useful way to add a little extra receive processing time, especially at high baud rates and/or using soft UART, where time is required to process the received byte. Where speed is tight, and your UART only offers division ratios in powers of 2, adding an extra stopbit can be an option to give a less drastic reduction in speed than the next lowest baudrate. I believe this is may one reason the DMX512 standard specifies 2 stopbits. Another situation where they can be useful is if you have devices forwarding a data stream without any buffering or packetisation - small differences in clock rates between nodes and finite sampling granularity can cause errors to occur as data is received and retransmitted by a number of nodes in a chain, but if the data is sent with 2 stopbits and the receivers are set to one stopbit, it adds enough margin to accommodate these errors and leave at least one valid stopbit period for nodes far down the chain to receive reliably. I have also enountered a situation where a very long cable run caused some asymmetry in the rise and fall times, resulting in inadequate stopbit length - sending 2 stopbits and having the receiver only require one fixed this. |
|||
|
|
|
Two stop bits are unlikely to be much more useful than one on a system that has a significant proportion of stopped time and which is working in a low noise (low BER) environment such as internal to equipment or in a peripheral interface with a few metres of cable and/or without a modem-modem stage. 2 stop bits give you greater synchronisation time, more time to process between characters and probably, depending on hardware and algorithms, better chance of gaining or regaining synchronisation during a continuous data stream. Intercharacter time is of much less value on modern systems than when clock speeds were low and processor throughput lower. If you have an essentially continuous data stream, then if unsynchronised, any high bit will look like a stop bit. Any high low transition will look like a byte boundary. If your receiver starts on a 10 boundary and it is not a true start boundary then this will only be discovered 50% of the time )(ie if the final "stop bit" is found to actually be a low data bit and you will also have skipped over the genuine stop/start boundary along the way. On average you have 1/4 prospect of a byte boundary being 1/0 and falsely looking like a stop/start pair. The above suggests that if you choose a false stop-start pair then there is probably about 50% chance that you will choose another one on the following attempt. If you use 2 stop bits (11) then a valid stop start sequence is 110 which has 1/8th chance of occurring in random data traffic. The mixing of genuine stop and start bits in the unsynchronised flow changes the sats slightly but it seems relatively unlikely that if you get a false 110 stop/start sequence on one cycle that you'll hit another one next try before stumbling over the genuine 110 sequence which next occurs. As you note, 1 stop bit yields 8/10 = 80% max throughput and 2 stop bits yield 8/11= 72% efficiency. The difference in throughput at the utter limit is 80%/72% =~ 11% more. this is a useful gain in extreme circumstances but not vast and if the circuit is idle more than about 10% of the time it's of minimal value. If your circuit is noisy and prone to occasional synchronisation loss then the extra stop bit may help a lot. BUT if you care that much about throughput you can often increase the baud rate (not always) or change to fully synchronous operation. |
|||
|
|
In days long gone printers were (almost) all-mechanical constructs. Baudrates were somewhat standardised even then, so adding an extra stop bit would give the printer some extra time to print the character. Timing aspects were more visibly back then. For my first printer, an noisy http://en.wikipedia.org/wiki/Teletype_Model_33 , I had to insert a pause of two characters after sending a Carriage Return. |
|||
|
|
|
To amplify mikeselectricstuff's point about receive time with "soft UARTs", a receive application that will always know when to accept data and does so on a polling basis can often handle faster baud rates than would be practical with an interrupt-driven soft UART. Such applications, however, can only process incoming data during the time between the start of one byte's stop bit and the next byte's start bit; the time required to process each byte ends up being the limiting factor for communications speed. Processing data at 115,200-N-8-2 is not much more demanding than processing it at 57,600-N-8-1, but it's more than 80% faster. Sometimes one can push things even further by using seemingly-less-efficient data formats. For example, one can send each byte in two pieces, one with seven bits and one with one (the MSB's of the one-bit part are all set). If one does that, even with only one stop bit, there will be eight bit times of marking between the end of one byte-pair and the start of the next, thus allowing one to push the bit rate four times as high as what one could do with only two stop bits (and eight times as high as what one could do with one). Despite having to send twice as many bytes, the four-fold increase in data rate would be a major win. In addition, although each transmitted byte pair could be used to send eight bits of data, only 130 out of 256 possible byte values would be used by the encoding, leaving 126 values available for signalling or other purposes. |
|||||
|
|
Slowness of the receiving mechanical devices was the reason behind adding the extra stop bits, however the devices today are fast enough and work at even higher baud rates without the need of an extra stop bit |
|||
|
|
