5
\$\begingroup\$

There is an option in many terminal programs or ICs to set 1 stop-bit, 2 stop-bits or 1.5 stop-bits. Is there any standard that says the RS-232 can have only 1/1.5/2 stop-bits but can't have 0.5 or 3 stop-bits, for example?

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Could it just be Recommended Standard 232? \$\endgroup\$
    – Bart
    Aug 15 at 7:59
  • 2
    \$\begingroup\$ wikipedia says that the RS-232-C (1969) specification fails to define many things, including character encoding, start and stop bits, and even the order of the bits. One of the things defined is that enormous 25 pin D connector. Later standards like 485 define more stuff, but whether they define the stop bits is another matter. \$\endgroup\$
    – Neil_UK
    Aug 15 at 8:01
  • \$\begingroup\$ Nop :) TIA-232-F (d1.amobbs.com/bbs_upload782111/files_35/ourdev_608717A327FT.pdf) has no one timing diagram or so. \$\endgroup\$
    – Arseniy
    Aug 15 at 8:02
  • 1
    \$\begingroup\$ You are referring to a protocol standard that defines the bits, not R2-232 which defines voltage levels. There is no standard that I am aware of, each device defines their own. The protocol details on one end (or both) are usually programmable using a UART (en.wikipedia.org/wiki/…). When one side is "smarter", it adapts to the "dumber" side which may have a fixed protocol. I have never seen a modern device with anything but one stop bit. \$\endgroup\$
    – Mattman944
    Aug 15 at 8:40
  • 1
    \$\begingroup\$ The stop bit just returns the data line to its idle state. The 1/1.5/2 bit setting determines the minimum lenght of the idle state. The idle state may last as long as you want. \$\endgroup\$ Aug 15 at 15:38

2 Answers 2

8
\$\begingroup\$

Nothing, there is no such standard that says how data should be sent over an RS-232 interface.

RS-232 is only a physical, mechanical, and electrical standard; it does not even define a protocol for to sending bits on the data wires. It also does not define at what rates data should be sent, other than it is intended for bit rates up to 20 kbps, and the electrical specifications give a theoretical limit of about 120 kbps.

So you can literally use any protocol you want over an RS-232 interface; it is not even limited to the asynchronous start-stop protocol of a UART. Anything goes as long as the two devices are compatible with each other and communicate within the limits of the specifications.

However, most often a UART or USART is used for serial comms over an RS-232 interface, so what options you have available in practice is based on limitations and features of the UART or USART your system has.

UARTs and USARTs themselves are not standardized: they are usually programmable and support at least the most common options typically found on most devices, but sometimes also some less common features such as 0.5 stop bits needed for communicating with smart cards or using 9 data bits in a frame.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ Thank for your comprehensive answer. But if someone can add some more "records" of UART (for max/min speed/symbol length/stop-bit length or so) which totaly proof that there is no any standard it will be completely wodnerfull. \$\endgroup\$
    – Arseniy
    Aug 15 at 8:18
  • 1
    \$\begingroup\$ There is no proof for that. The asynchronous start-stop protocol is older invention than integrated UART chips, but you can examine features from different UART chips of the 70s up to MCUs with built-in UARTs made 50 years later. The speeds used are also arbitrary as it depends on what you use it for, e.g. 31.25 kbps for MIDI or 250 kbps for DMX-512 which are UART speeds but not typically used or even available on RS-232 serial comm ports. The bit rate does not even need to be exact as e.g. 1% difference is easily tolerated by UARTs and rates of several megabits per second is possible. \$\endgroup\$
    – Justme
    Aug 15 at 8:36
  • \$\begingroup\$ Note that a lot of modern UARTs like those used by USB, HDMI and PCIe are more commonly known as SERDES. A lot of SERDES are single-function devices however the SERDES commonly found on FPGAs and CPLDs can be programmed to behave like traditional UART (8bit, stop bit, parity) or use more than 8 bits per "word" (eg. 16bit, 64bit etc.) \$\endgroup\$
    – slebetman
    Aug 15 at 20:42
  • 2
    \$\begingroup\$ @slebetman USB, HDMI and PCIe don't even remotely relate to UARTs. Even if they all can be made with SERDES. \$\endgroup\$
    – Justme
    Aug 15 at 20:49
  • \$\begingroup\$ @Justme USB and HDMI works the same way as traditional UARTs - they have a start bit, some data bits (16, 32 or 64bits) and a stop bit. That's why I wanted to highlight modern SERDES because modern SERDES work the same way as UART but with wider bit sizes. \$\endgroup\$
    – slebetman
    Aug 16 at 4:22
0
\$\begingroup\$

In asynchronous UART communications - as typical over RS-232 - the only real constraint is that the transmitter must be able to send at least as many stop bits as the receiver needs. That's all.

If the receiver is configured to expect 1 stop bit, the transmitter can be configured for 1, 1.5, 2, 10, 1000 stop bits. What's 1000 stop bits, you ask? A long pause between sending two bytes. Stop bits are idle state, after all, and idle state is what's on the line when no data is being transmitted :)

I'd expect no device to allow receiving just 0.5 stop bits, but many devices will be fine with maybe 0.6 or 0.7 stop bits, depending on how they sample the RX line, and what's their clock frequency as compared to that of the transmitter.

But, in general, I've not seen "0.5" stop bits as an option. 1 is the minimum, and you can always transmit 2 and remain compatible with all receivers that have the same baud rate and same number of data bits.

\$\endgroup\$
4
  • \$\begingroup\$ UARTs that support smartcard communication protocol do use 0.5 stop bits, because an ACK bit is sent back after the half-length stop bit on a single half-duplex wire. That's a bit special as it generally would not be used between other communication equipment. And usually a device configures the stop bits for both transmission and reception, so while a frame that transmits 2 stop bits can be received by device expecting one, the device configures to 2 stop bits may not handle frames sent back-to-back with only 1 stop bit, if it really requires 2 stop bits and checks both stop bits to be idle. \$\endgroup\$
    – Justme
    Aug 16 at 4:50
  • \$\begingroup\$ The STM32F103 MCU has "STOP" bits [13:12] in "USART_CR2" register which can set stop-bit size from 0.5 to 2 bits. It's made exactly for ISO/IEC 7816-3 SmartCard standard. The next question is If we made our own protocol with 1000 stop-bits shall receiver just wait for 1000 bits or shall it check that 1000 stop-bits really income? If income only 998 bits is it just a transmission error or is it a special condition like "break condition"? \$\endgroup\$
    – Arseniy
    Aug 16 at 5:55
  • \$\begingroup\$ @Arseniy Beware, the "break condition" is a "0" for extended time, not "1". -- If you design your protocol to require 1000 stop bits, your receiver should check them all. If you design your protocol with a "deaf" period of 1000 bits, your receiver can ignore the level on the wire during this interval. It's up to your specification. You see, writing good specifications requires a lot of thought. \$\endgroup\$ Aug 16 at 6:07
  • \$\begingroup\$ @Arseniy You can read how STM32 you mentioned works and can implement same or different UART with 1000 stop bits if you want. STM32 requires the whole frame to be low including all stop bits to be a break frame. But STM32 does only check the first stop bit if configured for two, so it is possible it can still receive data frames sent with only 1 stop bit if it does not check and require two stop bits. If you unplug wire in the middle of a transmission it will go idle and receive data as ones wit correct stop bits. If unplugging goes to active state then data is zeroes and stop bits too, error. \$\endgroup\$
    – Justme
    Aug 16 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.