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に近くなります。それは忠実に待ってから、次のものを再び正しく取得し、次に間違って(長く)、交互に行ったり来たりします。