看门狗定时器（Watchdog Timer，简称 WDT，工程界习惯称为看门狗电路）是嵌入式系统中用于检测系统故障并自动实施恢复的一种硬件定时器机制。它的工作逻辑非常朴素：让系统周期性地向一个后台定时器"报到"，一旦系统因为程序跑飞、陷入死循环、任务死锁或者异常挂起而无法按时报到，这个定时器就会超时溢出，进而触发系统复位或者不可屏蔽中断，把整个系统从故障状态中强行拉回到可用的初始状态。在嵌入式领域，看门狗被普遍定义为一种运行监控部件，其核心是一个在后台独立计数的计数器，它与主程序的执行流程相互独立，专门负责盯着主程序是否还在正常推进。
从工程实现的角度看，看门狗的工作过程可以概括为三步。第一步是初始化，系统上电后软件需要配置看门狗的计数初值、时钟分频等参数并启动它；第二步是周期性喂狗，应用程序必须在规定的时间周期内执行一次喂狗操作，也就是向看门狗的控制寄存器写入特定数据，让内部的计数器重新回到初始值；第三步是超时判定，如果应用代码在超时之前没有完成喂狗，计数器就会递减到零，看门狗据此判断系统已经失去响应，立即产生复位信号或者中断。这三步环环相扣，构成了看门狗完整的监督闭环。
这里的"喂狗"是一个约定俗成的形象说法，其规范表述应当是"看门狗服务例程"或者"清除看门狗操作"。喂狗的实质是向看门狗定时器的重载寄存器写入数据，或者写入一个特定的控制命令，让内部的递减计数器被重新装载为初始计数值。很多教材在描述看门狗时都会强调一句话：看门狗并不能预防故障的发生，它只能保证系统在故障发生之后能够自动恢复。这句话精准地界定了看门狗的职责边界，它本质上是一个纠错与自愈机制，而不是一个防错机制。理解这一点，是正确看待看门狗能力与局限的起点。
初学者最容易犯的错误，就是把看门狗当成一个普通的定时器，认为它无非就是"定时到了就做点事"。这种理解会漏掉看门狗最核心的设计意图。一般定时器的作用是产生周期性的时间基准，用于计时、任务调度、脉冲宽度调制输出、数据采样等，它的超时是系统期望发生的事件，是正常工作流程的一部分；而看门狗的超时恰恰是系统最不希望发生的事件，因为看门狗一旦超时，就意味着系统已经处于异常状态。一般定时器服务于正常业务，看门狗服务于异常检测，两者的出发点完全不同。
两者的另一个关键区别在于超时后的动作。一般定时器超时后执行的是正常的业务逻辑，例如切换任务、刷新显示、采集数据；而看门狗超时后执行的是恢复动作，例如复位整个系统或者进入故障处理中断。可以这样概括：一般定时器参与系统的正常工作，看门狗则监督系统的正常工作是否还在进行。这一区别直接决定了看门狗在系统架构中的特殊地位——它是旁路于正常业务逻辑之外的安全监督部件。
看门狗要解决的核心问题，是嵌入式系统长期无人值守运行时可能出现的"僵死"故障。这类故障的典型表现包括：程序指针跳转到非法地址导致程序跑飞、某个高优先级任务死锁导致整个调度停滞、硬件受到电磁干扰导致寄存器状态被破坏、代码路径存在隐藏缺陷在特定输入下陷入死循环等等。这些故障有一个共同特征：系统不再按预期的逻辑向前推进，但硬件本身仍然在供电、仍然在运行，因此单纯依靠软件自身的逻辑无法察觉自己已经"卡死"。程序已经停止了正常的判断和调度，自然也就无法主动发现并纠正自身的异常。
看门狗正是针对这一盲区而设计的外部监督机制。它独立于主程序的执行流程运行，只要主程序停止喂狗，看门狗就能在超时之后把系统强制复位。正是因为看门狗能够在软件完全失控的情况下仍然发挥作用，它才成为工业控制设备、汽车电子、航空航天、医疗器械等高可靠性领域几乎标配的安全部件。可以说，看门狗是嵌入式系统可靠性的最后一道防线，也是软考嵌入式系统设计师考试中一个虽然体量不大却年年涉及的基础考点。
要真正理解看门狗，就必须深入到它的内部工作机制。看门狗的核心是一个递减计数器，这个计数器由独立的时钟源驱动，在系统上电之后被启动并持续递减。理解看门狗的工作原理，可以从计数、喂狗、超时三个环节逐一展开，把每一个环节的硬件行为和软件语义都搞清楚。
看门狗内部有一个计数寄存器，它的初始值在配置阶段由软件设定。看门狗启动之后，这个寄存器在每个时钟周期减一，当计数值减到零的时候，就产生一个超时事件。超时事件的触发条件极其简单，就是计数器归零，因此看门狗的实现原理非常可靠，几乎不依赖任何复杂的逻辑判断，这是它能够在极端故障条件下依然工作的根本原因。相比之下，基于复杂软件逻辑的故障检测手段，往往在系统出问题的时候自身也一并失效。
这里有一个关键的设计细节必须强调：看门狗通常使用独立的时钟源。以典型的微控制器为例，独立看门狗一般由芯片内部的低速内部RC振荡器驱动，这个时钟源与主系统时钟相互隔离。这样做的好处是，即使主时钟因为电源波动、晶振失效等原因停振，看门狗仍然能够继续计数，从而在系统时钟彻底瘫痪的情况下依然能够触发复位。这一特性被称为看门狗的时钟独立性，是评估看门狗可靠性的重要指标，也是软考命题人反复考查的知识点。
喂狗操作的本质，是把递减计数器重新装载为初始值，从而把超时的"死线"往后推延。应用软件在设计的时候，会确保在所有正常的执行路径上都会周期性地执行喂狗代码。例如，一个主循环每轮执行都会调用一次喂狗函数，只要主循环正常运转，看门狗就永远不会超时。喂狗动作本身十分简单，往往只是向一个寄存器写一个固定的键值，但它所承载的语义却十分重大：它在告诉看门狗，"我还在正常运行，请不要复位我"。
喂狗的语义十分微妙，喂狗频率必须与看门狗的超时周期相匹配。如果喂狗周期远短于超时周期，看门狗几乎不可能超时，监督意义就大打折扣；如果喂狗周期长于超时周期，系统在正常运行的时候也会被误复位。因此，工程实践中喂狗周期通常被设计为超时周期的三分之一到一半，这样既能及时地反映系统的异常，又能为正常程序的执行时间抖动留出足够的余量。喂狗时机与周期的选择，是看门狗设计中一个需要认真权衡的问题。
看门狗超时之后的处理方式主要有两种：系统复位和中断。复位是最常见的处理方式，看门狗超时之后直接产生内部复位信号，将处理器、外设和大部分寄存器恢复到上电初始状态，程序从复位向量处重新开始执行。这种方式最为彻底，能够清除绝大多数因为程序跑飞或者数据损坏而导致的故障状态，代价是丢失运行现场的上下文信息。
另一种方式是产生中断，例如不可屏蔽中断。看门狗超时之后先进入一个中断服务例程，在这个例程中保存关键的现场信息、记录故障日志，然后再决定是继续运行还是执行复位。这种方式的优点是可以为故障诊断留下线索，缺点是如果系统已经深度死锁，中断本身也可能无法正常执行。因此，在可靠性要求最高的场合，通常会采用"中断加复位"的组合策略，先用中断抢救现场信息，再强制复位。理解这两条路径及其适用场景，是完整掌握看门狗的必要条件。
看门狗能够检测软件故障的底层逻辑，在于它把"程序正常推进"这一抽象概念，转化为了"周期性喂狗"这一可观测的物理信号。一个运行正常的程序，其主循环或者关键任务调度器必然会在有限的时间内重复执行到喂狗代码；而一个卡死的程序，无论卡死的原因是什么，都会停止喂狗。因此，看门狗超时这一事件，等价于"程序在一段时间内没有按预期推进"这一判断，这正是软件故障的可靠标志。看门狗把难以直接观测的软件活性问题，转化为一个简单的计数器状态问题，这是它设计思想中最精妙的地方。
值得强调的是，看门狗判断的是"活性"而非"正确性"。也就是说，看门狗只能确认系统还在活动，不能确认系统所做的事情是正确的。一个程序可能在逻辑上算错了结果，但只要它还在正常喂狗，看门狗就不会介入。这一局限决定了看门狗只能作为最后一道防线，不能替代其他的正确性保障手段，例如校验、断言、冗余计算等。理解看门狗的能力边界，有助于在答题时避免夸大看门狗的作用。
看门狗并不是一个单一的实现，而是有着多种分类。在软考嵌入式系统设计师的考查范围内，最常见的是独立看门狗与窗口看门狗的区分，以及硬件看门狗与软件看门狗的区分。理解这些分类之间的区别与联系，是答对看门狗相关题目的重要前提。
独立看门狗使用独立的低速时钟源驱动，通常由芯片内部的低速内部RC振荡器提供时钟，与主系统时钟完全隔离。由于独立
本篇完！