2

FreeRTOS の xmega256a3 ポートで動作する tickless サポートを取得するのに苦労しています。周りを見回して、ボンネットの下をよりよく理解しようとしていると、次の行が にあることに驚きました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