組み込みエンジニアの本能的な欲求から生まれた？ ポーランド発RTOS「DioneOS」：リアルタイムOS列伝（38）（2/2 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第38回は、マルチタスクに焦点を当てたポーランド発の省フットプリントRTOS「DioneOS」を取り上げる。

[大原雄介，MONOist]

「DioneOS」を作った最大の動機は「自身でRTOSを作ってみたかった」

　あと明示されていないのだが、おそらくDioneOSを作った最大の動機は、「自身でRTOSを作ってみたかった」ではないかと思う。組み込みのビジネスを手掛け、組み込みLinuxを中心にシステム構築などを行っている開発者としては、「自身でもRTOSくらいは作れる」ということを示してみたい欲求に駆られるものらしい。

　実際この連載でも、個人で作ったRTOSを幾つもご紹介しているわけで、そのあたりの気持ちは分からなくもない。多分このDioneOSも、ちょうど「ChibiOS/RT」や「scmRTOS」などと同じように「MCUを使ったシステムを作る仕事が舞い込んできて、なのでついでにRTOSから作ってみた」という感じではないのかと思う。

　MSP430とSTM32L162というピンポイントな移植や、その後は新プラットフォームへの移植が全く行われず、にもかかわらず現在も販売されているというあたりは、そうした特定のシステムへの対応が優先されており、ただしあわよくば他にも売れるかも、ということでまだラインアップを残してあるという感じではないかと考えられる。

　一応カーネルそのものはMulti-Threadで、Preemptive構成である。変わったところではステートマシンのサポートがカーネルレベルで用意されているのが目新しい。

　さてそういうRTOSであるから、制限もいろいろある。まず、Thread数は最大でも16個に制限されている。一般的なRTOSだと、これはちょっと足りないと感じられる場合もあるだろう（Cortex-M7ベースのMCUに256KBくらいのSRAMを組み合わせれば、30〜40個のThreadをブン回すのは容易である）が、STM32L162やMSP430がターゲットならこれくらいで十分というか、これ以上増やすと大変だろう。

　メモリ管理については、MSP430／STM32L162にはMPU（メモリ保護ユニット）が搭載されているが、AVR8にMPUがなかったためか管理を行っている気配はない。一応os_mem_pool_alloc()／create()／destroy()／free()という動的なメモリプールを行うための関数は用意されているので、あるいはOS内で決め打ちでMPUの設定を行っている可能性はあるが……。また、Thread間同期はMutexとSemaphoreであり、Thread間通信にはListとRing Bufferが提供されている。小規模なRTOSだからこれで十分だし、あれこれ提供してフットプリントが増えるよりマシ、という判断だろう。

　開発環境としてはMSP430がTIのCode Composer Studio v.4、STM32L162とAVR8はGCC toolchainを利用する格好である。デバッグ環境としてはこれらのツールの他に、OpenOCDやcross-GDB、JTAGなどが利用可能となっている。ちなみに商用OSらしい側面としては、提供に当たって、不良品を徹底的に排除することを意味する“Zero tolerance”を実現しており、400を超えるテストを実施して問題がないことを確認しているという。

　ここまで説明すると「んじゃちょっと試してみようか？」という気になる方もおられるかもしれないが、今のところDioneOSは無償版の提供がない。商用ライセンスのみの提供（これには、自社製品向けの開発と他社製品向けの開発の2つがある）であり、その価格なども同社に問い合わせということで明示されていない。こんな売り方で売れるものなのか？　という疑問もあるのだが、もはやEleSoftRom（というか、Romaniuk氏）にとってDioneOSは積極的に売りたい製品ではないのかもしれない。手持ちのMSP430のボードでちょっと動かしてみたい、という気もするのだが残念である。