Golang笔记–04–GPIO与中断

Jul 29, 2018 · 10 min read · golang GPIO 中断轮询 ·

文章目录

前言

最初动笔时，想着把那次涉及到MySQL的故障一起写下，可是搜集资料后，发现关于中断、轮询还有GPIO就可以写很多的内容，全面展开的话大概又会陷入持久战无法产出。刚开始写GPIO和串口代码时，我认为应该有一个库提供这样的功能：检测引脚的电平变化或者边沿变化，当数值改变时读取串口数据，有点像iOS中的键值观察。用到的第一个开源库并没有实现这样的功能，需要主动轮询来检测上升沿和下降沿，上一篇中也有实例代码，每10ms检查一次是否有上升沿或者下降沿，只是碰到检查间隔与硬件触发时间点冲突时，会少收或者多收到数据，在树莓派3上正常运作，但在树莓派 zero w上却出现兼容性问题，随后切换到了另一个库，它的实现就比较符合预想的功能，执行SELECT系统调用，检测到边沿触发时通知用户。

GPIO

上一篇链接：Golang笔记-03

首先是用到的开源库和代码，上一篇中使用的是

github.com/stianeikeland/go-rpio

查看README和源码，可以看到它通过 /dev/mem 或者 /dev/gpiomem 访问引脚，将内存地址转换为指针主动访问，带来的问题也是无法接收到电平变化的通知，需要主动轮询，此外在树莓派zero w上会引起死机。

PS: 找到了github.com/brian-armstrong/gpio这个库在树莓派zero w上死机的原因了，问题出在取地址偏移的函数，它没有像RPI.GPIO一样做好错误处理，详情加到issue了：

Raspberry Pi Zero W compatibility issue

PS: 再度更新，找到bug了，GOARM环境变量在macOS上默认为7，树莓派2代以及3代更新了CPU，支持ARMv7指令集并向下兼容，而树莓派A, A+, B, B+, Zero的CPU还是老款ARMv6的，之所以遇到问题，是因为在官方镜像带的内核上，几乎无法编译出可执行程序，无限卡死，只能先交叉编译后再拷贝过去，然后又忘了指定GOARM......更新内核后就可以在树莓派zero w上编译了

这次使用的是：github.com/brian-armstrong/gpio

通过在 /sys/class/gpio 目录下，为每个使用的引脚创建索引，使用文件描述符来进行GPIO操作，通过SELECT系统调用获取电平与边沿变化，上一篇中相关代码修改如下

全局变量

 1const (
 2	io1    = uint(5)
 3	rst    = uint(13)
 4	intIn  = uint(26)
 5	intOut = uint(21)
 6)
 7// 对串口的引用
 8var s *serial.Port
 9// 对inPin的引用
10var inPin *gpio.Pin
11// 对gpio监视器的引用
12var watcher *gpio.Watcher

初始化串口

与上一篇保持一致，设置了读超时时长

1func startSeril() {
2	c := &serial.Config{Name: "/dev/ttyAMA0", Baud: 115200, ReadTimeout: time.Second * 5}
3	p, err := serial.OpenPort(c)
4	s = p
5	if err != nil {
6		log.Fatal(err)
7	}
8	log.Info("open serial port successfully")
9}

初始化GPIO

在main函数中调用，程序退出前关闭监视器

 1// 设置低电平输出
 2gpio.NewOutput(io1, false)
 3// 设置高电平输出
 4gpio.NewOutput(rst, true)
 5// 设置为输入模式
 6p := gpio.NewOutput(intIn, true)
 7inPin = &p
 8watcher = gpio.NewWatcher()
 9defer watcher.Close()
10// 检测下降沿，低电平有效
11watcher.AddPinWithEdgeAndLogic(intOut, gpio.EdgeFalling, gpio.ActiveLow)
12// 在goroutine中读取引脚状态
13go func() {
14	for {
15		pin, value := watcher.Watch()
16		if pin == intOut && value == 0 {
17			read()
18		}
19	}
20}()

读串口数据

