阻止从Python读取GPIO：如何使用epoll（）和选择.EPOLLET

Question

我正在一个嵌入式系统（armcore）上测试Python的GPIO访问，该系统运行的是用Buildroot（内核4.1.15）构建的linux。在

我希望我的代码阻止等待GPIO2上的pin更改（即，我不想通过反复调用“read”来轮询pin）。我尝试在边缘触发模式下使用“epoll”来执行此操作：

见Python docs for epoll。选择.EPOLLET标志用于获取epoll的边缘触发。另请参见Linux docs for epoll。在

为了简单起见，我已经使用sysfs从控制台设置了GPIO pin：

# cat /sys/class/gpio/gpio2/direction 
in
# cat /sys/class/gpio/gpio2/edge
rising

下面是我的Python代码：

^{pr2}$

为了测试，我用信号发生器的方波为输入引脚供电，每周期2秒，这样我就能看到引脚的变化。在

当我在我的嵌入式系统上运行这个程序时，我得到：

# python3 /usr/sbin/test-gpio-python.py 
EPoll result: [(3, 10)]
FD: 3; Events: 10
-EPOLLPRI!
-EPOLLERR!
--> 0

代码在睡眠1秒时休眠，然后在下一次迭代中，poll（）立即返回，并且不阻塞。它应该被阻止，因为我的输入每2秒只运行一个上升沿。在

为什么“poll（）”没有阻止？

===编辑：===

最初，当我试图使用选择.EPOLLET“：

OverflowError: can't convert negative value to unsigned int

然而，我发现我无意中使用了myPoll=选择投票（）而不是epoll（）。代码现已修复。在

Answer 1

我决定通过查看/proc/interrupts来检查中断信息。在

在这里，对于GPIO引脚，在将边缘设置为“上升”后仅几秒钟：

# cat /proc/interrupts 
...
 33:        421  gpio-mxc   2 Edge      gpiolib
...

嗯，已经有421次中断了！在

两秒钟后：

^{pr2}$

这就可以解释了。中断以每秒大约400次的速度堆积起来，绝对比我用Python处理它们的速度要快。在

用示波器进行的进一步调查表明，信号发生器只输出约1.6伏的电压，而且看起来像是噪声触发了设备上的输入电路。在

当我切换到正确的信号发生器输出并在GPIO管脚上得到一个干净的信号时，我开始获得预期数量的中断，python代码正常工作（即poll（）在输入的上升沿之间正确阻塞）。在