RTOS多任务环境中使用看门狗的重要性
关注+星标公众号,不错过精彩内容
编排 | strongerHuang
微信公众号 | 嵌入式专栏
1994年1月25日,克莱门汀号发射升空,它是美国国家航空航天局(NASA)的卫星,用于在长时间暴露于太空环境下测试传感器和航天器组件。由于缺乏几条看门狗代码,它的任务于1994年5月7日丢失。
克莱门汀离开月球轨道并前往下一个目标近地小行星Geographos时,已经连续进行了两个月的月球制图。然而不久,克莱门廷的一台机载计算机出现故障,有效地阻止了NASA操作该航天器,并导致其推进器之一不受控制地“开火”。
NASA花了20分钟的时间试图使该系统恢复活力,但无济于事。硬件重置命令最终使克莱门汀重新上线,但为时已晚,它已经用尽了所有燃料,因此必须取消任务的继续。
随后,负责克莱门汀软件的开发团队希望他们使用了硬件的看门狗定时器,因为事实证明,他们实施的软件超时不足。
嵌入式专栏
1
看门狗的主要组件是一个计数器,该计数器最初配置为某个值,然后递减为零。软件必须经常将此计数器重置为其初始值,以确保其永远不会达到零。否则,可能会导致故障,并且通常会复位CPU。这表明看门狗是万不得已的选择,只有在其他所有方法都失败后才可以选择,就像克莱门汀那样。
嵌入式专栏
2
在简单的应用程序中,特别是在不使用RTOS的情况下,开发人员通常会从主循环中提供看门狗。这种方法只需要配置适当的初始计数器值即可,就像选择一个超出整个主循环的最坏情况执行时间至少一个计时器周期的任何值一样简单。这通常是一种相当健壮的方法:虽然某些系统需要立即恢复,但其他系统仅需要确保它们不会无限期挂起-这肯定会完成工作。
嵌入式专栏
3
操作系统是否正常执行。 高优先级任务是否耗尽了CPU,从而完全阻止了低优先级任务的运行。 是否发生了阻碍执行一项或多项任务的死锁。 任务例程是否正确且完整地执行。 开发人员还需要确保对源代码进行的任何修改(无论是专用的看门狗任务还是对受监视任务的特定修改)都必须小且针对效率进行优化,以将干扰最小化。
嵌入式专栏
4
在RTOS中实现硬件看门狗的方法有很多种,我记得之前给大家分享过。其实,懂一些基本原理,自己都能设计。比如:每个任务添加“有关看门狗的计数”,超过设定时间做一定处理,否则看门狗复位。
当然,一些操作系统自带的看门狗功能,只需要调用API函数即可。比如embOS:任务可以简单地在embOS看门狗模块中注册自己,并且可以同时分别配置其超时时间。然后,该任务可以通过调用一个简单的embOS API函数来发信号通知其正确执行。是否所有受监视的任务都已在其指定的超时时间内发出信号以指示其已正确执行,随后将通过另一个单个embOS API调用进行检查,该调用可以从专用的看门狗任务中,从OS_Idle()内部,甚至从定期OS内部执行定时器中断服务程序或任何其他ISR。
用户只需要提供和注册两个功能:第一个执行看门狗的硬件相关馈送,而第二个指定在看门狗计数器达到零的情况下采取的进一步操作。例如,这允许将日志文件存储到Flash,其中包含有关系统状态的更多信息,然后再执行硬件重置或采取任何其他措施。
嵌入式专栏
5
后台回复『RTOS』阅读更多相关文章。
点击“阅读原文”查看更多分享,欢迎点分享、收藏、点赞、在看。