UART and a driver

Modules this lab uses

• Module 10: I/O
• Module 11: Drivers

What you need

• Your station's board, booted to Linux, reachable over SSH
• Your station's USB-to-UART adapter and the bench PC with a serial terminal
• The MCP3008 ADC wired as in lab 7
• The bench logic analyser

Before you start

Read the rules that keep the board alive. The UART link follows the same rules as the console: three wires, crossed, and never the adapter's power pin.

Steps: UART

1. With the board shut down and unplugged, clip a logic analyser channel to the board's transmit pin on the header UART and its ground to a ground pin, then boot. If you enabled the UART with a live overlay, enable it again: a live overlay does not survive a reboot.
2. Find the UART's device under /dev/tty* on the board.
3. Set the board's end with sudo stty -F <device> 115200 raw -echo, and the same rate in the serial terminal on the bench PC. Over SSH, watch the board's end with sudo cat <device> in one session and send from another with echo hello | sudo tee <device>; type in the bench PC's terminal to send the other way.
4. Repeat at a second baud rate, changing both ends.
5. Set the two ends to different baud rates, send a known message with echo, and capture it on the logic analyser. Set the analyser's UART decoder to the receiving end's rate (the bench PC terminal's), then to the board's, and explain the framing errors you see at the receiver's rate from what it decoded.

Steps: a driver

1. Enable the spidev device again with sudo ldto enable H40P_SPI_0_1CS_DEV (a live overlay does not survive a reboot), and check that it appears in /dev.
2. Write a userspace library for the MCP3008 with a clean API, unit tests that run against a mocked SPI bus, and a small command-line tool that uses it.
3. Take the spidev device off with sudo ldto disable H40P_SPI_0_1CS_DEV and enable the bare bus with sudo ldto enable H40P_SPI_0_1CS. Apply your own overlay that binds the kernel's MCP3008 driver to chip select 0. Its node needs the driver's compatible string and a vref-supply (both in the kernel's devicetree binding documentation; point the supply at a 3.3 V regulator node), reg = <0> for chip select 0, and spi-max-frequency at or below 1000000, lab 7's limit for the part at 3.3 V; read the same channel through its files under /sys/bus/iio/devices/, and compare the two readings.
4. Write down what the kernel driver gives that your library does not, and when you would choose each.
5. Stretch: build and load a minimal kernel module that registers a character device reporting a counter. Read the counter, unload the module, and read its messages with dmesg.

What to measure

• What arrives at each baud rate, and what arrives when the two ends disagree.
• The same ADC channel read through your library and through the kernel's driver.

What you hand in

• A UART capture with its framing errors explained.
• Your library, its tests and the tool.
• The same channel read through your library and through the kernel's driver, and when you would choose each.
• Stretch: the module's source and the dmesg lines from loading and unloading it.
• Your own short report: what you did, what you measured, and one problem you met and how you solved it.

If it goes wrong

If the module will not build, tell your TA: it needs kernel headers that match the image your board runs. If you moved the adapter off the console and the board stops answering over SSH, move the adapter back and read the console. If it will not boot, work down when it will not boot on your bench page.