看门狗间隔中的计算和等待，什么时候不能直接相加

最后更新 2026-10-23

⏱ 约 6 分钟 🟡 涉接线/强电

只有同一喂狗路径中互不重叠的时间段才应相加。若某个总耗时已经包含等待，再额外加一次等待会重复预算；并行任务也不能不加分析就串成一条时间链。

本文由器赋开物编辑整理，AI 辅助撰写。下面输入是合成对照，用于复算公式或协议规则，没有连接真实设备完成现场验证。

本次具体要判断什么？

工具把20、50、10ms视作三个非重叠段，得到80ms基础间隔。若你的“计算80ms”实际已是从上次喂狗到下次喂狗的完整测量，就不应再把50ms网络等待加进去。

打开看门狗喂狗间隔预算表，把默认值改为下表场景。文字或字节过长时这里只展示摘要，完整原始输入在附件中。

间隔假设=t计算+t等待+t额外调度；预算=间隔×(1+余量%)

结果项目	对照输出	单位
相加得到的最大间隔假设	80	ms
含规划余量的超时预算	100	ms

三段应互不重叠，且覆盖实际最坏喂狗间隔；不生成具体SDK配置，不证明死锁可被正确检测。

下载本例完整输入、输出与核验记录 JSON。64 位整数按字符串保留，未四舍五入的计算值保存在附件；设备、仪器和实际结论栏目留空，不把预测当测量。

画出真实喂狗调用的起止点，标注每段是否阻止目标看门狗被喂。分别检查任务级和中断级看门狗语义，再把有依据的非重叠段填写。保留完整间隔测量作为交叉核对，不用复杂拆分掩盖重复计数。

不是所有阻塞都等于停止调度，也不是某任务继续运行就能喂到另一个被订阅的任务。工具不判断SDK的实际订阅与复位行为，必须结合官方实现。

分段之和能对应完整路径，平均值、最长值与规划余量分别记录。预算通过后还要验证异常情况下的检测和恢复，不把时间表当作看门狗机制已正确部署。

继续查阅相关原理或其他工具。使用不同工具时先核对输入单位、模型和协议版本，避免把一个场景的结论直接套到另一个场景。

不生成SDK配置，不保证死锁检测和系统恢复；不同看门狗、任务订阅及喂狗语义需查官方实现。

依据：乐鑫：看门狗机制。实现检查覆盖了独立算例和拒绝路径；工具自身通过测试不能替代你对硬件、SDK版本和业务规则的核验。

📄 来源 / 自校链接

本文为公开资料整理，非亲测。关键参数与代码请结合实物与下列官方来源验证。

乐鑫：看门狗机制 ↗
docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/wdts.html

内容有错、看不懂、或想看下一期？告诉我们 →

本文为公开资料的学习整理，非亲测。涉接线/花钱/合规的步骤请结合实物与官方最新资料验证，风险自负。见免责声明。