在有看门狗定时器的情况下编程

Question

我是嵌入式系统编程的新手，虽然在学习期间学过课程，但离实际编程还有点远。

问题是：我必须在 NXP LPC2103 微控制器（基于 ARM 7）上编写一个小型系统，而无需操作系统。它有一个需要定期更新的看门狗定时器。该系统有一个嵌入 TCP/IP 堆栈的 GPRS 调制解调器，初始化所需的时间比看门狗超时所需的时间长。当我调用初始化函数时，系统会重置。

我与一位更有经验的同事交谈过，他建议我需要从主函数中退出并重新进入相​​同的初始化函数，在该函数中我咬住了看门狗定时器，直到函数完成执行。这个想法听起来不错，但我还想听听其他一些经验。另外，参考资料（书籍或网站）也可能很有用，因为我找不到任何具体的内容。

我不想从初始化函数中调用看门狗定时器，我觉得这不好。

Answer 1

我不想从初始化函数中调用看门狗定时器，我觉得这不好。

对于这种情况，这可能有点过分了，但是我用于长时间运行的操作（您可能想要执行其他工作）的通用技术是让长时间运行的函数接受将定期调用的回调函数指针。我通常使用的模式是拥有一个可能如下所示的回调原型：

int (callback_t*)(void* progress, void* context);

长时间运行的函数将定期调用回调，并提供一些指示其进度的信息（如何将进度表示为它的含义取决于以下详细信息）特定函数）以及原始调用者与回调指针一起传入的上下文值（同样 - 该参数的含义以及它的解释方式完全取决于回调）。一般来说，回调函数的返回值可用于指示“长时间运行的事物”应该取消或以其他方式更改行为。

这样，您的初始化函数就可以采用带有上下文值的回调指针，并定期调用它。显然，在您的情况下，这些回调必须经常发生才能让看门狗满意。

int watchdog_callback( void* progress, void* context)
{
    kick_the_watchdog();

    return 0;  // zero means 'keep going...'
}


void init_modem( callback_t pCallback, void* callback_context)
{
    // do some stuff

    pCallback( 0, callback_context);

    // do some other stuff

    pCallback( 1, callback_context);


    while (waiting_for_modem()) {
         // do work...

         pCallback( 2, callback_context);
    }    
}

这种模式的一个好处是它可以在不同的情况下使用 - 您可能有一个读取或写入大量数据的函数。回调模式可用于显示进度。

请注意，如果您发现有其他长时间运行的函数，则可以使用相同的 watchdog_callback() 函数来允许它们处理防止看门狗重置的问题。但是，如果您发现自己经常需要依赖这种类型的东西，特别是看门狗，那么您可能需要考虑您的任务如何交互，要么更多地分解它们，要么使用更复杂的看门狗方案来管理看门狗通过其自己的任务与其他任务交互以间接保持看门狗计时器的状态。

Answer 2

一般来说，针对这种情况我采用了两种方法。

状态机初始化

第一个就像您的同事所建议的那样：在作为主循环一部分调用的状态机中实现初始化例程，然后停止调用初始化例程并开始调用主例程。

这是一个简单而干净的函数，但是当涉及到特定的长过程（例如启动低频振荡器）时可能会有点尴尬。

限时 ISR 看门狗处理

如果您有“systick”或等效中断，例如每 1ms 触发一次的中断，还有另一种选择。在这种情况下，您可以考虑每 50 次中断调用（例如）向看门狗供电，但限制向看门狗供电的次数，使其等于完成初始化例程所允许的最大时间。然后，通常有必要（如果您有，正如我认为的那样，有一个窗口看门狗）在初始化结束时有一个短同步循环，以确保在达到最小窗口时间之前不会给看门狗供电，但这实施起来很简单。

这是一个非常干净的解决方案（因为它不会使初始化例程成为不必要的状态机）并处理初始化例程挂起的问题。然而，强制执行 ISR 中看门狗调用的限制非常重要。

讨论

两者都有其优点和缺点，但是对于不同的要求采用不同的方法是有用的。我倾向于更喜欢后一种解决方案，其中我有低频振荡器（可能需要一段时间才能启动）之类的东西，因为它避免了初始化例程过于复杂，初始化例程本身就足够复杂了！

我相信其他人也会提供其他替代想法......

Answer 3

LPC2103 中的看门狗是高度可定制的。
您有很多选项来控制它：

您可以在初始化序列结束之前不启用它。

您可以将喂食之间的时间间隔延长至很长一段时间。

问题是你用看门狗做什么？

如果它用来检查你的软件是否运行良好并且没有冻结，我不知道AI的ISR选项将如何帮助你（即使你的程序被卡住，ISR也可以继续工作）。

有关看门狗选项的详细信息，请参阅 MCU 用户手册中的看门狗定时器 (WDT) 第 (17) 章。
http://www.nxp.com/documents/user_manual/UM10161.pdf

