組込み MCU で使用される RTOS は無限にあるように見えますが、そのほとんどは独自の機能と独自の API を備えています。API の中には優れたものもありますが、それほど優れていないものもあります。実際には、良い RTOS API とあまり良くない RTOS API の差は非常に小さく、ほとんどの RTOS API で十分に機能します。過去 30 年以上を振り返ってみると、適切な RTOS API が組込み開発と業界全体に重大な悪影響を及ぼし、現在も与え続けていることに気づきました。
何よりもまず、独自の RTOS API はアプリケーション ファームウェアのロックイン（閉じこもること）を意味します。独自の RTOS API を使用して記述されたコードは、別の RTOS に移行する際には変更する必要があります。さらに悪いことに、別の RTOS に移行するために必要な変更は気が遠くなる可能性があります。一部の RTOS ベンダーは、他の API をサポートするためにアダプテーションレイヤーを追加しています。ただし、この解決策は、丸い穴に四角いペグをはめ込もうとすることが多いため、理想的とは言えません。言うまでもなく、レイヤーを追加するとオーバーヘッドが大幅に増加し、RTOS が複雑になり、結果的にエラーが発生する可能性があります。
いずれにしても、アプリケーションコードを簡単に移行できないと、製品の進化が大幅に制限される可能性があります。たとえばアプリケーションが、とあるRTOS XYZに依存しており、最新かつ最高のプロセッサをサポートしていない場合、アプリケーションはコード ベースを変更して別の RTOS に移行するか、RTOS XYX がサポートを追加するまで待つか、単に諦める必要があります。同様に、RTOS XYZ ベースのアプリケーションを組込み Linux に移行すること (これも非常に一般的な状況) は、組込み Linux のマルチスレッドが POSIX pthreads API に基づいているため、困難です。標準の RTOS API はロックインを排除するのに役立ち、それによって組込みアプリケーションの移植性が高まり、将来の進化が促進されます。
また独自の RTOS API を使用するには、広範なトレーニングが必要です。RTOS を初めて使用するほとんどの開発者は、独自の RTOS API の学習にかなりのサイクルを費やす必要があります。FreeRTOS や Microsoft の Azure RTOS ThreadX (どちらも人気のある組み込み RTOS であり、それぞれ独自の API を備えています) を使用している組込み開発者でさえ、開発者の総数から見れば、かなり少ない割合にすぎません。ここで重要なのは、独自の RTOS API には学習が必要であり、企業にとっては時間とコストがかかるということです。業界標準の RTOS API を使用すると、トレーニングが削減され、その結果、コストが節約され、メーカーの市場投入までの時間が短縮されます。
もう 1 つの問題は、一部のデバイス メーカーが MCU と MPU の両方にまたがる製品ファミリを持っており、通常は機能や価格が異なっていることにあります。このようなデバイスメーカーの MPU ベースの製品は、組込み Linux の何らかのフレーバーを頻繁に使用します。これらの企業にとって、独自の RTOS API のために個別の開発チーム (およびコードベース) を維持する必要があるのは困難でありコストもかかります。標準の RTOS API を使用すると、アプリケーションコードを MPU ベースのプロジェクトと MCU ベースのプロジェクト間で即座に共有できるため、コーディングやテストから製品リリースに至る開発プロセス全体が改善されます。
標準の RTOS API はどうあるべきか?
話を進める前に、Arm の功績を讃えておく必要があります。Arm はこの問題を何年も前に組込み業界で特定し、CMSIS-RTOS API を使用してこの問題に対処しようとさえしたからです。残念ながら、CMSIS RTOS API は、結局のところ、別の独自の RTOS API です。
標準の RTOS API がどうあるべきかに戻りましょう。面白いことに、その答えは何年も前から私たちの目の前にありました。標準の RTOS API は、業界標準の POSIX pthread API と同じであるべきです。これは、すでにすべての組込み Linux ディストリビューションとすべての大学のコンピューターサイエンスカリキュラムの一部になっています。組込み Linux は組込みデザインの 70% を占めているため、POSIX pthread API はすでに組込み分野の RTOS API 標準であり、ほとんどの開発者がすでによく知っているものであると主張するのは簡単です。
さらに、POSIX pthread API は 30 年以上にわたって UNIX/Linux システム上でテストされてきました。ハードリアルタイム機能とこの業界標準 API を組み合わせることで、組込み開発者は両方の長所を利用できるようになります。私たちの業界では、さまざまな RTOS プロバイダーがそれをネイティブに採用する必要があります。POSIX pthread API 標準に基づいて組込み業界を統合することで、ロックインが排除され、組込み製品の進化が加速され、トレーニングが削減され、MCU クラスと MPU クラスのデバイス間のコード共有と移行が即座に可能になります。これらすべてが、組込み業界において重要な前進を意味します。