ベアメタルからOSへ：私が組み込み開発の焦点を移した理由

「ベアメタル時代」を振り返る

組み込みソフトウェアとの最初の出会いは2008年、大学2年生のときに8051チップでプログラミングを学んだことでした。コンピュータサイエンス専攻で、ほとんどのコードはPC上で動いていましたが、プログラムがベアメタルボード上で直接実行されるのを見たときの衝撃は忘れられません。最初のサイクリングランプファームウェアが完璧に動作した瞬間を今でも覚えています。しかし、ベアメタルプロジェクトを重ねるにつれ、課題が浮上してきました。

ベアメタル開発の主な課題

並行処理

ベアメタルファームウェアでは、単一のwhile (1)ループにほぼすべてのトランザクションロジックが含まれます。あるルーチンが遅延関数を呼び出すと、CPUはその遅延中ロックされ、他のすべてのタスクが待たされます。この逐次実行はCPUサイクルを浪費し、並行性を著しく制限します。

モジュール性

すべての関数が単一のモノリシックなループに存在する場合、高凝集・低結合の実現は困難です。依存関係が密接になり、大規模プロジェクトへのリファクタリングや拡張が難しいコードになります。例えば：

• 関数が無限ループにまとめられ、明確なモジュール境界が不可能
• ウォッチドッグタイマー近くで遅延関数を使用するには慎重なタイミングが必要。計算ミスはウォッチドッグリセットを引き起こし、さらなる複雑さを追加

エコシステムの制約

多くの高度なソフトウェアコンポーネントは、より低レベルのOSに依存しています。例：

• FreeModbusを中心としたオープンソースプロジェクトを構築し、ベアメタルボードを含む様々なプラットフォームへの移植を目指しました。しかし、各ボードで必要な関数をスクラッチから実装するのは複雑すぎました。現在、私のModbusスタックはベアメタルシステムでは動作しません
• Realtek、TI、MediaTekなど主要ベンダーのSDKはOS上でのみ動作し、ファームウェアソースコードを公開していないため、純粋なベアメタル環境では使用不可

リアルタイム要件

産業制御システムは精密なタイミングを要求します。メカニカルアクチュエータは厳密なシーケンスに従わなければなりません。すべてのロジックが単一ループに押し込められている場合、リアルタイム動作の保証はほぼ不可能で、システム障害と安全上の危険を招きます。

再利用性

機能が特定ハードウェアに強く結合されているため、新しいプラットフォームごとに同じコードを書き直す必要があります。これは重複した労力を生み、製品開発を遅らせます。

OSを採用するメリット

2010年までにSTM32 MCUが普及し、私はRT-Threadを試し始めました。過去10年間、RT-Threadを広く使用し、組み込み開発がいかに変わるかを実感しています。

モジュール性

RTOSはファームウェアを独立したスレッドに分割し、それぞれが独自の実行コンテキストを持ちます。この分離が自然にモジュール性を高め、保守を簡素化します。

並行処理

スレッドがsleep()を呼び出すかイールドすると、スケジューラが自動的に他の準備完了スレッドに制御を移します。これによりCPU利用率とシステム全体の並行性が向上します。

リアルタイム保証

RTOSは決定論的スケジューリングを提供します。タスクには優先度があり、カーネルは高優先度タスクが低優先度タスクをプリエンプトすることを保証します。この組み込みのリアルタイム動作は、安全クリティカルなアプリケーションに不可欠です。

開発効率

OSはセマフォ、イベントフラグ、メールボックス、リングバッファ、リンクリストなど統一APIを提供し、開発者がアプリケーションロジックに集中できるようにします。

ソフトウェアエコシステム

LinuxとRT-Threadの両方がデバイスドライバーフレームワークを実装し、ハードウェア詳細を抽象化しています。エンジニアはドライバーを一度書けば多くのボードに展開可能で、プラットフォーム固有コードを大幅に削減できます。このエコシステムは共有も促進します。私は定期的にオープンソースコンポーネントをGitHubで公開し、世界中の仲間が貢献してくれます。活気ある協調コミュニティが形成されています。

結論

ベアメタルからRTOSへの移行は、モジュール性、並行性、リアルタイムセーフティを備えたコード作成能力を拡張しました。また、再利用可能なコンポーネントが繁栄し、開発者がハードウェアの境界を越えて協調できる、より豊かなエコシステムへの扉を開きました。