Linux sysfs GPIO 点灯与 C 编程避坑指南

简介：《GPIO应用linux编程.pdf》是一份面向嵌入式Linux初学者与驱动/应用开发者的实操型技术文档，聚焦通用GPIO在Linux用户态的控制方法，帮助读者理清从sysfs接口到C语言系统调用的完整使用路径。压缩包内仅含1个PDF文件，约419KB，篇幅紧凑、便于随查随用。文档围绕GPIO基本概念、export/unexport导出机制、gpiochip与gpioN属性文件、direction与value的输入输出设置展开，并给出Shell命令范例与C代码范例，还涉及M28x GPIO应用编程、EPC-28x GPIO资源汇总等实例，可作为开发板调试和接口验证的参考。目前已有338人学习，适合需要快速掌握Linux GPIO应用编程、补齐sysfs操作与C程序读写细节的读者按需查阅。

1. 从 /sys/class/gpio 说起：一份把点灯流程拆到 C 代码的 GPIO 应用笔记

GPIO 应用这件事，说穿了就是在用户态把一个引脚拉高、拉低，或者读回它的电平。可真正到板子上，第一次echo 1 > value之前那几步，足够把人卡一下午：编号怎么算、导出为什么失败、写进去为什么没反应。手上这份《GPIO 应用 Linux 编程》PDF 走的是最朴素的路线——不碰驱动源码，只用/sys/class/gpio这套 sysfs 接口，从 shell 命令一路写到 C 程序，把「导出、设方向、读电平、写电平」四个动作讲成可以直接抄的流程，末尾还补了一段 M28x 平台上的 BANK 编号换算和一个完整的 C 范例。

它适合三类人：第一次在 ARM 板上点灯的固件与应用工程师、需要从应用层验证硬件链路的测试人员，以及要给产线写一段不依赖第三方库的点灯自检脚本的人。下面按我实际复现的顺序拆一遍，重点补文档里一笔带过、但真正会翻车的地方。

2. sysfs 模型先立住：export、gpiochip 与 BANK×32 的换算账

很多人上手就echo 68 > export，成了就继续，不成再回来查。这种做法在单板上没问题，一旦换一块引脚更多的板子就抓瞎，因为你并不知道 68 这个数字是从哪来的。sysfs 这套接口的真正价值在于：它把「控制器—引脚组—组内偏移」三层结构摊开在目录里，看懂目录，编号就是算出来的，不是猜出来的。

2.1 目录里到底有哪几样东西

先看一眼/sys/class/gpio下有什么。一个典型的五控制器平台会长这样：

ls -l /sys/class/gpio/ # export gpiochip0 gpiochip32 gpiochip64 gpiochip96 gpiochip128 unexport

export和unexport是两个真实文件，其余五个gpiochipN是符号链接，指向内核里管理该组引脚的那个设备目录。这五个文件的用途，文档里给了一张表，我按实际使用频率重排了一下：

一条命令把这五个控制器的家底打出来，比逐个cat省事：

#!/bin/sh # 列出所有 gpio 控制器：起始编号、引脚数、控制器名 for c in /sys/class/gpio/gpiochip*; do [ -e "$c/base" ] || continue printf "%-22s base=%-5s ngpio=%-5s label=%s\n" \ "$(basename "$c")" \ "$(cat "$c/base")" \ "$(cat "$c/ngpio")" \ "$(cat "$c/label" 2>/dev/null)" done

这里base是起始编号、ngpio是数量，两者相加就是该控制器的编号上界（左闭右开）。五个控制器 base 分别是 0、32、64、96、128，每个 ngpio 都是 32，说明这块板子把 160 个引脚平均分给了五组，编号 0~159 全覆盖。反过来，如果你拿到一个编号 130，先跑这段脚本，就能立刻判断它落在gpiochip128里，组内偏移是 2。这一步判断在排查「导出报参数错误」时非常有用——编号超出任何控制器的区间，写入就会返回EINVAL。

