大学生まれのフル機能RTOS「RIOT-OS」は良くも悪くもビジネスと直結しない：リアルタイムOS列伝（17）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第17回は、欧州の大学の共同研究に出自を持つフル機能のRTOS「RIOT-OS」を紹介する。

[大原雄介，MONOist]

Linuxプログラマーがスムーズに開発できる点で「Apache Mynewt」に近い

　さて、WSN向けからスタートしたこともあり、RIOT-OSは基本エンドノードというか、IoTのフレームワークでよく用いられるConstrained Device（制約されたデバイス）あたりが主なターゲットとなっている（図5）。結果として、当然図6のような条件の下で動作することになる。

図5　このターゲットは「Contiki」とすごく近いのだが、実装がまるで違うのも面白い［クリックで拡大］

図6　最近だとMCU向けのGUIのニーズがぼちぼち増え始めているのだが、まぁ全部が全部というわけではないし、WSN向けならばUIはせいぜいが液晶ディスプレイ程度で十分だから、ほぼこの条件は今でも当てはまる［クリックで拡大］

　そのRIOT-OSの基本的な方針が図7である。上でもちょっと書いたが、Linuxのプログラマーが比較的スムーズに開発ができるような工夫がなされているというあたりでは、Apache Mynewtに近いものがある。特に開発の初期段階は、Linuxの上でそのままRun＆Debugができる（もちろん最終段階では、性能の確認などのために実機を動かす必要があるが）のはちょっと特異である。

図7　開発にはgdbやValgrindが使えるし、プロトコルチェックなどにはWiresharkが利用できるというのもメリットとして挙げられている［クリックで拡大］

　図8に挙げたのはOSの特徴になる。先のFireKernelの数字に比べるとややメモリの利用量は増えているが、フル機能のRTOSになっていること、32ビットMCUということを考えれば、これは許容範囲化と思う。それにしても、図8で見るとかなり機能が豊富であるものの、これを担保するためのシステム構造もかなり充実というか、RTOSとしてはかなり重厚な構造になっている（図9）。

図8　ちなみにターゲットは8ビットや16ビットも当然カバーしている［クリックで拡大］

図9　さすがにHALを入れるところまではしなかったもよう［クリックで拡大］

　センサーノード向けということで当然コネクティビティも必要であり、これも当然用意されている（図10、11）。ネットワークスタックも当然、それも複数用意されており、用途に応じて選択することができる。ちなみにGitHubでsys/netの下を見てみると、専用のkconfigを用意することで、LPWA（省電力広域）ネットワークの一つであるLoRaへの対応も進んでいるようだ。

図10　CANはともかくNFCというのはちょっと不思議な選択のような気もする［クリックで拡大］

図11　lwipは「Contiki」でも出てきた［クリックで拡大］

　プラットフォームとしては、先にも書いたが、Armやx86/MIPSといった32ビット以外に、MSP430やAVR8もサポートされている（図12）。現時点でRIOT-OSの動く開発ボードの数は実に236個。あまり古いもの（それこそH8やZ80など）はサポートの対象に入っていないが、逆に現在入手可能な開発ボードはかなり網羅されている印象だ。

図12　LLVMに対応というのもRTOSでは珍しい気が［クリックで拡大］

　ちなみに「Arduino Uno」もサポートリストに入っているが、これはATmega328pベースなので、そもそもSRAMが2KBしか搭載されておらず、それもあって説明にも“Don't expect having a working network stack due to very limited resources.”と書いてあるのはまぁご愛嬌（あいきょう）か。多分、OSカーネルとネットワークスタックを載せたらアプリケーション用のメモリが余らないだろう。そういう意味で現実的か？　と言われれば怪しいのだが、逆に動くだけならかなり多くのMCUに移植が可能ということになる。