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

[大原雄介，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に移植が可能ということになる。