μITRON／POSIX互換のRTOS「eCos」はカーネルもオプション!?：リアルタイムOS列伝（28）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第28回は、μITRON／POSIX互換のRTOS「eCos」を紹介する。

[大原雄介，MONOist]

ちゃんとしたカーネルがあるのにオプション扱い

　この後2009年にはeCos 3.0およびeCosPro 3.0が、2011年にはeCos 3.1がリリースされる。実はこのeCos 3.1が公式には最新版である。後述する「eCosPro」の方は、バージョンは3.1のままながらSMP対応とかCAN-FD、Octal SPI、lwIPやMbed TLSなどの対応が追加されるなどきちんとメンテナンスはなされているし、eCosCentricのサイトそのものもきちんと更新されているが、eCos 3.2あるいはeCos 4.0といった新バージョンの話は今のところオフィシャルには一切出てはいない。

　さて、そのeCosであるが、基本的な構造は図3のようになっている。ちょっと面白いのは、カーネルすらもオプション扱いになっていることだ。eCosのカーネルはPreemptive、Multi-Thread対応でPriorityベースのSchedulerが動作する割とちゃんとした構成だが、Single-Threadedなアプリケーションの場合はそもそもSchedulerやPreemtiveなカーネルなどは不要である。

図3　「eCos」の構成いささかラフすぎる図ではあるが、概略は理解できるかと思う

　そこで、こうしたアプリケーションの場合はカーネルを利用せず、限りなくベアメタルな構成で利用することも可能である。もっともeCosの場合、ベアメタルというよりはPOSIX互換やμITRON互換レイヤーを利用するケースが多いし、ネットワークスタックを利用すると当然Multi-Thread環境が必要になるので、カーネルを組み込まない利用形態はあまり一般的ではないとは思うが、それでもこれをオプション扱いにするRTOSはあまり見掛けない。

　Schedulerはbitmap schedulerとMLQ（Multi-Level Queue）の2種類からどちらかを選択できる。SchedulerのPriorityそのものはデフォルトで32（変更可能）で、bitmap schedulerは1Priority当たり1threadという構成、MLQでは1つのPriorityに複数のThreadを登録可能で、この同一Priorityの複数Thread間はtimeslicingによるschedulingとなる。

　Thread間同期のメカニズムとしてはmutex、条件変数、カウンタ付きセマフォ、Mail boxとEvent flagとなっており、よく利用されるものは大体提供される格好だ。また、割り込みハンドリングとしてはISR（Interrupt Service Routine）に加えてDSR（Deferred Service Routine）も利用可能になっている。通常のRTOSの場合、DSRに相当するものはユーザープログラム側でハンドリングするのが常だと思うが、DSRというエントリが用意されているのはちょっと珍しい。

　カーネルの上には、先にも触れたがPOSIX互換のAPIとμITRON 3.0互換のAPIが提供されている。このμITRON互換のAPIの提供が、日本でeCosが利用されることになった最大の理由と思われる。他にISO CとMath library、C++ Standard Template Library（μSTL）、Serial／Ethernet／SPI／I2C／Framebuffer／CAN／ADC／Wallclock & Watchdog timerといったデバイスドライバ、USB Slave、TCP/IP Stack、GDB debug supportなどが提供される。ただし、デバイスドライバは当然ながらターゲットデバイスに依存するので、これらが常に全て提供される訳ではない。