UART, and drivers in user space and the kernel

Learning goals

By the end of the week a student can:

• Explain UART framing, baud rate and flow control, and what a baud-rate mismatch does.
• Explain user space and kernel space, and the bus, device and driver model.
• Write a userspace driver for a peripheral, and say when a kernel driver is the better choice.
• Describe a minimal kernel module.

Lecture 1, block 1: UART

• Asynchronous serial: no shared clock, so both ends must agree on the baud rate.
• Framing: each character is sent in a frame both ends agree on, like the console's 8 data bits, no parity, 1 stop bit.
• Flow control lets a receiver ask the sender to pause.
• From Linux: /dev/tty*.

Lecture 1, block 2: when the ends disagree

• At a mismatched baud rate, the receiver samples at the wrong times.
• The result is framing errors and wrong characters.
• Lab 8 captures this on the logic analyser and explains it.

Lecture 1, block 3: the console is a UART

• The serial console students have used since week 1 is a UART.
• Das Frite's console is on header pins 3 and 5, so the lab enables a second UART; Solitude's console is on its own 3-pin header.
• The same rules: three wires, crossed, never the adapter's power pin.

Lecture 2, block 1: user space and kernel space

• Applications run at EL0 with no direct access to hardware; the kernel runs at EL1 and owns it.
• The driver model: buses, devices and drivers. The kernel matches a driver to a device from the device tree and calls its probe function.

Lecture 2, block 2: which kind of driver

• spidev and i2c-dev let a userspace program talk to a bus directly: quick to write, safe to crash, often right for one program and one part.
• A kernel driver is better when several programs share a part, when it needs fast interrupt handling, or when it should appear through a standard interface.
• The kernel already has an MCP3008 driver in its industrial I/O subsystem; the lab compares it with the students' own library.
• A library deserves a clean API, unit tests against a mocked bus, and a small tool.

Lecture 2, block 3: a minimal kernel module

• Code loaded into the running kernel: an init function, an exit function, and whatever it registers in between.
• The stretch: a character device that reports a counter.
• Building one needs kernel headers that match the running image.
• Its messages appear in dmesg.

Board demo

1. Exchange messages with a PC over a header UART, then set the two ends to different baud rates and show the garbage on screen and the framing on the logic analyser.
2. Bind the kernel's MCP3008 driver with an overlay and read a channel through /sys.
3. Load and unload a minimal module, and show its lines in dmesg.