2

我正在努力获得为我们的 xmega256a3 端口的 FreeRTOS 工作的无滴答支持。环顾四周，试图更好地理解幕后，我惊讶地看到以下行vTaskStepTick()：

configASSERT( xTicksToJump <= xNextTaskUnblockTime );

我没有configASSERT打开，但我认为如果我打开了，那会经常引发问题。xTicksToJump是增量时间，但是xNextTaskUnblockTime，如果我正确阅读代码，是绝对滴答时间吗？我弄错了吗？

我的睡眠功能，按照文档示例的模式如下所示：

static uint16_t TickPeriod; 

void sleepXmega(portTickType expectedIdleTime) 
{ 
  TickPeriod = RTC.PER; // note the period being used for ticking on the RTC so we can restore it when we wake up 
  cli(); // no interrupts while we put ourselves to bed 
  SLEEP_CTRL = SLEEP_SMODE_PSAVE_gc | SLEEP_SEN_bm; // enable sleepability 
  setRTCforSleep(); // reconfigure the RTC for sleeping 
  while (RTC.STATUS & RTC_SYNCBUSY_bm); 
  RTC.COMP = expectedIdleTime - 4; // set the RTC.COMP to be a little shorter than our idle time, seems to be about a 4 tick overhead 
  while (RTC.STATUS & RTC_SYNCBUSY_bm); 
  sei(); // need the interrupt to wake us 
  cpu_sleep(); // lights out 
  cli(); // disable interrupts while we rub the sleep out of our eyes 
  while (RTC.STATUS & RTC_SYNCBUSY_bm); 
  SLEEP.CTRL &= (~SLEEP_SEN_bm);    // Disable Sleep 
  vTaskStepTick(RTC.CNT);  // note how long we were really asleep for 
  setRTCforTick(TickPeriod); // repurpose RTC back to its original use for ISR tick generation 
  sei(); // back to our normal interruptable self 
}

如果有人在那里看到明显的问题，我很想听听。它展示的行为有点有趣。为了测试，我正在运行一个延迟 2000 毫秒的简单任务循环，然后简单地切换一个我可以在我的示波器上观看的引脚。在我的函数中添加一些 printf，它会正确执行第一个，但是在我退出它之后，它会立即重新进入，但值接近 65535。它尽职尽责地等待，然后让下一个再次正确，然后再次错误（长），来回交替。

4

0 回答 0