提示：label在某些内核配置下可能是空字符串，脚本里加了2>/dev/null兜底，别因为一个空值把整段循环打断。

2.2 序号 = BANK × 32 + N，这条公式是怎么来的

对分成多个 BANK 的处理器，引脚在硬件手册里按「端口组 + 组内序号」命名，比如 P2.4 就是 BANK2 的第 4 号脚。而 sysfs 需要的是一个全局连续编号，两者之间的换算就是文档里那条公式：

GPIO 全局编号 = BANK × 32 + N

以 P2.4 为例：BANK=2，N=4，编号 = 2×32+4 = 68。反推也很直观——68 除以 32 得 2 余 4，落在 BANK2，组内第 4 位。这条公式成立的前提是每组固定 32 个引脚，绝大多数 ARM 处理器的 GPIO 控制器都是这个粒度，所以能通用；但如果你手上的芯片某个 BANK 只有 24 个脚，公式就得改成按实际 ngpio 累加。

后一种情况更稳妥的算法是不背公式，直接让脚本去问内核：

#!/bin/sh # 输入全局编号，反查它属于哪个控制器、组内偏移多少 N=${1:-68} found=0 for c in /sys/class/gpio/gpiochip*; do [ -e "$c/base" ] || continue base=$(cat "$c/base") ngpio=$(cat "$c/ngpio") if [ "$N" -ge "$base" ] && [ "$N" -lt $((base + ngpio)) ]; then echo "GPIO $N -> $(basename "$c") base=$base offset=$((N - base))" found=1 fi done [ "$found" -eq 0 ] && echo "GPIO $N 不在任何控制器区间内，编号有误"

这段脚本做的是区间匹配，不依赖 32 这个常数。参数N从命令行第一个位置取，缺省 68；-lt $((base + ngpio))是左闭右开判断，避免边界编号被两个控制器同时命中。实际调试时我一般先跑它确认编号合法，再去写export，能省掉一大半「写进去没反应」的困惑。

2.3 为什么用 sysfs，而不是字符设备或直接怼寄存器

在用户态操作 GPIO，至少有四条路可走，各自的适用面差别很大：

sysfs 的定位很清楚：它不追求速度，追求的是「不用编译、不用链接、出问题能一行命令验证」。所以凡是点灯、复位、使能、读按键这类毫秒级、低频次的动作，我都会先用它把链路走通，确认硬件没问题，再去考虑换更快的通道。反过来，如果你的场景是软件模拟 WS2812 这类微秒级时序，sysfs 一定不够——一次write的开销就在几微秒到几十微秒之间抖动，别在这条路上浪费时间。

2.4 引脚复用：先确认这个脚真的能当 GPIO 用

这是文档里一句话带过、但代价最大的一条：如果导出的引脚默认功能不是 GPIO，强行切换会导致它原本对应的外设失效。常见现象是——GPIO 拉高了，网口不通了；或者电平怎么都翻转不了，因为引脚还挂在某个控制器上。

动手前的检查顺序我一般是这样的：先从硬件手册或底板丝印上确认这个脚标了 GPIO 功能，再确认它没有被内核里的其他驱动占用，最后才去export。如果系统开启了 pinctrl 调试节点，可以直接看引脚的当前复用状态：

# 查看引脚复用状态（需要内核开启 pinctrl 调试） ls /sys/kernel/debug/pinctrl/ # 进入对应控制器目录后 cat /sys/kernel/debug/pinctrl/*/pinmux-pins | grep -i gpio

pinmux-pins会列出每个引脚当前被谁 claim、复用成什么功能。看到目标引脚被别的设备名占着，就别硬来了，换脚或者先解绑驱动。这一步做完再导出，后面能少踩很多坑。

3. Shell 侧先跑通：导出、设方向、读写的四条命令链

