Device tree, pin multiplexing and GPIO

Learning goals

By the end of the week a student can:

• Read a device-tree node: compatible, reg, interrupts, clocks, regulators and status.
• Look up a header pin's multiplexed functions, and say how one is selected.
• Write an overlay that binds an in-kernel driver, and verify it in /sys and /dev.
• Size an LED's resistor, and switch a motor through a MOSFET with a flyback diode, saying why a pin cannot drive it.
• Drive and read GPIO with libgpiod within the header's electrical limits, and explain why Linux is not hard real time.

Lecture 1, block 1: why a device tree

• A PC's buses announce what is plugged into them; most peripherals on an Arm system-on-chip cannot.
• So the board ships a description of its hardware: a tree of nodes, one per device.
• Each node says what it is (compatible), where its registers are (reg), and which interrupts, clocks and regulators it uses; status turns it on or off.
• The live tree is under /proc/device-tree; dtc decompiles it.

Lecture 1, block 2: pin multiplexing

• One pad can be a GPIO, or an I2C, SPI, UART or PWM signal.
• A register selects which; the device tree's pin-control nodes tell the kernel what to select.
• The GPIO pinout shows every function a header pin's pad can carry and the register write that selects each.
• Only one function owns a pad at a time: enabling I2C on two pins takes them from GPIO. ldto conflicts checks whether two overlays claim the same pin; gpioinfo shows whether a line is held by a bus, a driver or a program. Show module 9's pin-multiplexing figure.

Lecture 1, block 3: overlays

• A patch to the board's device tree, applied live to the running kernel or merged so the bootloader loads it at boot, that enables a bus on header pins or adds a part on it.
• No kernel or base-tree rebuild.
• When the added part has an in-kernel driver, the kernel probes it and it appears in /sys and /dev with no code written.
• Libre Computer's ready-made overlays and the tool that applies them: libretech-wiring-tool.

Lecture 2, block 1: the electrical limits

• The header is 3.3 V logic; the inputs are not 5 V tolerant. Never 5 V on a GPIO pin: it can damage the system-on-chip for good.
• A pin supplies a few milliamps. Enough for an LED through a resistor: work the 680 Ω example from lab 6's GPIO steps with module 10's formula.
• Not enough for a motor, relay or LED strip: those switch through a logic-level MOSFET, a load under about 200 mA, such as lab 6's motor or a relay coil, from the 5 V pin and anything larger from its own supply with grounds joined; a coil needs a flyback diode across it. Walk through module 10's figure.
• Pull-ups give an open input a defined level; edges are what an input program waits for.
• Power off before rewiring.

Lecture 2, block 2: GPIO from Linux

• The GPIO character device, through libgpiod: gpiodetect, gpioinfo, gpioset, gpioget, gpiomon, then the library from a program.
• The pinout gives each header pin's chip and line; gpioinfo shows which lines a bus or driver already holds.
• An LED with a series resistor, and a button debounced in software.

Lecture 2, block 3: latency

• Linux is not a hard real-time system: the same GPIO toggle takes a different time under load.
• Measure it on the logic analyser, many times, idle and under load.
• Plot it as a histogram; the tail is the point.

Board demo

1. Show /proc/device-tree, and decompile it with dtc.
2. In the GPIO pinout, select a header pin and read its functions.
3. Apply a ready-made overlay with the wiring tool and show the new device appear.
4. Measure an LED's current with the multimeter in series, then switch a small motor through a MOSFET from a GPIO pin, pointing out the flyback diode's direction.
5. Blink an LED with libgpiod with the logic analyser on its pin, then add a CPU load and show the timing spread.