新的库使用了系统调用来获取状态变化，感觉灵敏度有所提升，例如在初始化模块后，模块会立刻返回响应，初始化后返回一个数据包，树莓派3上两个数据连在一起返回，而树莓派 zero w上可以读取到分开的数据，可能与硬件的性能有关，这里根据起始结束符做了特殊处理。由于是从系统缓冲区读取数据，可能会遇到下发的命令响应数据与采集到的数据连接在一块发送的情况，需要根据协议定义起始符和结束符来拆分。这次有点麻烦是命令相应的结束符可能出现在数据中，设计协议时应该尽量避免这种情况。

 1func read() {
 2	data := []byte{}
 3	for {
 4		buf := make([]byte, 50)
 5		n, err := s.Read(buf)
 6		if err != nil {
 7			log.WithField("err", err).Info("read error")
 8			break
 9		}
10		dataRead := buf[:n]
11		data = append(data, dataRead...)
12		if dataRead[n-1] == byte(0x21) {
13			str := string(data)
14			log.Info("RESP: ", str)
15			pushData(str)
16			break
17		}
18		if dataRead[n-1] == byte(0xfe) {
19			if len(data) > 20 {
20				preDecodeBytes(data)
21			}
22			break
23		}
24	}
25	s.Flush()
26}

初始化模块

初始化模块操作与之前相同，拉低电平，2ms后拉高来触发一个下降沿，休眠80ms后发送数据

 1func sendCMD(cmd string) bool {
 2	result := false
 3	inPin.Low()
 4	time.Sleep(time.Millisecond * 2)
 5	inPin.High()
 6	time.Sleep(time.Millisecond * 80)
 7	for i := 0; i < 3; i++ {
 8		data := []byte(cmd)
 9		_, err := s.Write(data)
10		if err != nil {
11			log.WithField("err", err).Info("failed to send cmd: " + cmd)
12			time.Sleep(time.Millisecond * 2)
13		} else {
14			log.Info("REQ: " + cmd)
15			result = true
16			break
17		}
18	}
19	return result
20}

新的开源库在编程和直观的感觉上都会给人一种省电的感觉，毕竟用户空间的操作在接收到通知后才会执行，逻辑上也更清晰，实际测试下来的功耗并没有太多的改变，换一个角度来讲，是操作系统代替了用户轮询的操作，除了使用SELECT外，还有EPOLL（Linux），KQUEUE（Unix）等操作系统提供的系统调用可以使用，常用的RPI.GPIO库，就是在底层使用EPOLL获取引脚状态变化，再封装为Python调用，接下来先讨论文件描述符。

文件描述符

在Unix/Linux中，一切皆文件，几乎所有的操作都是对文件的操作，这次用到库是根据这篇文档实现的：GPIO Sysfs Interface for Userspace

在/sys/class/gpio中可以看到上述代码里打开的引脚

用ps命令获取到程序的PID，在对应的/proc目录下可以看到当前程序的信息

其中fd目录保存着该程序打开的文件描述符

Linux上默认每个进程最多打开1024个描述符，采集程序需要同时开启API并通过HTTP请求上报数据，之前没有正确关闭HTTP请求中的body，导致文件描述符很快被占用完，程序无法上报数据，也不受理HTTP请求，因此需要做好文件描述符的打开和释放，否则即使通过配置增加上限也无法保证程序能长期运行。

SELECT、EPOLL与中断

我们知道用户空间是无法直接操作硬件，只能通过系统调用让操作系统经驱动程序控制硬件，这里涉及到用户态与内核态的切换。

硬件中断是异步的，操作系统接收到硬件中断后，处理硬件发送的电信号并转换为数据，用户读取数据时，从内核空间拷贝到用户空间。

上面的示例程序启动后，通过cat命令查看当前系统中断信息，可以看到正在监控的21号引脚。

在搜索SELECT与EPOLL时，绝大部分内容是关于网络IO问题，有些解答甚至把底层实现都详细解说了一遍，涉及内核调优、文件系统、内存映射、内核态与用户态切换以及大量的数据结构和算法优化，而这里的场景是树莓派上的硬件IO，需要监控的引脚只有一个，但要求实时性高且负载低、省电。

github.com/brian-armstrong/gpio完全使用文件描述符操作GPIO，边沿检测也是利用SELECT系统调用，通过文件描述符监控，而github.com/brian-armstrong/gpio以及RPI.GPIO则使用内存地址偏移来读写引脚数据，但前者只能使用主动轮询引脚数值实现监控，后者使用EPOLL通过文件描述符监控。

