「ThreadX／Azure RTOS」の悔恨から生まれた「PX5 RTOS」はできたてほやほや：リアルタイムOS列伝（32）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第32回は、2023年1月にリリースされたばかりのRTOS「PX5 RTOS」を紹介する。

[大原雄介，MONOist]

pthread APIをネイティブでサポートするMCU向けRTOS

　実際に、PX5 RTOSのブローシャを見ると、以下のような形で手掛けるに至った動機が記されている。

• 既存のLinux／Embedded Linuxでは広範にpthread APIが利用されており、開発者はもうpthread APIに慣れている。だからこそ、pthread APIをサポートするとコードの再利用が期待できる（図3）

図3　これはこれで正しくはあるのだが、その一方で最近AndroidベースのEmbeddedアプリケーションも増えており、Android NDKとpthreadを併用するのが結構大変という話もあって、次の課題はこの辺にあるかもしれない［クリックで拡大］

• Embedded LinuxはLinuxをベースにしているので、ハードリアルタイムには向いていないし、MCU上での動作も難しい（図4）

図4　法的な話とかは取って付けた感もあるが、基本MCUに向いてないのは間違いない［クリックで拡大］

• その一方でRTOSはpthread APIへの対応がないか、もしくは互換レイヤーでのサポートになり、フットプリントの増加や性能低下の要因になる（図5）

図5　後半の話は、ThreadXに対してのLamie氏の後悔の念、と読めなくもない［クリックで拡大］

　その結果、PX5 RTOSはpthread APIをネイティブでサポートするMCU向けRTOSという、なかなかとがった構成となった（図6）

図6　pthread APIの提供そのものはそんなに難しいわけではない。本当に難しいのは、それを現実的なRTOSとして提供することで、10KB程度のフラッシュと1KBのSRAMでこれを実現するのは相当難しかっただろう［クリックで拡大］

　普通ここまでの割り切った判断は出来ないものである。思うにLamie氏は、ThreadXやAzure RTOSの使われ方を見て、予想以上にpthread APIを使うアプリケーションが多いことを実感し、だからといってThreadXやAzure RTOSをpthread APIベースに書き直すのはあまりにチャレンジングというか、今度はThreadXのネイティブAPIをpthread APIの上で互換レイヤーで提供するようなことになってしまうから、さすがに踏み切れなかったのではないだろうか。

　逆に言えば、Microsoftから離脱したことで、ThreadXとの互換性を考えずに全く新しいRTOSを開発できる環境になったからこそこれに踏み切った、という見方もできる（あるいはAzure RTOSが一段落したので、かねて思い描いていたネイティブでpthread APIに対応するRTOSを作るためにMicrosoftから離脱したというべきか）。

　さてそんなPX5 RTOSの内部構造は図7のようになっている。

図7　カーネルに当たるのはPX5 RTOS C Implementationになり、Binding LayerはHALに相当する［クリックで拡大］

　PX5 RTOSのAPIは全てpx5.cで提供され、ここは通常のANSI Cで記述されている。一方で各MCU独自の部分は全てpx5_binding.sで提供される。.s、つまりオブジェクトで提供というのがミソで、そもそもここはCだけでなくアセンブラで記述される場合もあるそうだ（コードの99％はCで記述されているそうだが）。

　このpx5_binding.sの詳細はPX5_RTOS_Binding_User_Guide.pdfというドキュメントで説明されているらしいのだが、今のところ一般には公開されていない（恐らくライセンスを取得すると入手できるような気がする）。