Question

我正在努力为我们的FreeRTOS xmega256a3端口提供无效支持。环顾四周，试图更好地了解内幕，我很惊讶地看到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 
}

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

努力在xmega256a3上实现对FreeRTOS的无滴答支持

0 个答案: