4

I'm using USART on board to display messages on desktop PC terminal using Realterm

I noticed that, when I change stop bit number on Realterm, it does not affect the correctness of the message, contrary to baud rate, or bit number.

why stop bit number does not affect correctness?.

Lkaf Temravet
  • 583
  • 10
  • 27

2 Answers2

7

The stop-bit has a logical high level, it's the last bit that gets transfered if you transmit a byte over RS232. In case that you don't do any transfers the line is idle, and this is signaled as a logical high level as well.

If you increase the number of stop-bits on the sender side of a RS232 connection the receiver side will interpret the first stop bit as a stop bit, and all following stop bits as idle time on the line.

Effectively for each additional stop-bit you just add a small delay between the bytes transfered over the link.

Nils Pipenbrinck
  • 5,137
  • 1
  • 21
  • 30
  • Note that the inverse will probably not work: when the receiver expects 2 stop bits and checks for them (AFAIK not all do, even when set to 2 stop bist), and the reveiver sends only one stop bit and a new byte immediate after the stop bit, the receiver will signal a (framing) error. – Wouter van Ooijen Jun 16 '15 at 10:30
  • 1
    @WoutervanOoijen Correct, it will however receive the last byte of any continuous transfer because the idle-time will again be interpreted as a stop-bit. – Nils Pipenbrinck Jun 16 '15 at 10:44
  • correct. And when there is somehow a gap between each tranismitted byte the problem will never be noticed... – Wouter van Ooijen Jun 16 '15 at 11:21
  • @WoutervanOoijen Jep! Quite a lot of RS232 transmitters have small, undocumented delays between bytes. Found that out when I tried to abuse RS232 transmitters as frequency generators. – Nils Pipenbrinck Jun 16 '15 at 11:36
  • @NilsPipenbrinck sorry im really new to uart : what does baud rate means exactly : the number of data (8 bit length in my case) per second, or number of single bits (including start, data bits, stop bit) per second ??? – Lkaf Temravet Jun 16 '15 at 12:42
  • @MakhloufGharbi The baud-rate is the rate individual bits are transmitted over the RS232 link. Since each byte needs 10 bits per transfer (8 data-bits plus start-bit plus stop-bit) the maximal data-rate over an RS232 link is 8/10 lower than the baud rate. (assuming the popular 8N1 settings) – Nils Pipenbrinck Jun 16 '15 at 14:00
  • @MakhloufGharbi: Baud rate is the rate of symbols, not data bits. It includes control symbols such as start, stop, and parity bits. And formally it only counts symbol timeslices, regardless of how many bits are encoded per symbol. For a 53 kilobaud modem, 53k is the actual baud rate on the serial line between computer and modem, not the baud rate of the modulation, which is 8000/s. (When you have a modem connected on a bus instead of via UART, then there's not actually any communication that occurs at the rated baud rate) – Ben Voigt Jun 16 '15 at 14:35
0

A second stop bit in the transmitter makes the communication more resistant to interruptions, allowing the receiver to detect a true byte start faster than with one stop bit.

When you have a continuous stream of bytes and you turn on the receiver mid-stream, chances are that you get a byte from its middle, taking actual data as a start bit and confusing start/stop bits as part of the data. Of course this means that you'll get garbage for a while. Errors will accumulate until the receiver finally gets the real start bit for a word start and the stream stabilizes. When that happens depends on the data itself; it's more likely to happen after bytes that end in ones, like 0x01, 0x03, 0x07, 0x0f, 0x1f or such., because they have fewer zeros to be taken as start bits.

When you have two stop bits, statistically you'll get to that point faster than with one stop bit (provided that all bytes are transmitted without any pause or delay between them, which would act as effective additional stop bits). This was specially useful in old hardware like teletypes with very low baud rates and very noisy lines, especially if you don't have an underlying protocol (with checksums, retransmissions and such).

It's still a good measure to use two stop bits (in the transmitter) if you've got any of the forementioned conditions.

Of course you've asked about the receiver side. I don't think it's very useful to use two-stop bits, but it could help to detect framing errors as well depending on the implementation (whether the word is rejected or accepted when an error is found).

Guillermo Prandi
  • 897
  • 1
  • 10
  • 24