嵌入式系统 - 看门狗设计浅谈

术语介绍

• 嵌入式：

指嵌入式系统，编程领域下的一个特定的方向。和一般的编程不同，嵌入式编程的对象通常直接是CPU、内存、磁盘；实际产物 通常是可以单独独立运行的设备。例如：冰箱、空调、遥控器、DVD、无人机、监测传感器等。

• 嵌入式Linux：

截至目前：2021.10.16。目前嵌入式编程的框架大致有4种：
1.裸机编程，即单个main函数的形式，通常是while(1)循环的形式，不支持多线程。
2.RTOS(Real-Time OS 实时操作系统)编程，在裸机的基础上，提供了多线程的支持。
3.Linux编程，比RTOS更加复杂，直接运行Linux操作系统，提供虚拟内存、用户空间隔离等支持，可以使用更多的高级特性，例如python、golang、java等。
4.Android编程，即在Linux的基础上，更进一步，提供安卓层面的支持，可以安装apk、有UI界面，一般而言，Android编程主要用在有人机界面的设备上。例如手机、挂号机、自动售货机等。

• 看门狗：

在由单片机构成的微型计算机系统中，由于单片机的工作常常会受到来自外界电磁场的干扰，造成各种寄存器和内存的数据混乱，会导致程序指针错误，不在程序区，取出错误的程序指令等，都有可能会陷入死循环，程序的正常运行被打断，由单片机控制的系统无法继续正常工作，导致整个系统的陷入停滞状态，发生不可预料的后果。

看门狗是一种监控系统的运行状况的手段，通过软硬件结合的方式实现对系统运行状况的监控。稳定运行的软件会在执行完特定指令后进行喂狗，若在一定周期内看门狗没有收到来自软件的喂狗信号，则认为系统故障，会进入中断处理程序或强制系统复位。

背景介绍

正如上面的看门狗介绍中所说，嵌入式系统中都需要一种看门狗机制来保证系统正常运行。否则嵌入式系统通常是无人值守，卡死了也没有人知道，也就无法自恢复。在设计看门狗的时候，也有一定的讲究。

举例，假设现在在一个RTOS系统中，需要启用看门狗保证设备不会卡死。那么不熟练的工程师，可能直接是新加一个线程，定时喂狗（以下简称喂狗线程）。这样的话，假设系统死机，这个线程就不会执行，看门狗得不到喂狗，就会自动重启系统。

但是这样会大概率有bug：

• 假设这个RTOS设备的主要功能是通过串口采集传感器的数据，那么会单独起一个线程（以下简称collect线程）用于采集数据。 假设此线程由于某些原因卡死，或者return退出了，系统显然发生了异常。 那么此时喂狗线程仍然在工作，系统不会发现任何异常，也不会重启。看起来就像看门狗没有起作用一样。
• 同理可以作用于其他的线程。

因此，基于上述问题 本文主要讨论了一种看门狗机制，用于最大程度的保证嵌入式系统在无人值守情况下的稳定性。

第一部分: 什么是稳定性

首先让我们来理解一下，什么是稳定性，防止“卡死”到底是防止什么。

什么是“卡死”

大部分人的概念中，只要设备没有任何输入/输出了，就算作“卡死”。因此防止“卡死”就是防止设备不响应任何输入/输出。

by the way顺便说一句，在安卓Android系统中，大家经常看到系统提示：此程序无响应。 其实这是因为安卓系统默认监控UI进程需要在一定时间内响应用户的触摸输入的操作，如果没响应就会弹出这个提示。

但是，发生了“卡死”并不代表其他线程没有正常工作；没有发生“卡死”也并不代表其他线程正常工作。 总之就是，卡死相对于嵌入式系统的稳定性来说，并不是决定性的指标（虽然大多数情况下可以用来做关键指标）。

什么是“稳定性”

稳定性指的是软件正常工作的时间比例，而“正常工作”的定义需要依据实际情况而定。比如：

• 对于一个每秒采集一次数据的传感器来说，正常工作的定义就是1.每秒采集到一次数据 2.在规定时间（假设2秒）内响应主机发来的读取数据请求
• 对于微信来说，正常工作的定义就是1.100ms内响应用户的触摸操作 2.三秒内响应用户发送消息的请求 3.十秒内响应用户打开相机的操作 …等等

通过上述的分析，可以总结出：系统稳定性的概念和业务逻辑强相关，使业务逻辑在规定时间内执行成功，就是保障系统稳定性。

第二部分：看门狗的设计

经过上述讨论，我们已经得出了概念：使业务逻辑在规定时间内执行成功，就是保障系统稳定性。

因此看门狗的设计也要围绕着“使业务逻辑在规定时间内执行成功”，这个思路来进行。

超时机制

超时机制：
在很多代码设计中，我们都可以看到超时机制的影子，比如java中：
Socket s=new Socket();
s.connect(new InetSocketAddress(host,port),10000);//这里设置超时10000ms

再比如STM32的C语言编程框架HAL中：
HAL_StatusTypeDef HAL_SPI_Transmit(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size, uint32_t Timeout);
调用这些函数时，要求必须传入一个超时timeout参数，如果函数没有在timeout时间内执行完毕，则会返回超时。

这种超时机制其实也是“使业务逻辑在规定时间内执行成功”，但是实际编程过程中仍旧存在一些问题：

• 并不是每个函数都有超时机制。即使是语言自带的库函数，也不一定提供超时机制；更不用说程序员自己写的函数了。
• 超时机制需要调用方来处理超时的异常，在某些情况下，不存在调用方，比如上述我提到的1s采集一次的线程，其没有调用方。
• 当然，为了解决上述两个问题你可以再手动的去包装一次，增加超时机制，但是这个数量会非常多，肯定会有遗漏。

看门狗设计

因此需要一种统一的，位于“顶层”的机制，来保证业务逻辑在规定时间内执行。 如果没有执行完毕，则统一的在这个机制里处理。

如上图所示，此看门狗机制的主要功能有三块：

1. 对于定时执行的业务逻辑，直接通过固定的间隔有没有收到其发来的消息，判断其有没有定时执行。
2. 对于非定时执行的业务逻辑，则需要两次消息，判断两次消息的间隔判断其有没有执行成功
3. 为了保证看门狗机制本身，使用硬件看门狗来保证。

因此，只要实现了上述三点，我们就可以设计出一个能通用的、统一的，可以保证业务逻辑正常执行，也就可以保证软件稳定性的看门狗程序。

示例1：STM32中的看门狗线程

TODO

示例2：嵌入式Linux中的看门狗进程

参考：

论文：Linux进程间通信 gated-content/inter-process_communication_in_linux.pdf

TODO