在写 C 之前，我强烈建议先用 shell 把整条链路跑通。原因很实在：shell 每一步都是独立的，出问题能立刻定位到是导出失败、方向写失败还是电平写失败；而 C 程序把这四步揉在一起，一个-1返回值你不打日志根本不知道卡在哪。

3.1 导出：echo N > export 背后发生了什么

导出的动作本身只有一行：

cd /sys/class/gpio echo 68 > export

写完之后，目录里会多出一个gpio68子目录，里面有active_low、edge、direction、value、power、subsystem、uevent七个文件。这一步的语义是「向内核申请这根引脚的用户态所有权」，内核会去检查：编号是否存在、引脚是否已被别的驱动占用、当前复用是否能切到 GPIO。三项都通过，才建目录。

如果export写失败，shell 会直接甩一句write error: Device or resource busy或者Invalid argument。前者是引脚被占，后者多半是编号不合法——正好对应 2.2 节那段区间匹配脚本要解决的问题。

各属性文件的作用，文档给了表 2，我按调试时的实际用途整理：

3.2 direction 与 value：两个文件撑起全部功能

方向控制就两条命令，读回来验证一下最保险：

cat /sys/class/gpio/gpio68/direction # 刚导出时应为 in echo out > /sys/class/gpio/gpio68/direction cat /sys/class/gpio/gpio68/direction # 应回显 out

direction的写值是字符串in或out，不是数字。这一点在 C 里写代码时特别容易错——写成write(fd, "1", 1)会返回EINVAL。

输出控制同样是往value写一个字符：

echo 0 > /sys/class/gpio/gpio68/value # 输出低电平 echo 1 > /sys/class/gpio/gpio68/value # 输出高电平

输入读取则是cat：

echo in > /sys/class/gpio/gpio68/direction cat /sys/class/gpio/gpio68/value # 返回 0 或 1

这里有个容易被忽略的细节：value文件读出来的是 ASCII 字符'0'或'1'，外加一个换行符\n。所以在 C 里读一个字节拿到的是 0x30 或 0x31，不是 0 和 1。我见过有人在串口里打印出48，然后怀疑板子坏了——其实只是没减'0'。

active_low是个双刃剑。它对输入输出都生效，写 1 之后，你在value里写的 1 实际输出的是低电平，读到的 0 实际是高电平。做低电平有效的复位信号时它很好用，但如果你忘了自己设过，后面所有逻辑都会反着来。调试阶段的习惯是：每次导出后先cat active_low确认是 0。

3.3 一段能直接放进开机脚本的点灯函数

把上面的动作串起来，写成可复用的小脚本，比每次手敲可靠得多：

#!/bin/sh # gpio_out.sh <gpio编号> <0|1> # 作用：导出指定 GPIO 并输出电平，已导出则跳过导出 GPIO=$1 VAL=$2 BASE=/sys/class/gpio DIR=$BASE/gpio$GPIO if [ -z "$GPIO" ] || [ -z "$VAL" ]; then echo "用法: $0 <gpio编号> <0|1>" exit 1 fi # 已导出就不再重复写 export，否则会返回 busy if [ ! -d "$DIR" ]; then echo "$GPIO" > "$BASE/export" || { echo "导出 $GPIO 失败"; exit 2; } sleep 0.05 # 等 udev 建好属性文件的权限 fi echo out > "$DIR/direction" || { echo "设置方向失败"; exit 3; } echo "$VAL" > "$DIR/value" || { echo "写电平失败"; exit 4; }

几个参数和逻辑值得说明：$1是全局编号，必须先用 2.2 节的脚本算好；$2只接受 0 或 1，做产线脚本时可以在前面加一层白名单校验。中间那句sleep 0.05是血泪经验——某些发行版配上 udev 规则时，export返回成功到gpioN目录里文件权限就绪之间有一个极短的空窗，紧接着写direction会拿到Permission denied。加 50 毫秒延迟基本能规避，比去改 udev 规则省事。