处于用户态的采集程序如果使用主动轮询，相当于持续地发起系统调用，从用户态触发串口读取，而使用SELECT或者EPOLL时，由处于内核态的操作系统主动通知用户读取串口。因为硬件中断是异步的，主动轮询的间隔越短，获取到事件通知的实时性越高，相应会占用更多的CPU时间，也消耗更多的电力。

这里使用到的外接模块，其事件触发与数据发送周期都是毫秒级，而树莓派3和树莓派zero w的CPU时钟周期是纳秒级，开头使用10ms的轮询间隔也是实际测试后挑选出的，采集到的数据基本都是正常的，但总会遇到这样的情况：轮询操作刚刚进入休眠时，硬件被环境触发并开始发送数据，但休眠结束时才读数据，遇到CPU压力增大时，从休眠回复的时间可能更长，此时会出现数据异常，少收或者多收到数据。

如果关键数据正好因此被处理为异常数据，采集再多也没有意义，这是最初想要解决的问题，也希望SELECT或者EPOLL减少轮询次数与系统调用，节约电池电量，但结果其实并没有太多差别，倒是让直观上的逻辑更清晰了一些。切换到新的开源库后：

（1）数据的实时性有所提升，例如初始化流程，先下发命令，模块响应，接着进行初始化并返回一个数据。使用主动轮询时，固定存在10ms以上的间隔，通过串口读取的数据包也是分割开的，而使用系统调用后，在树莓派3上经常出现命令响应与采集数据连接在一起返回的情况，因此在解析数据的操作里增加了预处理操作，通过结束符分隔两个数据包；

（2）电量消耗并没有下降，每个设备启动都有最低功耗，显然采集程序与外置模块并不是最大的电量消耗原因，以树莓派zero w为例，电流维持在100~110mA之间，如果每秒采集一个数据，使用四节容量2600mAh的18650并联电池组通过升压模块供电，可以运作29个小时左右。

GPIO库结构

这里浏览一遍github.com/brian-armstrong/gpio的主要内容：

（1）代码结构

io.go，打开或关闭引脚，设置引脚的输入输出模式、高低电平有效状态、输出模式下设置引脚高低电平；

sysfs.go，实现了用户空间的GPIO调用，参照上一节的文档链接与截图内容；

watcher.go，监视器，在内部维护一个heap，保存需要监控的引脚，发起SELECT系统调用，当引脚产生事件时返回；

select_darwin.go及select_linux.go，封装了两个平台下的SELECT系统调用。

