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

[大原雄介，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というドキュメントで説明されているらしいのだが、今のところ一般には公開されていない（恐らくライセンスを取得すると入手できるような気がする）。