小さな組み込みシステム プロジェクトで、スレッドで実行したいコードがあるため、組み込み RTOS (eCos) の上に構築することを選択しています。
以前は、それぞれがステート マシンとして実装されたタスクを駆動する main() で巡回エグゼクティブを使用していました。一部のタスクでは、タスクを多くの細かい状態に分割する必要があるため、コードが非常に複雑になるという問題が発生しました。
RTOS に切り替えると、各タスクに独自のスレッドを割り当てると、各スレッドのスタックのメモリ使用量が急速に増加することがわかりました。(64k しかなく、通信バッファー用のメモリーが必要です)
通信タスクにトレッドを使用し、循環エグゼクティブに別のスレッドを使用することを検討しています。巡回エグゼクティブは、他の論理タスクを駆動します。
このように RTOS と周期的なエグゼクティブを混在させることは理にかなっていますか?
これは完全に有効な設計です。
私たちの製品の 1 つで、非同期 I/O チャネル (TCP/IP、2 つのシリアル ストリーム) が独自のタスクにあり、機能の複数の領域を担当する「メイン」タスクがあった、同様の設計を使用しました。 .
タスクは、設計を簡素化できる単なるパーティション メカニズムと考えてください。
はい、複数の「タスク」を実行する 1 つの OS スレッドで循環エグゼクティブを使用することは理にかなっています。実際、2 つのタスクがスケジューリングのニーズと競合しない限り (一方をブロックする必要がある、一方が他方よりも優先度が高く、優先度の低いタスクの実行に時間がかかるなど)、それらを同じスレッドに配置することをお勧めします。
これは、メモリ保護のない軽量の RTOS を使用している場合に特に当てはまります。個別のスレッドは、1 つのスレッドよりも安全ではありません (アドレス空間の MMU 保護なし)。同時実行保護の必要性が高まります。IPC スキームが堅牢で、プログラマによる誤用の影響を受けにくい場合でも、そのオーバーヘッドは通常ゼロではないため、その必要性を回避することでパフォーマンスが向上する可能性があります。
FreeRTOSを見ると、実際にはタスクで別のスケジューラを実行しています:)
そして他の人に反響するように、デザインには何も問題はありません。何かをそのように表現する明確な方法があれば、タスク (の一部) をステート マシンにできない理由はありません。
有効な設計ですが、OS を搭載する理由をまったく見落としていたと思います。
OSのどのような機能を使用する予定ですか?
入手可能な情報によると、タスクの複雑さを新しいメイン ループに移動することになるようです。