3、GPIO接口调试：寄存器映射、sysfs与libgpiod操作、中断调试与波形测量

GPIO 调试，说白了就是嵌入式开发的基本功。我这些年调过的板子，十块里有八块都跟 GPIO 有关——要么是电平不对，要么是中断没响应，要么是驱动死活拉不起来的“玄学”问题。Rockchip 平台也不例外，它的 GPIO 控制器集成在 Pinctrl 子系统里，跟 IOMUX、上拉下拉、驱动强度这些功能绑在一起。你如果只把它当简单的“高低电平”来调，后面肯定要踩坑。

这一章，我带你从寄存器映射开始，一路走到 sysfs、libgpiod，最后用示波器抓波形验证中断。嗯，咱们一步步来。

3.1 GPIO寄存器映射与Pinctrl架构

Rockchip 的 GPIO 控制器，每个 bank 管理 32 个引脚。以 RK3588 为例，它有 5 个 GPIO bank（GPIO0~GPIO4），每个 bank 的寄存器基地址在 TRM（Technical Reference Manual）里都能查到。我习惯先把 /sys/kernel/debug/gpio 和 /sys/kernel/debug/pinctrl/pinctrl-handles 这两个节点看一眼，确认驱动有没有正确 probe。

你可能会问：“我直接读寄存器不就行了？” 其实没那么简单。Rockchip 的 GPIO 受 Pinctrl 管控，你得先确保 pin 被配置成 GPIO 功能，而不是 I2C、UART 之类的复用。我见过一个案例，同事调了半天 GPIO 没反应，最后发现 pin 被 bootloader 设成了 SDMMC 功能——寄存器读出来全是 0，但电平死活拉不动。

# 读 GPIO0 bank 的 SWPORT_DR 寄存器（假设基地址 0xFD8A0000）
devmem 0xFD8A0000 32

3.2 sysfs操作GPIO：老方法但依然好用

sysfs 接口虽然被标记为“deprecated”，但很多 legacy 项目还在用。我个人觉得，做快速验证的时候，sysfs 比 libgpiod 更直接——不需要编译额外工具，一根命令就能拉电平。

操作步骤很简单：

1. 导出 GPIO：echo 160 > /sys/class/gpio/export（160 是 GPIO 编号，RK3588 上 GPIO4_A0 = 4*32 + 0 = 128 + 32 = 160）
2. 设置方向：echo out > /sys/class/gpio/gpio160/direction
3. 写值：echo 1 > /sys/class/gpio/gpio160/value
4. 读值：cat /sys/class/gpio/gpio160/value

sysfs 最大的坑是 竞争条件。如果你在用户空间频繁写 value 文件，内核态会有延迟。我曾经在某个项目中用 sysfs 模拟 PWM，结果频率只能到 100Hz 左右，再高就失真了。后来换成 libgpiod 的 gpioset，频率直接拉到 1kHz 以上。

3.3 libgpiod：新一代GPIO操作标准

libgpiod 是内核社区推荐的新接口。它通过 /dev/gpiochipN 字符设备操作 GPIO，支持批量读写、事件监听、行消费（line request）等高级功能。Rockchip 平台默认启用 CONFIG_GPIOLIB 和 CONFIG_GPIO_CDEV，所以直接就能用。

常用命令行工具：

• gpiodetect：列出所有 gpiochip 设备
• gpioinfo：查看每个 chip 的引脚信息
• gpioset：设置引脚输出值
• gpioget：读取引脚输入值
• gpiomon：监听引脚中断事件

举个例子，监听 GPIO4_A0 的上升沿中断：

# 先查看 gpiochip 编号
gpiodetect
# 假设 GPIO4 对应 gpiochip3
gpiomon --rising-edge --num-events=5 gpiochip3 0

这里有个细节：gpiomon 默认输出时间戳和事件类型。我在调试一个按键中断时，发现中断触发频率异常高——用 gpiomon 一看，原来是硬件抖动导致每次按下都触发几十次中断。后来在设备树里加了 debounce-interval 才解决。

#include <gpiod.h>
struct gpiod_chip *chip;
struct gpiod_line *line;
int ret;

chip = gpiod_chip_open_by_name("gpiochip3");
line = gpiod_chip_get_line(chip, 0);
ret = gpiod_line_request_rising_edge_events(line, "my-app");
// 等待事件
struct gpiod_line_event event;
gpiod_line_event_wait(line, &ts);
gpiod_line_event_read(line, &event);
printf("event type: %d, timestamp: %ld\n", event.event_type, event.ts.tv_sec);
gpiod_chip_close(chip);

3.4 GPIO中断调试与波形测量

中断调试是 GPIO 调试里最头疼的部分。我总结了一套“三板斧”：

1. 看中断计数：cat /proc/interrupts | grep gpio，确认中断有没有触发。
2. 看中断延迟：用 trace-cmd 或 ftrace 抓 irq_handler_entry 和 irq_handler_exit，看执行时间。
3. 抓波形：示波器或逻辑分析仪直接量引脚，确认硬件信号是否干净。

我遇到过最典型的场景：中断计数一直在涨，但应用层收不到事件。后来发现是 中断触发类型 配置错了——设备树里配了 IRQ_TYPE_EDGE_RISING，但硬件信号是低电平有效，导致中断在电平变化时只触发一次，之后一直卡在 pending 状态。

波形测量这块，我建议你准备一个 逻辑分析仪（比如 Saleae 或国产的 Kingst）。示波器虽然精度高，但通道少，抓多路信号不方便。我一般这样操作：

• 把 GPIO 脚引出到排针，夹上逻辑分析仪的杜邦线。
• 设置触发条件为上升沿/下降沿。
• 在驱动里加 gpiod_set_value() 或直接写寄存器，人为制造电平变化。
• 看波形是否符合预期——比如中断响应时间是否在微秒级。

有一次，我发现 GPIO 中断响应延迟高达 200μs，远超预期的 10μs。用逻辑分析仪一抓，发现中断信号本身就有 50μs 的毛刺。后来在硬件上加了 RC 滤波，软件里也配了 debounce，才把延迟降下来。

3.5 知识结构总览

下面这张图把 GPIO 调试的整个链路串起来了。你可以把它当作调试时的“地图”——从寄存器到用户空间，再到波形验证，每一步都有对应的工具和方法。

这张图把 GPIO 调试分成了三层：硬件层、内核层、用户层。每一层都有对应的工具。你从上往下走，或者从下往上追，都能找到问题所在。我自己的习惯是：先确认硬件波形，再查内核中断计数，最后用 libgpiod 验证用户空间行为。三步走完，90% 的问题都能定位。