想到一个关于使用RTOS时，有没必要用看门狗的问题。

只看该作者 · 2013-6-3 16:58

李富贵发表于 2013-6-3 15:08
不胡说八道会死吗你？原来你用的是STM32，前面已经有人说的很清楚了，跑飞直接进HardFault，根本不会像你 ...

谁告诉你只有ARM才能跑ucos，你老先生说话那么多破绽。那些没hardFault功能的单片机，跑位了会跑哪去？跑到哪？？是跑到hardFault里还是跑到你那长刺的口里？
至于你下面说的“你把systick关了无非是OSTimeDly不能用了而已”，你妈比自己再去看看书去！

只看该作者 · 2013-6-3 17:18

yudie 发表于 2013-6-3 16:58
谁告诉你只有ARM才能跑ucos，你老先生说话那么多破绽。那些没hardFault功能的单片机，跑位了会跑哪去？ ...

没Hardfault的单片机跑飞了天知道能跑哪去，你问我我问谁？你连这个都看不懂也敢舔着脸跟我说话？

ucos是抢占式RTOS，很多二逼小白以为Systick是ucos任务调度的唯一手段，如果这是真的，ucos就是时间片任务调度器，时间片没到根本不会响应事件，二逼小白不觉的矛盾吗？滚回去看书的该是你！

只看该作者 · 2013-6-3 17:38

就这点事还能整的这么热闹呀，娱乐无处不在呀。。

只看该作者 · 2013-6-3 17:40

李富贵发表于 2013-6-3 17:18
没Hardfault的单片机跑飞了天知道能跑哪去，你问我我问谁？你连这个都看不懂也敢舔着脸跟我说话？

ucos ...

认栽了今天，碰到二姨家人才了！
我懒得跟你讨论Ucos里任务调度细节，谁不知道信号量，邮箱什么的会引起调度。。这种小白的问题你跟我纠缠我都觉得膈应，就像跟有狐臭的人扭打在一起时的感觉一样。
你TM不知道没HardFault功能的单片机PC跑飞后会到哪，你就闭嘴，这个时候狗都比你强，我说的狗是看门狗。我开这个帖子就是要讨论如何用看门狗拯救这种情况！

只看该作者 · 2013-6-3 17:43

李富贵发表于 2013-6-3 17:18
没Hardfault的单片机跑飞了天知道能跑哪去，你问我我问谁？你连这个都看不懂也敢舔着脸跟我说话？

ucos ...

我还想推断一件事，你咋知道很多小白就像你一样曾经以为“Systick是ucos任务调度的唯一手段”？
这么二逼的低级想法只有你意淫的出来吧？

只看该作者 · 2013-6-3 17:43

yudie 发表于 2013-6-3 17:40
认栽了今天，碰到二姨家人才了！
我懒得跟你讨论Ucos里任务调度细节，谁不知道信号量，邮箱什么的会引起 ...

“但在RTOS中，每个任务都是一个主循环，如果每个任务都喂狗，那么当CPU跑在其中一个任务时，PC指针跑飞，那么这个任务就死掉了，当然其他任务仍然会继续正常运转。”

用你自己的发言抽你自己的耳光。

又不正常运转了，又要看门狗了。你知道PC跑飞了跑的哪里了？讲给我听听让我也乐一乐了，讲不出来就闭嘴。

2万 · 2013-6-3 17:58

我没研究过OS，不过根据我的理解：
在OS中，任务独占CPU只是表象，各个任务和内核之间应当在不停的沟通和协调，你首先保证内核调度不死，再给每个任务设置一个软件看门狗，例如任务执行超时退出等，这样是不是就有了一定保证？

另外，你到底是想保证什么不死？保证内核不死和保证每个任务执行不死，这应该是两回事情把。

1万 · 2013-6-3 18:04

还是讨论技术吧，我认为保证内核不死和每个任务不死都是一样重要，当然办法不一样。

1万 · 2013-6-3 18:05

哪个死了客户都会投诉的。

只看该作者 · 2013-6-3 18:17

z_no1 发表于 2013-6-3 18:04
还是讨论技术吧，我认为保证内核不死和每个任务不死都是一样重要，当然办法不一样。 ...

