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

EN

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

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

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

长时间运行的函数将定期调用回调，带有一些指示其进度的信息(该进度如何表示为它的含义取决于特定函数的详细信息)，以及原始调用者传递的上下文值和回调指针(同样，该参数的含义和解释完全取决于回调)。一般来说，回调函数的返回值可以用来指示‘长时间运行的东西’应该取消或以其他方式改变行为。

这样，您的初始化函数可以接受一个带有上下文值的回调指针，并定期调用它。显然，在您的情况下，这些回调必须发生得足够频繁，才能让watchdog满意。

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()函数来允许它们处理阻止watchdog重置的问题。但是，如果您发现自己需要经常依赖于这种类型的东西，特别是watchdog，那么您可能需要考虑任务是如何交互的，并将它们更多地分解，或者使用更复杂的watchdog方案，该方案让watchdog由其自己的任务管理，其他任务与之交互，以间接地保持watchdog计时器的工作状态。

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

状态机初始化

首先，正如您的同事所建议的那样:在作为主循环一部分调用的状态机中实现初始化例程，然后停止调用初始化例程，并开始调用主例程。

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

有时间限制的ISR监视程序处理

如果你有一个“系统棒”或等效的中断，还有另一种选择，例如每1毫秒触发一次中断。在这种情况下，您可以考虑喂食看门狗(例如)每50次中断调用，但限制提供给看门狗的次数等于初始化例程完成的最大允许时间。然后，通常有必要(如果你有一个有窗口的看门狗，在我看来，你应该)在初始化结束时有一个短的同步循环，以确保在达到最小窗口时间之前看门狗不会被馈送，但这是很容易实现的。

这是一个相当干净的解决方案(因为它不会使初始化例程变成不必要的状态机)，并且处理了初始化例程挂起的问题。但是，在ISR中强制限制看门狗呼叫是非常重要的。

讨论

两者各有优缺点，但针对不同的需求采用不同的方法是很有用的。我倾向于后一种解决方案，因为它避免了初始化例程的过度复杂，而初始化例程本身就足够复杂了！

我相信其他人也会提供其他的想法。

LPC2103中的Watchdog是高度可定制的。您有许多选项来控制它：

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

您可以将两个提要之间的时间间隔延长到非常长的时间。

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

如果它用来检查你的软件是否运行良好并且没有冻结，我看不出AI的ISR选项对你有什么帮助(ISR可以继续工作，即使你的程序被卡住了)。

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