用完记得回收，尤其是在反复调试的阶段：

echo 68 > /sys/class/gpio/unexport ls /sys/class/gpio/ | grep gpio68 # 应无输出

注意：unexport之前先把方向改回in，某些平台上输出态直接摘除会让引脚悬空，如果这个脚接着继电器或三极管，动作会抖一下。调试台架上无所谓，接真实负载时务必先拉回安全电平。

3.4 输入侧：把按键读成 0/1 并做最简消抖

读输入比写输出麻烦的地方在于抖动。机械按键在按下和松开的瞬间会有几毫秒到几十毫秒的毛刺，shell 循环读几百次能看到 0/1 乱跳。最简处理是两次采样间隔一段时间，连续一致才算数：

#!/bin/sh # 读 GPIO 输入，连续 3 次一致才认为稳定 GPIO=${1:-68} BASE=/sys/class/gpio/gpio$GPIO [ -d "$BASE" ] || echo "$GPIO" > /sys/class/gpio/export echo in > "$BASE/direction" last="" cnt=0 while [ $cnt -lt 3 ]; do v=$(cat "$BASE/value") if [ "$v" = "$last" ]; then cnt=$((cnt + 1)) else last=$v cnt=1 fi sleep 0.01 done echo "稳定电平: $last"

sleep 0.01是采样间隔，三次一致等于至少 20 毫秒的稳定窗口，对付普通轻触按键够用。如果按键接的是长线或者环境干扰大，把次数提到 5、间隔提到 0.02，抗干扰会明显变好。这套逻辑后面搬到 C 里也是同一个思路，只是把sleep换成usleep、把cat换成read。

4. 落到 C 代码：open/write/read 四个动作与三个返回值判断

shell 跑通之后，C 版本其实就是把每条命令翻译成系统调用。真正要小心的是返回值——文档里的范例把open的失败判了，但write的返回值基本没管，而实际现场出问题的恰恰是write。

4.1 导出这一步有四种返回，不能只判成败

打开export用O_WRONLY，写入编号字符串。这里的关键是写入长度：必须是strlen，不能是sizeof，后面会讲为什么。导出路径的失败模式至少有四种：

我在工程里一般把导出封装成一个函数，先检查目录是否已存在，存在就直接返回成功，这样重复调用不会报错：

#include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <sys/stat.h> #define GPIO_BASE "/sys/class/gpio" /* 导出 GPIO，已导出则直接返回 0 */ static int gpio_export(const char *num) { char path[64]; struct stat st; snprintf(path, sizeof(path), "%s/gpio%s", GPIO_BASE, num); if (stat(path, &st) == 0) /* 已导出，无需重复写 */ return 0; int fd = open(GPIO_BASE "/export", O_WRONLY); if (fd < 0) { perror("open export"); return -1; } /* 关键：长度用 strlen，不能带结尾的 '\0' */ if (write(fd, num, strlen(num)) < 0) { perror("write export"); close(fd); return (errno == EBUSY) ? 1 : -1; /* 1 表示被占用 */ } close(fd); return 0; }

snprintf拼出的路径用于stat判断，避免重复导出触发 EBUSY；write的长度用strlen(num)，因为内核解析的是字符串，多带一个\0有的内核版本会认为输入非法。返回值做了区分：1代表引脚被占用，调用方能据此换脚；-1是其他错误，直接报错退出。这种「用返回值区分错误类别」的写法比单纯perror加exit好用，尤其是在批量初始化十几根线的场景里，一根被占不该让整个初始化流程死掉。

4.2 方向与电平：写字符串、读字符

方向设置对应direction文件，写"in"或"out"：

/* direction: "in" 或 "out"，成功返回 0 */ static int gpio_set_dir(const char *num, const char *dir) { char path[64]; snprintf(path, sizeof(path), "%s/gpio%s/direction", GPIO_BASE, num); int fd = open(path, O_WRONLY); if (fd < 0) { perror(path); return -1; } ssize_t n = write(fd, dir, strlen(dir)); close(fd); return (n == (ssize_t)strlen(dir)) ? 0 : -1; }

这里再次强调strlen(dir)。范例代码里写的是sizeof("in")，也就是 3 个字节，包含结尾的\0，在某些内核版本上write会返回-1并置EINVAL，现象就是「方向设置失败但看不出原因」。这是我在实际项目里真真切切卡过半小时的地方。

电平读写分两条路。输出用write：

/* value 输出：val 取 '0' 或 '1' */ static int gpio_write_val(const char *num, char val) { char path[64]; snprintf(path, sizeof(path), "%s/gpio%s/value", GPIO_BASE, num); int fd = open(path, O_WRONLY); if (fd < 0) { perror(path); return -1; } ssize_t n = write(fd, &val, 1); /* 只写一个字符，不带换行也合法 */ close(fd); return (n == 1) ? 0 : -1; }

写value时一个字符就够，带不带换行内核都能解析。但读的时候不一样——读回来的是'0'或'1'后面跟一个\n，所以缓冲区至少给 2 字节，并且要做'0'的减法。

4.3 完整示例：读一次输入并打印

把上面的函数拼成一个可编译的最小程序，功能是把 68 号脚设为输入、读一次电平、打印出来：

#include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <sys/stat.h> #define GPIO_BASE "/sys/class/gpio" #define GPIO_NUM "68" /* BANK2 的第 4 号脚 */ static int gpio_export(const char *num) { char path[64]; struct stat st; snprintf(path, sizeof(path), "%s/gpio%s", GPIO_BASE, num); if (stat(path, &st) == 0) return 0; int fd = open(GPIO_BASE "/export", O_WRONLY); if (fd < 0) { perror("open export"); return -1; } if (write(fd, num, strlen(num)) < 0) { int e = errno; close(fd); errno = e; if (e == EBUSY) return 1; perror("write export"); return -1; } close(fd); usleep(50000); /* 等属性文件权限就绪 */ return 0; } static int gpio_set_dir(const char *num, const char *dir) { char path[64]; snprintf(path, sizeof(path), "%s/gpio%s/direction", GPIO_BASE, num); int fd = open(path, O_WRONLY); if (fd < 0) { perror(path); return -1; } ssize_t n = write(fd, dir, strlen(dir)); close(fd); return (n == (ssize_t)strlen(dir)) ? 0 : -1; } static int gpio_read_val(const char *num, char *out) { char path[64], buf[4]; snprintf(path, sizeof(path), "%s/gpio%s/value", GPIO_BASE, num); int fd = open(path, O_RDONLY); if (fd < 0) { perror(path); return -1; } ssize_t n = read(fd, buf, sizeof(buf) - 1); close(fd); if (n <= 0) return -1; *out = buf[0]; /* '0' 或 '1' */ return 0; } int main(void) { char v = 0; int r = gpio_export(GPIO_NUM); if (r == 1) { fprintf(stderr, "GPIO %s 被占用\n", GPIO_NUM); return 1; } if (r < 0) { return 1; } if (gpio_set_dir(GPIO_NUM, "in") < 0) return 1; if (gpio_read_val(GPIO_NUM, &v) < 0) return 1; printf("GPIO %s 电平: %c (%d)\n", GPIO_NUM, v, v - '0'); return 0; }

几个点值得单独说。gpio_export里的usleep(50000)是给 udev 留出改权限的时间，去掉它在一部分根文件系统上会偶发Permission denied。errno在close前后要保存一次，因为close本身可能改写errno，这是个很容易忽略的细节。读数时buf给了 4 字节但只取第一个字符，是因为文件里实际内容是"0\n"，多余的字节不关心。

编译命令按目标平台换工具链，用官方工具链前缀或者自己编译器的路径都行：

# 本机调试 gcc gpio_test.c -o gpio_test -Wall # 交叉编译到 ARM 目标板，前缀按实际工具链替换 arm-linux-gnueabi-gcc gpio_test.c -o gpio_test -Wall -static

-static不是必须的，但目标板根文件系统里 glibc 版本和编译机不一致时，静态链接能省掉GLIBC_2.xx not found这类问题。代价是体积大几百 KB，对存储紧张的板子可以在调试完成后去掉。

跑之前记得用杜邦线把 GND 或 VCC 接到目标引脚上，程序打印出的0或1才有意义。悬空引脚读出来的值是不确定的，别拿它判断代码对错。

4.4 文件描述符的生命周期：别指望一次 open 用到底

有人为了「提高性能」，open一次value文件然后循环read，结果发现读到的值永远是第一次那个。原因是value是普通文件语义，读指针停在上次读到的位置，第二次read返回 0，缓冲区里还是旧内容。

两种改法：一是每次read前lseek(fd, 0, SEEK_SET)回到文件头；二是每次重新open。前者开销小，后者更直观。文档范例里用的是lseek：

lseek(fd_dev, 0, SEEK_SET); /* 回到文件头，否则第二次读到 EOF */ read(fd_dev, &value, 1);

如果你的循环频率是几十赫兹级别，open/close的开销完全可以接受，我一般选这种，代码更短、不容易忘lseek。真要上到千赫兹，就该换别的通道了，sysfs 撑不住。

5. 避坑与排查：导出失败、电平不翻转的五条血泪记录

这一章全是从板子上撞出来的。每条都按「看到什么现象、底层是什么原因、怎么改」写，遇到同样的问题可以对号入座。

5.1 现象：echo 68 > export 报 Device or resource busy

原因有两种，先分清是哪一种。第一种是这根脚已经被别的内核驱动 claim 了，比如某个外设驱动在 probe 时就把它申请走了，此时 sysfs 会拒绝导出。第二种是你自己之前导出过，但没unexport，重复写入同样报 busy。

区分方法很简单，先看目录在不在：

ls -d /sys/class/gpio/gpio68 2>/dev/null && echo "已导出，无需再写 export"

目录存在就是第二种，直接用就行。目录不存在还报 busy，就是第一种，去/sys/kernel/debug/pinctrl/*/pinmux-pins里找是哪个设备占着，或者直接换一根丝印上标了推荐的脚。硬抢是不可行的，除非改设备树把那个外设关掉，代价远大于换脚。

5.2 现象：方向设置返回 -1，但 perror 打印 Invalid argument

这就是 4.2 节提到的那个坑。范例代码里写write(fd_dir, "in", sizeof("in"))，长度是 3，把字符串结尾的\0也写进去了。内核解析direction时按字符串严格匹配"in"和"out"，收到带\0的三字节输入，判定为非法值，返回EINVAL。

解决就一句：把sizeof("in")换成strlen("in")，或者用sizeof("in") - 1。同样的错误也会出现在写export的时候——write(fd_export, GPIO, sizeof(GPIO))会多写一个\0，部分内核版本直接拒绝。写 sysfs 属性文件，长度一律用strlen，这条可以当铁律记。

5.3 现象：程序跑完了，万用表量引脚电平没变化

这条最耗时间，因为代码看起来完全正确。常见原因有三个层次，按概率从高到低排：

第一，引脚复用没切到 GPIO。export成功了，direction也写成功了，但引脚在硬件上还挂在别的功能上，写value只是改了一个内核变量，物理引脚纹丝不动。回到 2.4 节用pinmux-pins核对。

第二，被active_low反了。物理上确实变了，只是方向反了，你以为没变。cat active_low确认一下。

第三，量的位置不对。有些底板 GPIO 经过电平转换或者光耦隔离，扩展接口上的电平不等于芯片引脚的电平；还有的脚是开漏输出，没有外部上拉，量出来就是浮的。这种情况要么看原理图，要么换个直连的测试点。

5.4 现象：C 程序读输入，值永远是第一次读到的那个

value文件读指针不回零，第二次read拿到 0 字节，缓冲区保留旧值。表现就是「输入明明变了，程序没反应」。加lseek(fd, 0, SEEK_SET)或者每次重新open，二选一。排查时可以在read后打印返回值n，如果n == 0就是典型症状，比盯着电平值猜快得多。

顺带提一句，读出来的字符是'0'/'1'而不是0/1，做判断时写if (v == '1')，别写if (v == 1)，后者永远为假。

5.5 现象：重启后一切回到原点，脚本报导出失败

sysfs 的 GPIO 状态不跨重启保留，断电之后所有导出记录清零，程序必须自己在启动阶段重新导出。如果点灯逻辑写在应用里，应用启动时补一次export就行；如果写的是开机脚本，记得脚本要在 udev 规则生效之后跑，否则gpioN目录权限还没改好。

更稳的做法是把这段逻辑做成「幂等」的——先stat判目录，存在跳过，不存在才导出，重复执行不报错。3.3 节和 4.1 节的代码都是这么写的，直接用即可。另外unexport也别乱调，尤其在别的进程还开着该引脚 fd 的时候，摘除之后那个 fd 的操作会返回错误，属于典型的「自己给自己挖坑」。

6. 进阶收口：edge 中断、active_low 与封装成库的最小做法

把基础流程跑顺之后，能明显提升实用性的有三个方向。

第一个是edge中断，它能让你不用轮询就读到电平变化。配置方式是把触发方式写进edge文件，然后用poll等：

#include <poll.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> int wait_edge(const char *val_path) { int fd = open(val_path, O_RDONLY); if (fd < 0) return -1; char buf[8]; read(fd, buf, sizeof(buf)); /* 先读一次，清掉"已就绪"状态 */ struct pollfd pfd = { .fd = fd, .events = POLLPRI }; int r = poll(&pfd, 1, 3000); /* 3 秒超时 */ if (r > 0) { lseek(fd, 0, SEEK_SET); read(fd, buf, sizeof(buf)); printf("边沿触发，当前电平 %c\n", buf[0]); } close(fd); return r; }

edge文件先写rising、falling或both之一，poll才会有事件。首次read不能省——内核在打开文件时就置了「就绪」，不清掉会立刻返回一次假事件，这是poll用法里最常见的错误。POLLPRI而不是POLLIN，也是这套接口的特殊之处。

第二个是active_low的正确用法。它适合驱动低电平有效的复位、使能信号：设active_low=1之后，代码里写 1 表示「有效」，不用在业务逻辑里到处取反。代价是所有经过这个引脚的读写语义都翻了，读输入时也要记得反向解读。我的习惯是把它写进引脚的初始化配置里，并要求所有读写都走封装函数，业务层永远看到「1 = 有效」，不做二次判断。

第三个是把这些操作收成一个薄封装，接口只暴露gpio_request、gpio_set_value、gpio_get_value、gpio_free四个，内部处理导出、方向、lseek、errno。封装之后，换平台时只需要改三个宏——sysfs 根路径、引脚编号换算、有效电平——业务代码一行不动。验证封装对不对，用最笨的办法：把输出脚和输入脚用杜邦线短接，程序里翻转输出、读回输入，翻转十次读到十次，说明整条链路（导出、方向、写、读、缓冲）都是通的。这个自环测试我每换一块新板子都会跑一遍，比示波器快，也比盯着代码猜靠谱。

从那以后，我每次接手新的板子，都强制先走一遍「区间脚本查编号 → shell 导出点灯 → C 程序自环测试」这三步，任何一步没通过就不往下写业务代码。前面多花二十分钟，后面少熬两个晚上。希望帮到你。

本文还有配套的精品资源，点击获取