单个任务卡死，是软件设计逻辑bug，这个问题绝对不能依赖看门狗来解决，否则整个系统的可靠性会非常差，只能靠仔细调试来解决问题。

看门狗解决的问题只应该是由于硬件干扰导致的软件运行不正常。

只看该作者 · 2013-6-3 18:34

不管各种cpu体系架构，只要没有用到类似MMU的功能，跑飞可以认为系统已经不可靠了。其实本质上跟裸机没有区别。
既然我们都是玩实时系统的，所以纠结这些真的没有啥意义了。：）

1万 · 2013-6-3 20:00

这个问题坛子里以前讨论过，好像是叶公的帖子，最好的办法是用另一个MCU监控

只看该作者 · 2013-6-3 20:07

楼主，嵌入式系统的多任务，任务PC跑飞后再恢复。理论上是可以做到
不过这么做的开销和限制条件，你会觉得不如重启来得合算

比如你要处理跑飞的情况，那你的程序中得随时检测PC是不是飞了。
只有这样，飞了之后才能即时还原，减少对其它任务的影响。
一般OS的时钟是几十ms，你把他改成几十ns
这样程序走两步，你就检测一下有没有飞:lol
飞了就用前面没有飞的状态还原。
这个时候你的问题又来了，万一检测程序飞了怎么办:L

只看该作者 · 2013-6-3 20:15

我觉得就楼主这个问题讨论解决方案的意义不大.
我想lz想解决的现象是这样的:在一个任务中,pc指针跑飞.即使用其他的事件触发让RTOS进行任务调度.但是返回该任务的时候pc指针还是跑飞的状态.lz可能希望能够判断出哪个任务跑飞并只重启这个任务.
但是pc指针在跑飞的时候怎么能确保不会对系统造成影响.整个系统都是不稳定的.那恢复某个任务又有什么意义.

1万 · 2013-6-3 21:19

李富贵发表于 2013-6-3 18:17
单个任务卡死，是软件设计逻辑bug，这个问题绝对不能依赖看门狗来解决，否则整个系统的可靠性会非常差， ...

如果在监控任务里加入日志输出功能，倒是调试的一个好助手，可以看到哪出问题了。

只看该作者 · 2013-6-3 21:56

楼主想法是好的，只是现实很无奈。

理论上，只要调度中断及其调度核心不被干扰，还是能够维持运转的。嵌入式一般都没有硬件虚拟地址的保护模式，所以很难止损。楼主应仔细思考楼上的诸位大侠的建议：
"不过看门狗和RTOS是应该分开考虑的。。不能把rtos的可靠性依赖看门狗，当然同样道理，你自己的程序其实也不应该依赖看门狗的。"

只看该作者 · 2013-6-4 07:10

用不用看门狗项目是否使用ＲＴＯＳ无关

只看该作者 · 2015-8-14 12:33

相当热闹啊，我也来凑一脚，说的不好勿喷！
首先，我觉得看门狗在RTOS下还是必要的，在每个任务的主循环里都加上吧，万一用上了呢？
再来说说，是不是白喂狗的问题，当然有可能白喂了！举个例子：
在AVR或430这些没有硬件错误中断的MCU上，跑freertos，现在跑2个任务，Task1是周期型的100MS运行一次，Task2则是等待信号量执行，这个信号量由串口中断给，Task2的优先级大于Task1，当Task1跑不见的时候，只要串口中断按时来，Task2中就还在喂狗，所以Task1中喂的狗就白喂了！
呵呵！大家看是不是这么回事呢！如果有不同意见欢迎探讨！

只看该作者 · 2018-11-13 22:42

好帖子，讨论够激烈。

只看该作者 · 2018-11-14 22:57

程序过于依赖狗来纠错,个人认为这不是个好事情,因为就算狗咬了,你应该怎么处理呢?

想到一个关于使用RTOS时，有没必要用看门狗的问题。

技术高手奖章

经常做客

技术导师奖章

突出贡献奖章

沉静之湖泊

十世金身

技术奇才奖章

以坛为家

湍急之河流

社区建设奖章

终身成就奖章

坚毅之洋流

技术领袖奖章

核心会员奖章

无冕之王奖章

技术新星奖章

伴坛终老