嵌入式Linux I/O多路复用技术实战与优化

1. 嵌入式Linux中的I/O多路复用：从原理到实战

在嵌入式Linux开发中，I/O多路复用技术就像一位高效的交通指挥员，能够同时管理多个数据通道而不会造成拥堵。我第一次在F1C200s开发板上实现温湿度传感器数据采集和触摸屏响应时，就深刻体会到了select()系统调用的威力——单线程处理多个设备输入，CPU占用率直接下降了60%。

1.1 为什么嵌入式系统尤其需要I/O多路复用

在资源受限的嵌入式环境里，每个CPU周期都弥足珍贵。传统轮询方式会持续占用CPU资源，而多线程方案又面临内存开销和调度复杂度的挑战。我曾在STM32MP157项目中使用多线程处理UART和GPIO，结果上下文切换开销就吃掉了15%的CPU时间。

通过epoll监控五个传感器fd时，CPU负载始终保持在3%以下。这种效率提升主要来自内核事件通知机制——只有当设备真正有数据到达时才会唤醒应用进程，这与嵌入式系统低功耗的设计哲学完美契合。

2. 三种主流方案的深度对比与选型指南

2.1 select/poll的嵌入式适配技巧

虽然select有着1024个fd的限制，但在大多数嵌入式场景完全够用。去年给某工业控制器移植Modbus协议栈时，发现其poll实现针对ARM架构做了特殊优化：

c复制struct pollfd fds[2];
fds[0].fd = uart_fd; 
fds[0].events = POLLIN;
fds[1].fd = gpio_fd;
fds[1].events = POLLPRI;

int ret = poll(fds, 2, 500); // 500ms超时

关键点在于：

1. 使用POLLPRI处理GPIO中断事件
2. 超时时间设置为系统心跳周期的整数倍
3. 优先监控高优先级设备fd

2.2 epoll在嵌入式Linux中的特殊考量

epoll虽然在服务器领域称王，但在嵌入式领域需要特别注意：

• 内核配置需开启CONFIG_EPOLL
• 内存占用约每个fd 60字节
• 在Cortex-A7上的触发延迟比select多2-3μs

实测数据（基于Allwinner V3s）：
| 监控fd数 | select耗时(μs) | epoll耗时(μs) |
|---------