最近看到一篇**

只看该作者 · 2007-7-10 21:39

请问大家ucos写的程序里，还用看门狗吗？如果用的话，大家怎么喂狗？是每个任务里都喂吗？如果这样的话，因为ostimetick不停的在调度任务，那么即使一个任务死掉，其他的任务也会来喂狗，不就起不到狗的作用了吗？请教大家。

只看该作者 · 2007-7-11 20:00

1万 · 2007-7-12 07:55

只看该作者 · 2007-7-12 07:59

不同层面上的东西

只看该作者 · 2007-7-12 10:04

看门狗是用硬件来防止死机的，OS属于软件，也有可能死掉，所以在一些场合需要看门狗。
设计一个监控进程，定时收集各个任务发送的联络字，根据一定的策略判断是否有任务死掉，尝试重新激活，如果情况严重就不喂狗引发复位重启。

只看该作者 · 2007-7-12 15:34

我在主函数里打开狗，在主任务的循环里喂狗，如果在多处喂狗，就失去了看门狗的作用。

1万 · 2007-7-12 20:07

如果在RTOS中使用WDT，必须建立一个任务定时刷新WDT，而且任务的优先级必须很高，因为低优先级的任务不能保证得到及时服务，否则使用WDT容易触发复位
，RTOS中任务切换一般是通过中断触发的，而中断程序都死掉是不太可能的，换句话说刷新WDT的任务是很难死掉的，所以作用也不大。。。
情况有点类似于在前后台系统的定时中断中刷新WDT。。。。

只看该作者 · 2007-7-12 21:00

我们公司反正是现在也没有用狗。5楼说的好像可行。6楼说的是否有个问题，如果主任务的优先级高，那么低优先级任务死掉，主任务还能喂狗，狗就没有起作用了，请大家指正。

只看该作者 · 2007-7-12 21:22

    不存在6楼所说的多处喂狗的问题，只在监控进程里进行。
    7楼所说有误。监控进程要和所有被监测进程联络，任何一个进程失去联络都会触发重启判决，不是由它定时喂狗那么简单。监控策略比较复杂，可以尝试激活死掉的进程而不必重启整个系统。
    对于8楼的问题，如果监控进程不断联络每一个被监控的其他进程，那么任何进程死掉，监控进程都可以发现。

1万 · 2007-7-13 09:05

RTOS编程一般都是消息驱动机制,也就是说仅在需要工作的时候任务才被激活,而刷新WDT必须定时或小于一定间隙,这本身和RTOS违背...

只看该作者 · 2007-7-13 12:47

印象中windows也用WDT

只看该作者 · 2007-7-17 23:36

1万 · 2007-7-22 08:19

"看门狗是用硬件来防止死机的，OS属于软件，也有可能死掉，所以在一些场合需要看门狗。
设计一个监控进程，定时收集各个任务发送的联络字，根据一定的策略判断是否有任务死掉，尝试重新激活，如果情况严重就不喂狗引发复位重启。"

回复以上:不喂狗引发复位重启可以用软复位来完成,OS属于软件,那请问你的方法不是软件吗.
你说的和看门狗不是一个回事,你这是通过软件来监控整个软件是否完成了作用...
RTOS中任务都是消息驱动的有可能永远都不运行,比如某个按键解释程序,用户可能长时间不按键,那个任务就不运行,那是否要复位呢...

2万 · 2007-7-22 09:40

只看该作者 · 2007-7-22 09:43

如果你的程序健壮如牛, 能够保证十年不死, 建议不要使用WDT. 如果程序不停的复位, 有几个客户能够接受?
程序死循环和进程僵死实际上都是软件设计上的不健全造成的.
但死机不光是软件上的问题, 实际的工作环境也会对其产生影响. 比如电磁兼容问题, 如果系统在非常恶劣的环境运行, CPU受到干扰, 程序自然跑飞. 这个时候又不能不复位. 碰到这种情况的时候复位的位置就更有讲究了. 保证现场的安全才是最重要的!

只看该作者 · 2007-7-22 11:18

    复位是由看门狗硬件触发的。
    软件+硬件一起完成可靠的监控功能。
    对于被监控的程序，使用者是非常清楚的，不存在判断一个永远也不运行的程序的问题。此种情况下可以不监测或者修改监控策略。

    一般正常运行的程序都不会频繁重启(除非为降低功耗，平时停机睡眠，工作时靠复位激活)，出厂前会进行测试，如果频繁死机会在出货前解决。有时出于安全和数据保全考虑，死机后不能复位或者要卷回处理，不过那得另当别论了。

只看该作者 · 2007-7-22 20:57

嗯学习继续关注~~

-4 · 2007-7-23 20:34

只看该作者 · 2007-7-25 17:36

为了防止任务死锁,我曾经的做法是在最低的任务里喂狗,时间根据任务而定,因为有些任务处理的时间比较长,并且喂狗任务不一定能很快获得调度.
我原来设置为6秒左右.效果还是不错的.

设计一个监控进程，定时收集各个任务发送的联络字，根据一定的策略判断是否有任务死掉，尝试重新激活，如果情况严重就不喂狗引发复位重启

这种方法不错!

在最高级里喂狗能解决硬件问题,但是不能解决软件问题.

-4 · 2007-7-27 07:18

用RTOS，我也有是否用WDT的困扰，不用设计程序顺利些，但是肯定有隐患存在。我喜欢开设一个监控任务，随时跟踪任务的执行状况，那种接力棒式的设计有时候会把事件无缘无故的搞丢了就麻烦大了。WDT倾向于硬件方式可靠。

最近看到一篇**

相关下载

相关帖子

没人回复？

RTOS中用狗没有什么意义...

怎么没有意义？

当然用，

我的经验

随便说说

re

OS里用监控进程喂狗是有效的，

再补充一句

好象只涉及WDT的刷新策略问题

5楼正解

随便说说

当然要，只不过喂狗策略不同罢了

说说我的看法

看门狗属于硬件方法，

继续关注

只有超时处理,不过和狗作用有点像.

在最低的任务里喂狗

很好的议题

甘甜之泉水

技术新星奖章

常驻人口

荣誉元老奖章

坚毅之洋流

十世金身

技术领袖奖章

涓涓之细流

精英会员奖章

以坛为家

技术导师奖章

沉静之湖泊

无冕之王奖章

终身成就奖章

偶尔光临