7

I know that the parity bit is optional in serial communication, but what about the start bit and the stop bit(s), are they also optional?

1
  • 5
    Short answer: No
    – DavidPostill
    Oct 23, 2017 at 17:38

2 Answers 2

10

Are the start bit and the stop bit(s) optional in serial communication?

No.


Presuming RS232 (or a TTL variant thereof).

Consider each "direction" independently, ignoring flow control lines. There is one signal, which must somehow convey "data", but it must also be able to convey "no data".

To convey "no data", we simply leave the signal high - logic 1. It can be like this indefinitely, and everyone is happy.

As soon as we want to convey "data" we must inform the remote end, using just this one binary signal, that data is about to come.

If we didn't use a start bit and transmitted 0b11110000, it would look something like this (where grey is idle, and green is active data):

unframed 0b11110000

But... how does the receiver know to start receiving? It looks identical to 0b00111100:

unframed 0b00111100

So, instead, we place a known "this is the start" bit at the front:

start-framed data

Brilliant!

But now we run into another problem... No two clocks tick at precisely the same rate. In the case of the humble UART, this is something that is agreed ahead of time - both ends of the link are "talking" at very nearly the same speed...

To give the link a better chance of working, we introduce a "stop bit", which is in effect, just a rest... a pause. Two stop bits are often used on older hardware that take longer to process the received byte - one stop bit is almost ubiquitous today.

start-stop-framed data

As @sawdust has kindly reminded me, a stop bit is also important to ensure that we can successfully detect and synchronise at the end of one frame, and the start of the next. This would be difficult if frame one ends in a zero, immediately followed by frame two's start bit.

... and there we have it! A nicely framed piece of data.


Parity is optional because it's related to assuring the integrity of the data - facilitating the detection of corruption. Nothing in the world is perfect (sometimes I'm amazed that anything works), and knowing if the data that you just received is valid is mighty helpful.

Unfortunately, the specification is very old, and the parity bit only permits us to detect an odd number of bit flips. If there are an even number of bit flips, then the parity cannot detect this.

Today we have much more advanced error detection, end even correction technologies, which are able to detect (or even correct) an amount of corruption.

Protocols that run over UARTs today typically do not use the parity bit, and prefer instead to use a checksum to ensure the integrity of the data transferred.

You'll also often see UARTs used to interface with a device - a serial console. In this case, the device is interfacing with a human, who will either not notice or not care that the data is corrupt (they could just re-run the command).

Finally, UARTs today are generally used on very short links, with good strong drivers - making noise and corruption at the physical (electrical) level much less of a concern.

2
  • 1
    The stop bit also exists to ensure that a start bit that immediately follows the prior frame can be detected. That's why the stop bit is the complementary value of the start bit.
    – sawdust
    Oct 23, 2017 at 19:47
  • 2
    sometimes I'm amazed that anything works - I thought it is only me. Oct 24, 2017 at 9:13
2

Both the start and stop bits are mandatory, and they serve a simple purpose--framing the data to be communicated.

The data line is usually set to a certain bit (for example, 0) when the sender is idle. Once it starts communicating, it will set the data line to the inverted bit (start bit, 1). This signals the receiver to enter a series of states. At the last state, the data line has to become idle again, and is reset back to its original bit (stop bit, 0). The receiver again listens for the start bit, and the cycle repeats.

2
  • 1
    The framing remark is spot on, but there's no clock line in serial (RS232 etc.) communication.
    – dirkt
    Oct 23, 2017 at 19:37
  • @dirkt You're right, my bad! Oct 23, 2017 at 20:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .