オリジナルOS「MicrOS」の設計と実装（4） ―― リアルタイム性の確保

● 割り込み処理部における処理時間の見積もり

　次が割り込み処理にかかる時間です．リスト1で説明すると外部割り込み処理の先頭から（A），ei，個別の割り込み処理，diの直前までの処理時間と定義して構わないでしょう．なお，ここでは多重割り込み処理の流れを示しています．

　割り込み処理をこのような形で構成した場合，特にいえることですが，クリティカルな処理を行う場合，割り込み処理の中での処理はできるだけ割り込み処理の中で処理するようにすべきです（それがほかの割り込みを消してしまうくらい長時間を要するものでない限り）．例えば，タイマを10ms周期で入れていたとすれば10msまでの処理を，またUARTを同時に使うことがあってそれが9,600bpsで動作するのであれば，1ms（FIFO-UARTで16バイトのバッファがあれば16ms）までの処理をクリティカルな割り込み処理に割り当てることができます（実際にはその半分程度にすべきだが）．タスク・スイッチはレジスタの入れ替えという実行ステップのかかる処理なので，タスク・スイッチを行わない方がむしろCPUの使用効率は高まるからです．この辺りはアプリケーション・システムの設計の仕方によりますが，このようにした方がクリティカルな処理は安定した動作を行うでしょう．

　ここに書いたことは一般にいわれていることとは反しています．しかし，クリティカルな処理が連続して発生するようなシステムでは，これに対処できなければリアルタイム処理は不可能となる場合があります．

　クリティカルな処理をタスクで処理しなければならないとすると，このあとタスク・スイッチの時間を計算に入れなければなりません．この場合，割り込みが発生したときに実行タスクがあるケースが最大の割り込み禁止区間で，この間にタスクのレディ・プールへの登録処理とディスパッチャへのジャンプ，ディスパッチャでのタスク選択処理と，タスクの実行にかかる処理までが，組み込みOSで示すことができる時間です．このときは割り込みの多重度も計算に入れなければなりません．この多重分だけタスクの処理が遅れる可能性があります．こうした意味からも，クリティカルな処理は割り込み処理の中に押し込んだ方がよいでしょう．

　タスクでクリティカルな処理を実行中にも割り込みは発生します（割り込み禁止で処理するなら，わざわざタスクで処理する必要がない）．タスクの処理時間は外部割り込みによってディスターブされます．これがどの程度あるのかを推定し，外部割り込みの処理時間を加えなければなりません．しかし，クリティカルな処理のタスクはそうした割り込み処理のあとでもタスク・スイッチで切り替えられることはありません．このタスクのプライオリティは最も高いからです．

　以上のことをまとめると表1のようになります．

　マルチプログラミングOSの中にはリアルタイム性を失わせる要因がたくさんあります．ハード・リアルタイム・システムであればあるほど，高級な機能を持ったリアルタイムOSではなく，機能が少なく専用性の強いOSで制御した方が安全で，確実にリアルタイム性を保障できるということがお分かりいただけたと思います．従って，高機能でハード・リアルタイム・システムにも適したリアルタイムOSなどというのは，「矛盾」の説話と相似形であると感じられるかもしれません．ものづくりに関わる技術者としては，こういう誤解を受けないような対応をすべきです（高級な機能は使わなければいいのだが，それはオーバヘッドなので組み込みの考え方に反しているといえる）．