RTOSの時間管理に関する6つの誤解
著者:Jean J. Labrosse氏、RTOSエキスパート
ほとんどのRTOSには時間管理のためにタイムソースが備わっていますが、このタイムソースは、ティックレートと呼ばれる一定のレートでCPUの割込みを行うハードウェアタイマによって提供されるのが一般的です。ティックレートは通常10Hz~1000Hzで、1000Hzが最も使用されています。このRTOS専用のタイマは、クロックティック、システムティック、あるいはRTOSティックと呼ばれ、ティックレートが高いほど、RTOSがシステムに課すオーバーヘッドは大きくなります。
このタイムソースは、タスクを一定の時間、遅延(スリープ)させ、イベント発生待ちのタスクが呼び出すAPIのタイムアウトを提供するために使用されます。ティックレートが高いほど、時間遅延やタイムアウトの分解能は(ある一定の値まで)高くなります。たとえば、タスクがイーサネットパケットの到着まで待つことを決定した場合、一定の時間は待ちますが、その後タイムアウトとなります。
以下の疑似コードのスニペットは、タスクの中で時間遅延(スリープ)させるRTOSサービスを用いる方法を示しています。赤字のコードはRTOS APIを示します。ここで注意すべき点は、タスクを1ティック分(ティックレートが1000Hzであれば1ミリ秒)遅延させる場合、2ティックを指定する必要があることです。なぜなら、CPUは所定の時間に1個のタスクしか実行できず、もしこれが優先度の低いタスクの場合、次のティックが到達する直前に実行が終了して、そのタスクが直ちに再実行されてしまう可能性があるためです。1ミリ秒の遅延が必要な場合でも、実際は全く遅延が生じない結果となってしまう可能性があります。
void Task (void)
{
// Task initialization
while (1) {
Delay(#ticks);
Perform some periodic work;
}
}
次の疑似コードは、タスクにイベント(ADC変換、イーサネットパケットなど)を待たせ、タイムアウトを指定する方法を示しています。この場合、イベントの発生を無期限に待つのを回避するためにタイムアウトを使用しています。タイムアウトはハードウェアの故障を示す場合もあれば、想定どおりの結果である場合もあります。
void Task (void)
{
OS_ERR err;
// Task initialization
while (1) {
err = WaitForEvent(&EventObject, timeout);
if (err == TIMEOUT_OCCURRED) {
Event didn’t happen within timeout;
} else {
Event occurred, process;
}
}
}
誤解1:RTOSティックはスケジューラである
RTOSは、イベントが発生すると常にスケジューラを実行して、より重要なタスクを実行する必要があるかどうかを判定します。ティック割込みは、スケジューラを実行させるイベントであり、RTOSベースのシステムに数多くあるイベントのうちの1つにすぎません。つまり、イーサネットパケットが到達し、それが、タスクが待っていたイベントである場合、RTOSは(イーサネット向けの)ISRが返された直後にそのタスクを実行すべきか否かを判断します。
誤解2:RTOSティックは、RTOSに常に必要である。
実際には、ほとんどのRTOSがクロックティックを必要としますが、アプリケーションにおいてタスクをスリープさせたり、タイムアウトを使用することが全くない場合は、RTOSティックをシステムから除外することも可能です。ただし、この機能が本当に不要であることを確認する必要があります。もし必要であった場合、タスクが予期したとおりの動作をしなくなります。このことを確認できない場合は、RTOSティックは有効にしてください。
誤解3:RTOSティックの割込みは、優先度が最も高い
これは明らかに誤解です。実際、RTOSティックの割込み優先度をシステムで最も低いレベルにする場合や、最低ではなくともアプリケーションのリアルタイム割込みより低く設定する状況はあり得ます。多くの場合、アナログ入力のサンプリング、高速モータの制御、TCP/IPトラフィックへの応答などには、より高い重要度を持たせる必要があるでしょう。RTOSティックは粗い時間遅延やタイムアウトを目的としたものです。
誤解4:RTOSティックレートは正確でなくてはならない
繰り返しになりますが、ティックの全体的な目的は、粗い時間遅延とタイムアウトを提供することです。アプリケーションが極めて正確な周期的割込みを必要とする場合は、別のタイマを使用して、その割込みの優先度を高くする必要があります。
誤解5:クロックティックはRTOS専用でなくてはならない
ハードウェアタイマをRTOSに割り当てている場合、そのタイマを使って時間遅延やタイムアウトを発生させることは当然のことです。しかし、場合によっては、RTOSにその機能を実行させる前に、タイマの割込みを中断して何らかの動作を実行させることが必要な場合があります。たとえば、uC/OS-IIIなどのRTOSでは、RTOSのティックサービスを呼び出す前に、ユーザ定義関数を呼び出すこと(フックやコールバック)が可能です。この場合の疑似コードを以下のスニペットに示します。
RTOS_TickISR(void)
{
Call user defined function; // i.e. a hook (a.k.a. callback)
Call the RTOS tick services;
}
ハードウェアタイマが入手できない場合や極めて正確なタイムソースが必要な場合には、この機能が役立つでしょう。RTOSの前にコードを呼び出すことで、RTOSスケジューラによって生じるタスクのジッタの影響を避けることができます。
誤解6:ハードウェアタイマは常に必要である
もし、ハードウェアタイマが入手できず、使用している組込みシステムがAC電源から給電されている場合は、単に回線周波数を引き出すだけで(ハードウェア技術者の支援が必要)、50Hzまたは60Hz(国によって異なります)を得るか、電源ラインのゼロ交差を検出して2倍の周波数(100Hzまたは120Hz)を得ることができます。少なくとも米国では、長期的な精度は比較的安定かつ正確であることが判明しているため、AC電源による普通の時計でも全く申し分なく計時が可能です。
著者について
本稿は、RTOSを使用したアプリケーション開発をテーマとしたシリーズの一部です。
Jean Labrosse(ジーン・ラブロス)氏は、Micriumの創設者であり、広く普及しているuC/OS-IIおよびuC/OS-IIIカーネルの作成者です。組込みソフトウェアのuC/ラインの発展のために積極的に取り組んでいます。
組込みシステム市場での豊富な経験を有し、市場を知り尽くしているLabrosse氏は、Weston Embedded Solutionsの主席アドバイザおよびコンサルタントとして、現行のRTOS製品の将来的な方向性の策定に尽力しています。Weston Embedded Solutionsは、Micriumのコードベースから生まれた信頼性の高いCesium RTOSファミリー製品のサポートと開発を専門としています。