タスクを一つ作ると，RTOSはTCB（Task Control Block）という内部データ構造を一つ生成する．TCBには，タスクIDや優先度などの情報が書き込まれる（図7）．リアルタイム処理に関する書籍を読むと，TCBの中にそのタスクのデッドラインとか使用したCPU時間などが含まれているように書かれてあるが，市販のRTOSのTCBにはほとんど見られない．OSと呼ばずにRTOSと呼んでいるが，本当は組み込みOSと呼ぶほうが妥当かもしれない．

〔図7〕TCBの例

　TCBにどのような情報をもっているかによって，どんなサービスを受けられるのか見当がつく．情報が多いほど高機能になるが，RAMを使用する．タスクを一つ作ると，どの程度のRAMを使用するか，どのような情報がTCBに含まれているのか，に関してカーネルのヘッダファイルが公開されていれば自分で判断できるが，そうでない場合はメーカーに問い合わせる必要がある．

　海外のあるスレッド型RTOSでは，TCBの中にいくつかリザーブ領域があった．日本の組み込み製品は，民生品が多くメモリ制約が厳しいので，国産RTOS（つまりITRON）では考えられないことだ．

　日本のユーザー（つまりエンジニア）はリソースについてシビアである．一方で，メモリサイズとか応答時間など，単純に比較できるデータ以外では，RTOSを評価できないユーザーが意外に多いような気もする．メモリサイズはともかく，最短応答時間などのあまり意味のないものに固執するのも問題である．チャンピオンデータをカタログに出しているメーカーも昔は多かったが，最近はなくなったようだ．

　また，昨年，米国の組み込みエンジニアと話したとき，米国ではRTOSを使う場合は開発言語にC++を選択する，RTOSを使わない場合はC言語を使う，これは常識であると言っていた．日本ではVxWorksをC言語で使う事例が多いと言ったら，なぜだと問うので，「C++を知らない人が多い」……と答えたらジョークだと思われかねないので，メモリ制約があると言った．そうしたら，なぜVxWorksを使うのかと聞き返された．

　なるほどミスマッチなケースもあるかもしれないと，そのときに思った．RTOSを使うのは一つの手段にすぎないのに，いつのまにか目的化してしまうと，メモリ消費量もオーバヘッドも増えて当然なのに，その事実を受け入れられなくなるのかもしれない．

　RTOSを使うのは，開発期間の短縮，保守性の向上，マルチタスク環境の実現が目的だろう．これらよりもメモリ制約やパフォーマンスを優先するのであれば，RTOSを使わないことも検討するべきである．ミドルウェアを目的としてRTOSを導入する場合もあるが，RTOSなしの環境でも使えるミドルウェアという選択も，TCP/IP程度であれば可能である．

　ARMプロセッサには，FIQという高速割り込みモードがある．FIQでは独立したレジスタをもっているので，コンテキストスイッチが速くなる．また，割り込みベクタがベクタテーブルの一番後にあるので，余計なジャンプ命令を使わずに割り込みルーチンにコントロールを移すことができる．

　そこで，このような話を聞くとFIQをサポートするRTOSを探したくなるのが人情というものだが，RTOSが関与したとたんにFIQのメリットはほとんどなくなってしまう．数百ns程度の時間は，RTOSのオーバヘッドのから見れば誤差の範囲である．つまり，RTOSの中から使ったのでは，数十μsの中の数百nsと言うことになってしまう．

　FIQのメリットを活かすには，カーネルよりもプライオリティの高い世界（カーネルの外）で使う必要がある．あるRTOS開発者は，営業からFIQサポートをせがまれるが，サポートするつもりはないと言っていた．カーネルよりも高プライオリティの割り込みをサポートしているので必要ないのである．CPUのすべてを牛耳ってしまうRTOSでは，このへんの自由度が少なくなる．

　携帯電話やPHSは，空を飛び交うパケットを捉まえなければならない．このような処理は時間的制約が厳しいので，FIFO処理も含めてハードウェア化するシステムLSIの利用が進んでいる．こうなるとRTOSの立場は微妙で，組み込み制御システムの中心的な存在ではなくなってきている．この立場をRTOSメーカーがどのように受け入れるのか，今後が面白い．

Copyright 2001 藤倉俊幸