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

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.