如何在RTOS中使用看门狗定时器?

use*_*230 12 c embedded rtos watchdog

假设我在嵌入式环境中有一个协作调度程序.我有很多进程在运行.我想利用看门狗定时器,以便我可以检测进程何时因任何原因停止运行并重置处理器.

在没有RTOS的简单应用程序中,我总是会从主循环接触看门狗,这总是足够的.但是,在这里,有许多进程可能会挂起.什么是定期触摸看门狗定时器的清洁方法,同时确保每个过程都处于良好状态?

我想我可以为每个进程提供一个回调函数,这样它就可以让另一个监督所有进程的函数知道它仍然存在.回调将传递一个参数,该参数将是任务唯一ID,因此监督者可以确定谁正在回叫.

Dan*_*Dan 20

一种常见的方法是将看门狗委托给特定任务(通常是最高优先级或最低优先级,每种方法的权衡/动机),然后让所有其他任务"检入"此任务.

这条路:

  • 如果一个中断挂起(100%CPU),踢球者任务将不会运行,你重置

  • 如果踢球任务挂起,则重置

  • 如果另一个任务挂起,踢球者任务没有检查,踢球者任务没有踢WDG,你重置

现在有一些实施细节需要考虑.有些人让每个任务在全局变量中设置自己的专用位(原子地); 踢球者任务以特定的速率检查这组位标志,并在每个人都签入时清除/重置(当然还有踢WDG.)我避开像瘟疫一样的全局变量并避免这种方法.RTOS事件标志提供了一种更优雅的机制.

我通常将我的嵌入式系统设计为事件驱动系统.在这种情况下,每个任务都会阻塞在一个特定的位置 - 在消息队列中.所有任务(和ISR)通过发送事件/消息相互通信.通过这种方式,你不必担心任务没有检查,因为它被阻塞在信号量"那里"(如果这没有意义,对不起,没有写更多我无法解释它更好).

还有考虑因素 - 执行任务"自主"检查或者他们回复/响应来自踢球者任务的请求.自治 - 例如,每秒一次,每个任务在其队列中接收一个事件"告诉踢球者任务你还活着".回复请求 - 每秒一次(或其他),踢球任务告诉每个人(通过队列)"检查时间" - 并最终每个任务运行其队列,获取请求并回复.适用任务优先级,排队理论等的考虑因素.

有100种方法可以为这只猫提供皮肤,但是单个任务的基本原则是负责踢动WDG并让其他任务漏斗到踢球者任务的标准.

至少还有一个方面需要考虑 - 在这个问题的范围之外 - 并且处理中断.如果ISR正在占用CPU,那么上面描述的方法将触发WDG复位(好),但是相反的情况如何 - 一个ISR(可悲地)变得偶然和无意中被禁用.在许多情况下,这不会被捕获,并且您的系统仍然会启动WDG,但系统的一部分仍然瘫痪.有趣的东西,这就是我喜欢嵌入式开发的原因.


Cli*_*ord 5

一种解决方案模式:

  • 每个希望检查的线程都向看门狗线程显式注册其回调,该线程维护此类回调的列表。
  • 安排看门狗后,它可能会迭代已注册任务的列表
  • 每个回调本身都会被迭代调用,直到返回健康状态为止。
  • 在列表的末尾,硬件看门狗被踢了。

这样,任何永不返回健康状态的线程都将停止看门狗任务,直到发生硬件看门狗超时。

在抢占式操作系统中,看门狗线程将是最低优先级或空闲线程。在协作调度程序中,它应在回叫之间产生。

回调函数本身的设计取决于特定任务及其行为和周期性。每个功能都可以根据任务的需求和特征进行定制。高周期性的任务可能会简单地增加一个计数器,该计数器在调用回调时设置为零。如果计数器在输入时为零,则自上次看门狗检查以来,该任务未计划。具有低行为或非定期行为的任务可能会为其计划打上时间戳,如果在某个指定时间段内未计划任务,则回调可能会返回失败。任务和中断处理程序都可以通过这种方式进行监视。此外,因为线程有责任向看门狗注册,所以您可能有一些根本不注册的线程。