RTOS多任务环境中使用看门狗的重要性

1994年1月25日，美国国家航空航天局（NASA）发射了克莱门汀号卫星，该卫星用于在太空环境下对传感器和航天器组件进行长时间暴露测试。不幸的是，由于缺乏几条关键的看门狗代码，该卫星的任务在1994年5月7日失去了联系。

克莱门汀号在完成了两个月的月球制图任务后离开了月球轨道，前往下一个目标近地小行星Geographos。然而，不久之后，克莱门汀号的一台机载计算机发生故障，导致NASA无法操作该航天器，并导致其中一个推进器失去控制地开始“开火”。

NASA花了20分钟的时间尝试重新激活该系统，但徒劳无功。最终，执行硬件重置命令使克莱门汀号重新上线，但为时已晚，它的燃料已经耗尽，因此不得不取消任务的继续进行。

随后，克莱门汀号软件开发团队意识到他们在实施软件超时方面存在问题，因此希望他们使用了硬件的看门狗定时器来避免类似情况的发生。

看门狗如何提供帮助？

看门狗是一种硬件，可以直接集成到微控制器（MCU）中，或者从外部连接到微控制器。它的主要目的是在可以安全地假定系统已挂起或执行不正确时执行错误处理（通常是硬件重置）。

看门狗的主要组件是一个计数器，该计数器最初配置为某个值，然后递减为零。软件必须经常将此计数器重置为其初始值，以确保其永远不会达到零。否则，可能会导致故障，并且通常会复位CPU。这表明看门狗是万不得已的选择，只有在其他所有方法都失败后才可以选择，就像克莱门汀那样。

如何喂看门狗

正确使用看门狗定时器并不像重新启动计数器那样简单（此过程通常称为“喂”或“踢”看门狗）。在系统中运行看门狗定时器的情况下，开发人员必须仔细选择看门狗的超时时间，以便看门狗可以在故障系统执行任何不可逆的恶意操作之前进行干预。

在简单的应用程序中，特别是在不使用RTOS的情况下，开发人员通常会从主循环中提供看门狗。这种方法只需要配置适当的初始计数器值即可，就像选择一个超出整个主循环的最坏情况执行时间至少一个计时器周期的任何值一样简单。这通常是一种相当健壮的方法：虽然某些系统需要立即恢复，但其他系统仅需要确保它们不会无限期挂起-这肯定会完成工作。

在多任务（RTOS）环境中

在更复杂的系统中，尤其是在多任务系统中，由于各种原因可能会使线程挂起。有些线程可以长时间不运行，例如等待接收数据的通信线程。定期提供看门狗的干净方法，同时仍要确保每个不同的过程都处于良好状态，这已成为这些系统开发人员的主要挑战，例如，他们需要关注以下方面：

• 操作系统是否正常执行。
• 高优先级任务是否耗尽了CPU，从而完全阻止了低优先级任务的运行。
• 是否发生了阻碍执行一项或多项任务的死锁。
• 任务例程是否正确且完整地执行。
• 开发人员还需要确保对源代码进行的任何修改（无论是专用的看门狗任务还是对受监视任务的特定修改）都必须小且针对效率进行优化，以将干扰最小化。

利用RTOS的看门狗支持

有些RTOS操作系统（如SEGGER的embOS）自带有看门狗解决方案，从而简化了看门狗的处理，从而减少了在任何开发过程中花费的时间。

在RTOS中实现硬件看门狗的方法有很多种，我记得之前给大家分享过。其实，懂一些基本原理，自己都能设计。比如：每个任务添加“有关看门狗的计数”，超过设定时间做一定处理，否则看门狗复位。

当然，一些操作系统自带的看门狗功能，只需要调用API函数即可。比如embOS：任务可以简单地在embOS看门狗模块中注册自己，并且可以同时分别配置其超时时间。然后，该任务可以通过调用一个简单的embOS API函数来发信号通知其正确执行。是否所有受监视的任务都已在其指定的超时时间内发出信号以指示其已正确执行，随后将通过另一个单个embOS API调用进行检查，该调用可以从专用的看门狗任务中，从OS_Idle（）内部，甚至从定期OS内部执行定时器中断服务程序或任何其他ISR。

用户只需要提供和注册两个功能：第一个执行看门狗的硬件相关馈送，而第二个指定在看门狗计数器达到零的情况下采取的进一步操作。例如，这允许将日志文件存储到Flash，其中包含有关系统状态的更多信息，然后再执行硬件重置或采取任何其他措施。

最后

在开始使用看门狗设计和开发应用程序时，尽早决定打算如何使用看门狗，并考虑可用的工具来帮助你更快地实现它。至少，你不想被困在“太空”中，对吧？

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！