Answer 4

看门狗很棒，但当您的程序或系统无法轻松适应时，它也会带来麻烦。当您的代码（通常）看起来像这样时，效果最好：

Watchdog_init();

hardware_init();
subsystem1_init();
subsystem2_init();
subsystem3_init();
...
subsystemN_init();

forever {
   Watchdog_tickle();

   subsystem1_work();
   subsystem2_work();
   subsystem3_work();
   ...
   subsystemN_work();
}

通常您可以以这样的方式设计您的程序，使其能够正常工作，并且通常它是非常简单的（但并非完全如此）。

但在像你这样的情况下，这效果不太好。您最终必须设计和创建（或可能使用库）一个框架，该框架具有必须满足的各种条件，以控制看门狗是否/何时受到抚摸。但这可能非常棘手。该代码的复杂性本身可能会引入其自身的错误。除了看门狗框架之外，您完全可以编写一个完美的应用程序，并且您的项目可能会重置很多，或者您的所有代码可能都很糟糕，并且只是不断地宠爱看门狗，导致它永远不会重置。

更改上述代码以处理更复杂情况的一种好方法是更改​​subsystemX_work函数以跟上状态。这可以通过函数中的静态变量或使用函数指针而不是函数来完成，并更改执行的实际函数以反映该子系统的当前状态。每个子系统都成为一个状态机。

使用快速咬合看门狗解决长时间有意等待的另一种方法是将长时间运行的函数分解为较短的部分。而不是：

slow_device_init();
Watchdog_tickle();

您可以这样做：

slow_device_init_begin();
Watchdog_tickle();
slow_device_init_finish();
Watchdog_tickle();

然后通过执行以下操作来扩展看门狗计时器：

slow_device_init_begin();
for ( i = SLOW_DEV_TRIES; i ; i--) {
   Watchdog_tickle();
   if (slow_device_init_done()) {
       break;
   }
}
Watchdog_tickle();

即使如此，它仍然会变得越来越复杂。通常，您最终必须创建一个看门狗委托，它仅检查要满足的条件，并根据这些条件是否宠爱看门狗。这开始变得非常复杂。它可以通过为每个子系统创建一个对象来实现，该对象具有一些方法/函数来调用以测试子系统的运行状况。健康方法可能非常复杂，甚至可能随着子系统状态的变化而改变，尽管它应该尽可能简单，以便尽可能容易地验证代码是否正确，而且还因为改变了子系统的状态。子系统的工作需要改变您衡量健康状况的方式。

如果您可以确保某些代码定期运行，那么您可以为每个子系统提供一个整数，充当子系统的本地看门狗。一些代码（可能在定时器中断处理程序中，但不一定）将递减并测试每个子系统的变量。如果任何子系统的值达到 0，则看门狗不会被触发。

Watchdog_periodic() {
   for_each subsustem in subsystem_list { // not C, but you get the idea
      if ( 0 > --(subsystem->count_down) ) {
           // Do something that causes a reset. This could be returning and not petting
           // the hardware watchdog, doing a while(1);, or something else
      }
   }
   Watchdog_tickle();
}

然后，每个子系统都可以通过将其 count_down 设置为正值来在不同的时间量内触发自己的 count_down。

您还应该注意到，这实际上只是一个软件看门狗，尽管它可能利用硬件看门狗来进行实际的重置。

您还应该注意，看门狗框架越复杂，其中出现错误的机会就越多，其他代码中出现错误导致其无法正常工作的机会也就越多。例如，诸如以下的指针错误

int x;
fscanf(input, "%i", x); // Passed uninitialized x rather than address of x

可能会导致设置某些子系统的 count_down 值，这最终可能会阻止看门狗在应该执行的情况下执行操作。

Answer 5

您可能会重新考虑在代码中为 WD 计时器提供服务的位置。

通常，WD 定时器需要在空闲时间（空闲循环或空闲任务）和最低级别驱动程序中提供服务（例如，当您从 GPRS 调制解调器或 TCP/IP 连接的 MAC 读取/写入时等）。 ）。

如果这还不够，您的固件可能除了在延迟例程中消耗 CPU 周期之外什么也不做。可以在此处添加 WD 计时器服务，但您可能需要调整延迟计时器以考虑 WD 服务时间。

如果您的应用程序只是有一些长时间的 CPU 密集型任务，这些任务需要比 WD 计时器周期允许的更多时间来执行，您可以考虑将 WD 计时器间隔设置得更长一些。这可能并不总是可行，但我喜欢将 WD 计时器引用保留在固件上层之外，以保持应用程序层尽可能可移植。 WD 定时器通常依赖于硬件，因此代码中的任何 WD 定时器引用很少是可移植的。无论如何，低级驱动程序很少是可移植的，因此这通常是服务 WD 计时器的更好地方。