22-Elec-A4 Digital Systems and Computers · December 2013

Question 5 of 6: Serial Communication Protocols and Framing

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Question 5: Serial Communication Protocols and Framing (12 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Polling versus interrupts (3 marks)

Polling is software-driven synchronisation. The processor reads the serial port's status register in a loop and tests the flag bits — receiver-data-available, transmitter-buffer-empty — and only when a flag is set does it perform the corresponding data transfer. The port is entirely passive: it raises a flag and waits to be noticed. All the intelligence, and all the timing responsibility, sits in the program.

Interrupt-driven transfer inverts the relationship. The port is configured to assert an interrupt request line when it needs service. The processor executes unrelated work; on receiving the request it finishes the current instruction, saves the program counter and processor status, and vectors to the interrupt service routine for that device, which performs the transfer and returns. The port now initiates, and the processor responds.

The differences that matter in practice are these. Polling wastes processor time in proportion to how often it checks: a loop tight enough to catch every character on a fast line consumes essentially the whole processor, while a loop relaxed enough to leave time for real work risks missing a character because the receive buffer is overwritten before it is read (an overrun). Interrupts consume processor time only when there is genuinely something to do, so the average overhead scales with the actual data rate rather than with the polling frequency, and the latency between a character arriving and being collected is bounded by the interrupt response time rather than by the loop period. Polling's compensating advantages are real but narrower: it needs no interrupt hardware or vector table, its timing is completely deterministic and therefore easy to analyse for a hard-real-time argument, it cannot suffer priority-inversion or nesting problems, and each transfer is cheaper because there is no context save and restore. Interrupts also introduce concurrency: any data structure shared between the service routine and the main program needs protection, which is a class of bug polling simply does not have.

The engineering conclusion is that interrupts are the better choice for a serial port in almost every general-purpose system, because a serial line is slow and sporadic relative to the processor and polling it would squander orders of magnitude more processor time than the interrupt overhead costs. Polling remains the right answer in a dedicated controller that has nothing else to do, in the earliest stage of system start-up before the interrupt system is initialised, and in tightly bounded real-time loops where determinism outranks efficiency.

(b) Synchronous versus asynchronous serial communication (3 marks)

The main difference is how the receiver obtains the timing reference used to sample the incoming bits.

In synchronous transmission the clock is shared between the two ends — carried on a separate wire, or recovered from the data stream itself by a phase-locked loop working on a self-clocking line code. Because the receiver's sampling instants are locked to the transmitter's, there is no accumulating timing error and characters need no individual framing. Data is therefore sent in continuous blocks of many characters, delimited by synchronisation characters or a flag pattern at the start of a frame, with no per-character overhead. That makes synchronous transmission efficient and suited to high rates and large transfers, at the cost of more complex hardware and the need to keep the link filled with idle or flag characters to hold synchronisation.

In asynchronous transmission there is no shared clock at all. Each end runs its own local oscillator, and the two are merely nominally equal. Synchronisation is re-established for every character from the falling edge of the start bit, and it need only hold for the ten or eleven bit times of one frame. This makes the hardware simple and cheap and allows the transmitter to send characters at arbitrary, irregular intervals — ideal for keyboards and terminals — but it costs the start, parity and stop bits on every single character, typically 20 to 30 percent of the raw line capacity.

(c) Line speed (3 marks)

i) What line speed is. The line speed is the rate at which bit cells are placed on the line, quoted in bits per second and often loosely called the baud rate. It fixes the bit time \(T_b = 1/R\), the interval the receiver allocates to each bit. On an asynchronous link both ends must be configured to the same nominal value, since it is the only timing information they share; the two independent oscillators are steered by it and by nothing else. (Strictly, the baud rate is the number of signalling symbols per second, and it equals the bit rate only when each symbol carries one bit — true for ordinary two-level asynchronous signalling but not for the multi-level modulation used in modems.)

ii) The consequence of disagreement. The receiver starts a bit-time counter at the falling edge of the start bit and then samples at the middle of each subsequent bit cell, using its own clock. If its bit time differs from the transmitter's by a fraction \(\varepsilon\), the sampling point drifts by \(\varepsilon\) of a bit cell per bit, and the error accumulates across the frame because there is no further edge to re-align it. For an eleven-bit frame the last bit is sampled about \(10.5\,\varepsilon\) bit times away from its centre, so the sampling instant leaves the correct cell once

which is the origin of the familiar rule of thumb that asynchronous links tolerate a few percent of combined clock error and no more. The practical consequences are, in order of severity: framing errors, because the stop bit is sampled where the receiver expects a mark and finds a space, which the receiver reports as an error and which is the usual visible symptom; corrupted data, where bits are sampled from the wrong cells so that the character delivered is wrong but not flagged, if the parity happens to agree; and, at a gross mismatch such as a factor of two, complete failure to communicate, with the receiver mistaking data transitions for start bits and producing an unbroken stream of framing errors and garbage. Nothing is negotiated automatically: the link simply does not work, and it fails in a way that looks like noise rather than like a configuration error — which is why mismatched speed is the classic first thing to check on a dead serial link.

(d) The additional bits in a character frame (3 marks)

Besides the data bits, each frame carries a start bit, an optional parity bit and one or more stop bits.

The start bit is always a single space (logic 0), and since the line idles in the mark state (logic 1) its leading edge is a guaranteed one-to-zero transition. This exists purely to provide the timing reference: it tells the receiver that a character is beginning and starts the bit-time counter that will place all the subsequent sampling instants. Without it a receiver could not tell an idle line from a run of ones, and would have no way to align its sampling to the transmitter's bit cells. Receivers typically over-sample the line (16 times per bit cell is standard) and re-check the start bit at its mid-point, so that a brief noise glitch on the idle line does not trigger a false character.

The parity bit is an error-detecting bit appended after the data bits, chosen to make the number of ones in the data plus parity even (even parity) or odd (odd parity). In the frame drawn above the data byte contains four ones, so the odd-parity bit is 1. It exists to detect corruption in transit: the receiver recomputes the parity of what it received and compares. A single bit flip — the dominant error mode on a noisy line — always changes the parity and is therefore always caught, although any even number of errors passes undetected and parity can detect but never correct. It is optional precisely because it is weak; links that need real integrity use a block checksum or CRC at a higher layer instead.

The stop bit is a mark (logic 1) of one, one-and-a-half or two bit times at the end of the frame. It serves two purposes. First, it guarantees that the line returns to the idle state before the next character, so that the next start bit always presents a genuine falling edge for the receiver to detect — without it, a character ending in a 0 followed immediately by the next start bit would produce no edge at all and the two characters would merge. Second, it provides a checkable framing condition: sampling a space where the stop bit should be proves that the frame was mis-timed, which is exactly how the clock-mismatch failure of part (c) is detected and reported. The longer stop bit lengths are a legacy of electromechanical terminals that needed extra time to reset the print mechanism between characters.

The cost is worth quantifying, because it is what part (b) traded against. A common configuration of one start bit, eight data bits, one parity bit and one stop bit spends eleven bit times to deliver eight bits of information, so the framing overhead is \(3/11 \approx 27\%\); a 9600 bit/s line therefore carries at most \(9600/11 = 872.7\), that is 872 complete characters per second.