ArmマイコンのRTOSとして充実する「Mbed OS」に一抹の不安：リアルタイムOS列伝（5）（1/3 ページ）

　ArmのリアルタイムOS（RTOS）「Mbed OS」は過去に何度か取り上げさせていただいた。最初は2014年のこちらの記事で、次いで2015年のこちらの記事、mbed 3.0の話、連載「IoT観測所」の第13回と第39回、そして2018年の「Mbed Linux OSに」絡んだ話といった具合だ。

　加えて言うなら、2020年7月にArmがISG（IoTサービスグループ）を切り離すという報道があり、Mbed OSはどうなるのか？　と思っていたら、最近になってロイターがこの計画が中止になったと報じている。これが事実ならまぁ一安心ではあるのだが、まだこれはArmの公式なリリースではないので、このあたりははっきりしない。

⇒連載記事「リアルタイムOS列伝」バックナンバー

進化を続けるMbed OS、bare metal profileとは

　それはともかくとして、Mbed OSはその後も進化を続けている。以前にこの記事でも簡単に触れたが、Mbed OSのオリジナルはSensinode Oyが提供していたNanoStack/NanoService/Nano Routerといった軽量サービスに皮を被せたもの（Mbed OS 2.x／Mbed Classic）だった。しかし、これとは別に「Mbed OS 3.0」という、きちんとRTOSを志向したものが別に開発され（こちらはArmの「Keil RTOS」をベースとした）、これら2つがマージされたものが「Mbed OS 5」となってリリースされた。そのMbed OS 5は現時点で5.15.5が最新であるが、これとは別に2020年6月には「Mbed OS 6」がリリースされており、原稿執筆時点での最新版はMbed OS 6.2.1となっている。

　そのMbed OSであるが、Mbed OS 5.12で、新しく「Mbed OS bare metal profile（以下、bare metal profile）」なるものが追加された。これはMbed OSのサブセットというか、APIの互換性をぎりぎり維持しつつ、最小限のサービスを提供するにとどまる（その代わりフットプリントが大幅に削減できる）ものである。このbare metal profile、実はMbed OS 2のリリースを終了することにも絡んだ提供となっている。要するに、Mbed OS 2のメンテナンスはそろそろ打ち切りにしたいという話で、ただしいきなり打ち切るとMbed OS 5の利用がフットプリント的に厳しいMCUだと困ってしまう。そこで、Mbed OS 2の移行先としてbare metal profileが提供された形になる。

　そのbare metal profileは、以下のような特徴がある。

• Mbed OSとAPI Callそのものは互換（ただし対応するものはそう多くない）
• ライブラリとしてはARM micro C libraryおよびGCC newlib-nanoが提供される。どちらもARM C libraryおよびGCC newlibのサブセット
• Thread safe（マルチスレッド環境で、ある関数などが複数のスレッドから同時に実行されても矛盾や不具合が生じないようになっていること）は提供されない

　こう書くよりも、次の図1を見ていただいた方が早いだろう。これは、Mbed OS 6のアーキテクチャの方向性（Conceptual Architecture）である。つまり、ハードウェア依存のドライバを各ベンダーが提供し、その上のCMSIS-CoreやMbed Driver ModelをArmが提供、その上層にOS Core APIを始めとするAPIが位置しており（これも原則はArm提供：ミドルウェアライブラリはオープン実装）、その上層でアプリケーションを自由に構築するという形だ。

図1　ずいぶんリッチな構成に進化したな、という気はする。もちろんRTOSの常として、必要なモジュールだけロードできるから、全部が全部乗るわけではないが（クリックで拡大）

図2　というか、RTOSがそもそも載っていない（クリックで拡大）

　では、bare metal profileは？　というと図2のような仕組みになっている。ハードウェアの上に、Mbed OS互換のAPI Wrapperを被せただけで、事実上何も載っていない。Mbed blogにおけるbare metal profileの説明は“Mbed OS bare metal delivers the rich features and support our customers expect for devices with different memory footprints, through a APIs consistency between releases and RTOS and non-RTOS environments.”という文章で締められているが、要するに“non-RTOS”環境というわけだ。そりゃThread safeもへったくりもないだろう。

　もっとも、APIリストを見てみると、かなり多くのAPIについて互換性が保たれており、既存のアプリケーションをより少ないベアメタル環境に移植したい、なんてケースではかなり有用だろう。もっともそうしたケースがどの程度あるのかよく分からないが。