（2）读写引脚

  1// 引脚结构，包含编号、输入输出方向、文件描述符引用
  2type Pin struct {
  3	Number    uint
  4	direction direction
  5	f         *os.File
  6}
  7// 首先导出引脚
  8func exportGPIO(p Pin) {
  9	export, err := os.OpenFile("/sys/class/gpio/export", os.O_WRONLY, 0600)
 10	if err != nil {
 11		fmt.Printf("failed to open gpio export file for writing\n")
 12		os.Exit(1)
 13	}
 14	defer export.Close()
 15	export.Write([]byte(strconv.Itoa(int(p.Number))))
 16}
 17// 也可以使用echo命令手动导出
 18echo 21 > /sys/class/gpio/export
 19// 设置输入输出方向及初始值
 20func setDirection(p Pin, d direction, initialValue uint) {
 21	dir, err := os.OpenFile(fmt.Sprintf("/sys/class/gpio/gpio%d/direction", p.Number), os.O_WRONLY, 0600)
 22	if err != nil {
 23		fmt.Printf("failed to open gpio %d direction file for writing\n", p.Number)
 24		os.Exit(1)
 25	}
 26	defer dir.Close()
 27
 28	switch {
 29	case d == inDirection:
 30		dir.Write([]byte("in"))
 31	case d == outDirection && initialValue == 0:
 32		dir.Write([]byte("low"))
 33	case d == outDirection && initialValue == 1:
 34		dir.Write([]byte("high"))
 35	default:
 36		panic(fmt.Sprintf("setDirection called with invalid direction or initialValue, %d, %d", d, initialValue))
 37	}
 38}
 39// 文件描述符，边沿触发监控该文件描述符的数值变化，同时需要根据电平初始值及需要检测的边沿设置高低电平有效状态
 40func openPin(p Pin, write bool) Pin {
 41	flags := os.O_RDONLY
 42	if write {
 43		flags = os.O_RDWR
 44	}
 45	f, err := os.OpenFile(fmt.Sprintf("/sys/class/gpio/gpio%d/value", p.Number), flags, 0600)
 46	if err != nil {
 47		fmt.Printf("failed to open gpio %d value file for reading\n", p.Number)
 48		os.Exit(1)
 49	}
 50	p.f = f
 51	return p
 52}
 53// 电平有效状态，在边沿检测时设置，例如初始状态为高电平，检测下降沿时需要设置为低电平有效，才能在检测到时返回
 54func setLogicLevel(p Pin, l LogicLevel) error {
 55	level, err := os.OpenFile(fmt.Sprintf("/sys/class/gpio/gpio%d/active_low", p.Number), os.O_WRONLY, 0600)
 56	if err != nil {
 57		return err
 58	}
 59	defer level.Close()
 60
 61	switch l {
 62	case ActiveHigh:
 63		level.Write([]byte("0"))
 64	case ActiveLow:
 65		level.Write([]byte("1"))
 66	default:
 67		return errors.New("Invalid logic level setting.")
 68	}
 69	return nil
 70}
 71// 读写引脚，即对文件描述符的读写
 72func readPin(p Pin) (val uint, err error) {
 73	file := p.f
 74	file.Seek(0, 0)
 75	buf := make([]byte, 1)
 76	_, err = file.Read(buf)
 77	if err != nil {
 78		return 0, err
 79	}
 80	c := buf[0]
 81	switch c {
 82	case '0':
 83		return 0, nil
 84	case '1':
 85		return 1, nil
 86	default:
 87		return 0, fmt.Errorf("read inconsistent value in pinfile, %c", c)
 88	}
 89}
 90func writePin(p Pin, v uint) error {
 91	var buf []byte
 92	switch v {
 93	case 0:
 94		buf = []byte{'0'}
 95	case 1:
 96		buf = []byte{'1'}
 97	default:
 98		return fmt.Errorf("invalid output value %d", v)
 99	}
100	_, err := p.f.Write(buf)
101	return err
102}

（3）边沿触发

 1// 包含监听的引脚及对应文件描述符
 2// 增删引脚时同步到heap
 3// 使用channel同步数据，所以在第一部分的<strong>初始化GPIO</strong>中需要开启一个goroutine来执行回调
 4type Watcher struct {
 5	pins         map[uintptr]Pin
 6	fds          fdHeap
 7	cmdChan      chan watcherCmd
 8	Notification chan WatcherNotification
 9}
10// 启动监听，当引脚数量大于0时执行SELECT系统调用，循环调用
11func (w *Watcher) watch() {
12	for {
13		// first we do a syscall.select with timeout if we have any fds to check
14		if len(w.fds) != 0 {
15			w.fdSelect()
16		} else {
17			// so that we don't churn when the fdset is empty, sleep as if in select call
18			time.Sleep(1 * time.Second)
19		}
20		if w.recv() == false {
21			return
22		}
23	}
24}
25// SELECT系统调用，任何一个监控中的引脚数值发生变化时返回
26func (w *Watcher) fdSelect() {
27	timeval := &syscall.Timeval{
28		Sec:  1,
29		Usec: 0,
30	}
31	fdset := w.fds.FdSet()
32	changed, err := doSelect(int(w.fds[0])+1, nil, nil, fdset, timeval)
33	if err != nil {
34		fmt.Printf("failed to call syscall.Select, %s", err)
35		os.Exit(1)
36	}
37	if changed {
38		w.notify(fdset)
39	}
40}
41// 遍历全部监控的引脚数值，封装为一个通知对象传递给用户
42func (w *Watcher) notify(fdset *syscall.FdSet) {
43	for _, fd := range w.fds {
44		if (fdset.Bits[fd/64] & (1 << (uint(fd) % 64))) != 0 {
45			pin := w.pins[fd]
46			val, err := pin.Read()
47			if err != nil {
48				if err == io.EOF {
49					w.removeFd(fd)
50					continue
51				}
52				fmt.Printf("failed to read pinfile, %s", err)
53				os.Exit(1)
54			}
55			msg := WatcherNotification{
56				Pin:   pin.Number,
57				Value: val,
58			}
59			select {
60			case w.Notification <- msg:
61			default:
62			}
63		}
64	}
65}