在没有RTOS的更简单的应用中,我总是从主循环触摸看门狗,这总是足够的.但是,在这里,有许多可能会挂起的进程.什么是一个干净的方法来定期触摸看门狗定时器,同时确保每个过程都处于健康状态？
我在想,我可以为每个进程提供一个回调函数,以便它可以让另一个监督所有的函数知道它仍然存在.回调将传递一个参数,这个参数将是任务唯一的id,所以监督者可以确定谁在回拨.
解决方法
这条路：
>如果一个中断挂起(100％cpu),则kicker任务将不会运行,您将重置
>如果kicker任务挂起,您将重置
>如果另一个任务被挂起,踢球者的任务看不到检查,踢球任务不会踢WDG,你重置
现在当然有实现细节要考虑.有些人将每个任务在全局变量中设置自己的专用位(atomically);踢球者任务以特定的速度检查这组位标志,并且当每个人都进行了检查(当然也是踢WDG)时,清除/复位.)我避开了全局变量,就像瘟疫一样,避免这种做法. RTOS事件标志提供了一种更为优雅的机制.
我通常将嵌入式系统设计为事件驱动系统.在这种情况下,每个任务在一个特定的位置 – 在消息队列上阻塞.所有任务(和ISR)通过发送事件/消息相互通信.这样一来,你不必担心任务没有检入,因为它被阻塞在一个信号量“在那里”(如果这没有意义,抱歉,没有写更多,我无法解释更好).
还有考虑 – 做任务“自主”检查,还是回复/响应踢球者任务的请求.自治 – 例如,每一个任务每个任务在其队列中收到一个事件“告诉踢球任务你还活着”.回复请求 – 一次(或任何),踢球任务告诉大家(通过队列)“时间签入” – 最终每个任务运行其队列,获取请求和回复.考虑任务优先事项,排队理论等适用.
有100种方式来皮肤这只猫,但是单一任务的基本原理是负责踢WDG和其他任务解决踢球任务是非常标准的.
至少还有另外一个方面可以考虑 – 在这个问题的范围之外 – 这就是处理中断问题.如果ISR正在占用cpu(好),上述方法将触发WDG复位,但是相反的情况如何 – ISR(可悲的是)意外地被无意中禁用.在许多情况下,这不会被抓住,您的系统仍将踢WDG,但您的系统的一部分是瘫痪的.有趣的东西,这就是为什么我喜欢嵌入式开发.
