C 如何在嵌入式系统中禁用/延迟特定任务的看门狗定时器

我正在做一个汽车系统项目，我们使用MPC5748单片机。该应用程序使用基于AUTOSAR OS的RTOS，该MPC目标支持两种类型的看门狗；软件和硬件（他们使用了软WDT）

我的任务是在这个应用程序中安装一个算法，算法的开发已经完成，问题是在算法运行的任务中是一个1ms的任务，算法需要的时间远远超过用于此功能的时间

我是嵌入式世界的新手。顺便说一句，在算法主功能中，程序将自行重置，这似乎是看门狗过期时产生的超时

我的问题是：

我是否可以为此指定功能禁用看门狗定时器（不得禁用，但仅用于测试目的）？是否可以在指定功能上为看门狗使用更多超时

我必须开发另一个任务，在其他任务中有很大的延迟来运行算法吗？但问题是算法需要与1ms任务同步，因为我们正在接收CAN命令

---

我可以添加睡眠吗（我不认为你可以禁用/延迟看门狗定时器，即使你可以，那也不是一个好的选择

我认为的问题是，您正在调用的任务的时间为

1ms

，读取CAN消息然后对其进行操作的时间非常少。我认为最短任务时间应为

5ms

，最佳时间应为

10ms

我是否可以为此指定功能禁用看门狗定时器（不得禁用，但仅用于测试目的）？是否可以在该指定功能上为看门狗使用更多超时

让我们忘记这一点——这是一个非常糟糕的主意。如果有可能击败监督机构，那么就有可能因为错误而失败，然后监督机构的全部观点都被击败。除此之外，这是一个问题——一个关于你对不同问题提出的解决方案的问题——你应该直接问这个问题

我必须开发另一个在其他方面有很大延迟的任务来运行算法吗？但问题是，算法需要与1ms任务同步，因为我们正在接收CAN命令

是的，您需要另一项任务，但不应添加“大延迟”如果1ms任务需要算法的结果，那么算法应该在由1ms任务触发的服务任务中运行，并与1ms任务异步运行，服务任务会在可用时将结果提供给1ms任务（可能通过共享内存或消息传递）。或者，如果1ms任务不特别需要结果，则服务任务可以独立于1ms任务采取必要的操作

有许多选项，但从本质上看，您的任务划分似乎不合适；您的CAN Rx任务应该只负责接收CAN消息，并且响应CAN消息所需的任何操作都应延迟到一个或多个其他任务，可能是从消息队列馈送的

还有什么其他选择可以尝试

软件设计不应该是一个试验和错误的问题-设计正确，实现设计。但是你可以考虑1ms是否合适；是否有可能延长该期限以包含最坏情况下的执行时间，而不导致一般未能达到最后期限？如果答案是“否”那么该算法不属于此任务

我是否可以为此指定功能禁用看门狗定时器（不得禁用，但仅用于测试目的）？是否可以在该指定功能上为看门狗使用更多超时

您不应该在代码中的任何地方禁用看门狗

这甚至可能不可能，在MPC5x系列上，您通常只设置一次看门狗，然后出于安全原因，所有看门狗寄存器变为只读寄存器

我必须开发另一个在其他方面有很大延迟的任务来运行算法吗？但问题是，算法需要与1ms任务同步，因为我们正在接收CAN命令

理想情况下，您应该只从程序中的一个位置为看门狗提供服务。您的CAN外围设备将是FlexCAN，它有许多可用于CAN消息的“邮箱”。在大多数情况下，您不需要轮询它，但在所需消息到达时将设置一个标志

因此，我不清楚为什么您需要延迟等待他们。只需执行以下操作：

void the_task (void)
{
  wdog_refresh(); 

  ... // do other things

  if(can_message_available)
  {
    // do something with the message
  }

  ... // do other things
}

而不是

// BAD:
while(!can_message_available)
  ; // do nothing

---

即使您需要使用CAN作为FIFO并重复轮询它，您仍然会使用相同的方法。您只需确保任务运行足够频繁，以确保FIFO缓冲区中不会出现溢出。

我相信（和问题）会对您有所帮助。了解“算法”的运行时间可能会很有用实际运行所需时间-是否固定？是否确定？1ms任务是否直接使用算法的结果？算法的目的是什么？任务的reg职责是什么（除了可以提到的Rx）？您无法共享代码，但概述任务体系结构的伪代码可能会有所帮助。这就是问题。解压缩算法确实有特定的时间，并且取决于已压缩文件的内容……我测量了所用时间，发现算法可以通过10秒（微秒）要解码单个帧和另一个将被解码为大量数据的帧，它将高达800 uS，在最坏的情况下，它将持续超过1ms和更长时间……结果由闪存模块读取以闪存数据。闪存控制器的速度不够快，无法闪存大量数据（解码一个fra后为40 kb）