ハードリアルタイム機能を備えた愛好家向けのポータブルロボットライブラリ (Windows および Linux) を作成しようとしています。標準イーサネットを介してマイクロコントローラーに接続し、そのデバイスにファームウェアをアップロードし、フィールドバスを介して他のデバイスに接続し、専用コントローラーを実行する他のマイクロコントローラーにファームウェアをアップロードできる必要があります。ハード リアルタイムが必要な場合、NIC は RTnet でサポートされているものになります。少なくとも 1 kHz、できれば 2 kHz 以上の典型的なサーボ レートが必要です。完全にカスタムのプロトコル (TCP や UDP over IP ではない) を実行するため、オーバーヘッドが最小限に抑えられ、高速フィールドバスはフレームを送受信していない間に飽和する可能性があります。その後、イーサネット フレームのペイロードを解釈したり、接続されたデバイスに送信したりできます。
1) プロトコルを C++ のままにしたいのですが、「new」キーワードを使用するとリアルタイム プログラミングがうまくいかないことを知っています。プロジェクトを C に変換するのではなく、C++ 言語を使用することを選択した場合、他にどのような制限がありますか? C++ の利用方法や厳しいリアルタイムの締め切りに対応する方法を教えている本や Web サイトを勧める人はいますか? Orocos プロジェクトはリアルタイム C++ を使用しているため、C++ を使用することは可能だと思います。C コードは使用しない方がよいでしょう。
2) 移植可能なプロトコル ライブラリの汎用性を維持するために、プログラムは非リアルタイム イーサネット アダプタと RTnet イーサネット アダプタの両方で同時に実行されるプロトコルをどのように処理する必要がありますか?
私が持っている特定の質問は、ブーストまたは Xenomai ミューテックスのいずれかを使用できるポータブル Mutex クラスについての質問です。
問題 2 の解決策 1 は次のようになります。アプリケーションが Xenomai ライブラリを使用してコンパイルされている場合、ブール値フラグを使用してミューテックスを構築し、実行時にロックとロック解除のためにどのメソッド (boost または Xenomai) がラップされるかを示すことができます。 . ライブラリが Xenomai 用にコンパイルされている場合、ブースト ミューテックスと Xenomai ミューテックスを含めることができます。プロジェクトが Xenomai 用にコンパイルされている場合、ブーストと Xenomai のミューテックスのプライベート変数が含まれるため、このソリューションは好きではありません。
問題 2 の解決策 2 は次のようになります。純粋仮想インターフェイス メソッドの抽象クラスから 2 つの異なる派生クラスをミューテックスに書き込みます。1 つはブースト用、もう 1 つは Xenomai 用です。私はこの方法の方が好きですが、実行時に使用するクラスを指定するのは面倒です。ブーストと Xenomai ミューテックスのプールが必要になるかもしれません。これは、最も困難なリアルタイム C++ プログラムがこの問題に対処する方法ですか?
ミューテックス以外にもこの問題が発生していますが、最初から悪い設計パターンを複製したくないので、フィードバックを受け取りたいです。
3) 私は Beckoff の TwinCAT が Windows 7 で EtherCAT をリアルタイムで実行すると信じています。後で？オープン ソースのハイパーバイザー プロジェクトがあるかもしれません。
4) また、クアッドコア コンピューターが各コアを 100% 使用して、システムがハード リアルタイムで実行されていないかどうかを確認できるように、どのようにシステムをロードしますか?