如何禁用/延迟嵌入式系统中某个任务的watchDog Timer

时间:2016-04-23 20:41:28

标签: c embedded task rtos watchdog

我正在开发一个汽车系统项目,我们使用MPC5748 MCU。该应用程序使用基于AUTOSAR OS的RTOS,该MPC目标支持两种类型的监视器;软件和硬件(他们使用了软WDT)。

我的任务是在这个应用程序中拟合算法,算法的开发已经完成,问题是在算法运行的任务中是 1ms任务并且算法需要比致力于此功能的时间多得多。

我是嵌入式世界的新手。顺便说一句,在算法主函数中,程序将自行重置,这似乎是看门狗到期时产生的timeOut。

我的问题是:

  1. 我是否可以禁用此指定功能的看门狗定时器(不能禁用但仅用于测试目的)?可以在指定函数上使用更多timeOut作为看门狗吗?

  2. 我是否必须在其他任务中开发另一个任务来运行算法?但问题是该算法需要与1ms任务同步,因为我们正在接收CAN命令。

  3. 我可以在所需的功能上添加一个睡眠(< 1ms),以便等待一点,而不会影响其他任务

  4. 还有哪些其他选择?

  5. 注意:这是看门狗定时器的一般问题,任何有用的信息对我都有帮助。很抱歉,因为我无法分享代码。

3 个答案:

答案 0 :(得分:2)

我不这么认为你可以禁用/延迟WATCHDOG计时器,即使你认为这不是一个好的选择。

问题在于您所调用的任务是1ms,这对于读取CAN消息然后再进行操作非常简单。我认为最短任务时间应为5ms,最佳时间应为10ms

答案 1 :(得分:2)

  

我是否可以禁用此指定功能的看门狗定时器(不能禁用但仅用于测试目的)?可以在指定函数上使用更多timeOut作为看门狗吗?

让我们忘掉那个 - 这是一个非常糟糕的主意。如果有可能击败看门狗,那么可以通过错误来做,然后看门狗的整点被击败。除了它XY之外的问题 - 关于你提出的解决不同问题的方法的问题 - 你应该直接询问这个问题。

  

我必须在其他任务中开发另一个任务来运行算法吗?但问题是,由于我们正在接收CAN命令,因此算法需要与1ms任务同步。

是的,你需要另一项任务,但你不应该添加“大延迟”,这可能是不必要的,当然也是一个糟糕的设计。如果1ms任务需要算法的结果,那么算法应该在由1ms任务触发的服务任务中运行并异步运行到1ms任务,然后服务任务在可用时将结果提供给1ms任务(通过共享记忆或消息传递或许)。或者,如果1ms任务不特别需要结果,则服务任务可以独立于1ms任务采取必要的操作。

有很多选项,但基本上你的任务分区似乎不合适;您的CAN Rx任务应负责接收仅 的CAN消息,并且响应CAN消息所需的任何操作都会延迟到一个或多个其他任务,可能是从消息队列中提供的。

  

还有哪些其他选择?

软件设计不应该是反复试验 - 设计正确,实施设计。但是你可以考虑1ms是否合适;是否有可能将期限扩展到包含最坏情况执行时间而不会导致无法满足最后期限?如果答案为“否”,则算法不属于此任务。

答案 2 :(得分:1)

  

我是否可以禁用此指定功能的看门狗定时器(不能禁用但仅用于测试目的)?可以在指定函数上使用更多timeOut作为看门狗吗?

您永远不应在代码中的任何位置禁用看门狗。

甚至可能,在MPC5x系列中,您通常只需设置一次看门狗,然后出于安全考虑,所有看门狗寄存器都会转为只读寄存器。

  

我必须在其他任务中开发另一个任务来运行算法吗?但问题是,由于我们正在接收CAN命令,因此算法需要与1ms任务同步。

理想情况下,您应该只从程序中的一个位置为看门狗提供服务。您的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缓冲区永远不会出现溢出。