我正在研究客户提供的定制/专有RTOS .
RTOS使用具有优先级抢占的循环调度 .
情景是 -
Renesas H8S控制器以20 MHz运行我已配置中断以太网中断（LAN9221芯片正在中断）从LAN控制器读取数据的OS任务在OS中以最高优先级运行另一个OS任务TCP是第二高优先级系统中的任务一个参考监视器的OS任务
我已经生成网络流量来模拟网络上的轰炸状况 . 问题是以太网上的高数据速率（超过500个数据包）ISR看门狗被激活，配置为1秒 .
看门狗配置为由OS的低优先级任务提供服务，以检测OS功能中的任何问题 .
我怀疑ISR和更高优先级任务的频率不会让看门狗任务被安排 . 为了证实我的疑问，我已经在ISR中为看门狗提供服务，并且发现工作到2000包/秒 .
您能否建议如何处理这种情况，以便看门狗即使在更高的数据/中断率下也不应该触发 .
在正常操作系统优先级运行的OS任务中刷新Watchdog，这有助于捕获无限循环 .
OS优先级最高的任务是以太网数据包读取任务 . 当以太网接收数据包时会产生一个硬件中断，而在ISR中我们会安排等待以太网数据包读取任务 .
同样在我的系统中，OS没有使用定时器中断运行（与其他OS运行一样） . 操作系统是循环操作并自愿放弃控制 . 因此，不可能将看门狗任务优先级提高到正常值以上，否则操作系统将始终以更高的优先级和准备就绪（看门狗在无限循环中刷新而不等待任何事件），并且其他任务将无法获得执行时间 . 只有等待某些事件的任务才能具有高优先级 .
所以问题是看门狗任务没有时间刷新，因为频繁的中断和连续调度高优先级任务（以太网数据包读取） .
4 回答
尽量给看门狗一个更高的优先级 .
乍一看，这似乎是错误的 . 看门狗不应该获得高优先级，但这仅适用于没有负载的系统 . 在负载很重的情况下，调度会将监视器推回（毕竟它是低prio），这可能导致虚假的超时 .
给监视器一个高优先级不应该对性能产生很大影响（这是一个小任务，不经常运行，由中断触发）但确保它不会饿死 .
缺点是您不能再捕获无限循环（因为循环现在可以被看门狗中断） .
您还应该考虑设计糟糕的硬件或中断的错误映射 . 也许你可以给看门狗IRQ一个比网卡更高的优先级 . 这将允许看门狗及时处理其中断，而无需为任务提供更高的优先级 .
或者，您可以尝试在处理网络数据包时递增计数器 . 一个新的，高优先级的看门狗线程可以观察这个计数器并重新配置低prio看门狗任务，只要计数器发生变化就不会触发 .
在任何形式的实时应用程序中，根据定义，您需要100％了解正在发生的事情 . 您必须知道每个任务消耗的时间 . 通过切换引脚，使用示波器测量每项任务所需的时间 . 然后calculate这些时间用于整个系统 . 如果优先级较高的任务需要花费太多时间，那么显然狗会饿死 .
如果由于非循环或非确定性行为而无法进行测量，则需要修复程序 . 如果看门狗处于高优先级任务中，那么对于任何具有较低prio的任务，您几乎都禁用它 . 你不妨完全关闭看门狗 .
试用和错误补丁，给看门狗更高的prio，或增加CPU时钟，直到bug消失，这根本不是一种专业的方法 .
但当然，硬件可能不足以为您提供如此高的数据负载 . 那么您可能别无选择，只能使用脏补丁或使用合适的MCU从头开始重新设计产品 .
它可能不是告诉如何去做的问题，你描述的架构应该工作 . 你需要做的是发现看门狗没有的原因提供服务 .
如果您的RTOS没有用于调试和测试的工具或工具，您可以在看门狗循环中添加I / O切换并使用示波器进行观察 - 所有停止切换的时段都是更高优先级的任务或中断正在运行的地方-if发生超过一秒钟，看门狗将触发 . 然后，您可以将类似的工具添加到其他任务和ISR中，以查看花费时间的内容 .
您是否可能在高负载下死锁，以致系统实际上失败了？看门狗射击完全有效的情况 . 如果它实际上检测到系统故障，您不希望停止它 - 您想要修复系统故障 .
如果处理网络数据包的任务耗费大量时间，则会阻止负责刷新监视程序的任务获得CPU时间;那么系统无法处理高网络负载 . 看门狗问题只是这种“无法处理高网络负载”问题的症状 .
解决方案是使用更快的CPU，减慢网络速度，减少处理数据包的开销，或者这些选项的某些组合;这样系统就可以处理高网络负载（这样刷新看门狗的任务就会运行） . 注意，“处理高网络负载”可以包括丢弃分组，这是用于处理网络拥塞的正常/已 Build 的方法 .