ハイパーバイザー( RTS Real-Time Hypervisorなど)を使用して非リアルタイムOSと並行してRTOSを実行することについてのアドバイス/経験は何ですか。パフォーマンスへの影響はありますか?リスクはありますか?(たとえば、非リアルタイムOSがRTOSのリアルタイムの側面に干渉しないようにする方法など)
私の理解では、各OSに独自のコアを割り当てることができるように、デュアルコア(またはハイパースレッディング)CPUを使用する必要があります。
ハイパーバイザー( RTS Real-Time Hypervisorなど)を使用して非リアルタイムOSと並行してRTOSを実行することについてのアドバイス/経験は何ですか。パフォーマンスへの影響はありますか?リスクはありますか?(たとえば、非リアルタイムOSがRTOSのリアルタイムの側面に干渉しないようにする方法など)
私の理解では、各OSに独自のコアを割り当てることができるように、デュアルコア(またはハイパースレッディング)CPUを使用する必要があります。
主なアイデアは、独自の API を使用して、この OS 用に特別に作成されたタスクを実行する 1 つの RTOS を持つことです。これらのタスクは文字列の優先度レベルで設定され、優先度の高いタスクが常に優先度の低いタスクよりも優先されます。最も優先度の低いタスクは、他に実行可能なタスクがない場合にのみ実行されます (つまり、すべてのタスクは、タイムアウトまたは外部信号のいずれかのイベントを待機しています)。
これはすべて通常のマルチタスク OS スケジューラと同じで、複数のコアやハードウェア スレッドは必要ありません。タイミングの保証が根本的に異なるだけで、利用可能な API はこの事実を反映しています。
これらのハイブリッド実装では、完全な非 RT OS カーネル、通常は Linux またはその他の UNIX のようなカーネルを実行する単一の最低レベルのタスクがあります (Windows については知りませんが、同じように動作するはずです)。現在、このアーキテクチャをハイパーバイザーと呼んでいます。
そのため、RT 以外の OS 全体が優先順位の最も低いタスクとして実行されるため、処理時間が得られるという保証はまったくありません。どの RT タスクも、ハードウェアにアクセスしているときでも、いつでも中断できます。これを維持するために、通常、RT タスクはハードウェアへのアクセスを非常に制限するか、非常に低いレベルで最小限の調停を行います。つまり、ディスク アクセスを中断する可能性があります (アクセス エラーが発生する可能性があります)。ただし、PCI アクセスではありません (存続期間が短く時間制限がある限り)
しばらくの間、Linux スケジューラーへのソフト RT 拡張もいくつかあります。ただし、タイミングの保証は、それを念頭に置いて構築された一部のハード RT OS ほど厳密ではありません。