問題タブ [vxworks]

すべてのタスクに単一の共通アドレス空間を与える方法。このように発生した場合、仮想メモリから物理メモリへのマッピングを回避できます。

すべてのタスクが共通のアドレス空間を共有している場合、仮想メモリから物理メモリへのマッピングを回避するにはどうすればよいですか。

RTOSで一般的に使用されるデザインパターンについて誰かが私を助けてくれますか？
VXworksでは、どちらのパターンがより好ましいですか？

コンパイル中に -fno-omit-frame-pointer オプションを追加すると、アプリケーションがランダムにクラッシュします。

この問題は、VxWorks の ARARCH5gnu アーキテクチャで発生します。

これを解決する方向への指針は役に立ちます。

recvfrom（）呼び出しを待機しているスレッドがブロック解除されてエラーで戻るようにする「良い」方法はありますか？

この動機は、UDPデータグラムを読み取るユニットを含むシステムのユニットテストを作成することです。ブランチの1つは、recvfrom呼び出し自体のエラーを処理します。コードは、さまざまなタイプのエラーを区別する必要はなく、フラグを設定するだけです。

別のスレッドからソケットを閉じるか、ソケットをシャットダウンして、recvfromがエラーで返されるようにすることを考えましたが、これは少し手間がかかるようです。特大のパケットを送信することでそれが可能であるという言及を他の場所で見たので、16Kバッファが4Kだけを待っているrecvfromに送信される実験を設定しましたが、エラーにはなりませんでした。recvfromは4096を返すだけで、そのバイト数を取得したことを示します。

VxWorks 5.5.1 では、execute コマンドを使用してスクリプトを実行できました。VxWorks 6.7 では、execute コマンドはサポートされなくなりました。代わりがいるなら今誰かいますか？コマンドラインではなくコード内から具体的に話しています。

タスクを切り替えることができるようにスケジューラーがどのように呼び出されるか知りたい。プリエンプティブスケジューリングやラウンドロビンスケジューリングの場合と同様に、スケジューラーはあらゆる種類のタスク切り替えを行うために状況を把握する必要があります。優先度の低いタスクに無限ループがあると仮定すると、スケジューラーが介入して優先度の高いタスクに切り替えるのはいつですか？

クエリは次のとおりです。1。誰がスケジューラを呼び出しますか？[VxWorksの場合]2。定期的に呼び出される場合、そのメカニズムはどのように実装されますか？

前もって感謝します。

-アシュウィン

サーバー:
vxworks 6.3
は通常のソケット、バインド、リッスンを呼び出し、次に:

client:サーバーに接続するための
.NET 2.0
TcpClient コンストラクター。次のように、文字列ホスト名と int ポートを使用します。

これは、サーバーが Windows (ネイティブ C++) でコンパイルおよび実行されている場合に正常に機能します。

断続的に、TcpClient のコンストラクターは例外をスローせずにインスタンスを返しますが、vxWorks の受け入れ呼び出しはクライアント fd を返しません。tcpstatShow は、受け入れが発生しなかったことを示します。

TcpClient コンストラクター (「Connect」を呼び出す) がインスタンスを返す可能性があるのに、サーバーでの accept 呼び出しが返されないのはなぜでしょうか? これは、システムがバックグラウンドで実行していることに関連しているようです。クライアントが接続を試みたときに、サーバーがフラッシュまたは NFS 共有にデータを永続化するためにビジーである場合に、この症状が発生する可能性が高くなります。もありません。

私は受け入れを実行しているスレッドの優先度を調整しようとし
ました。「リッスン」でキューのサイズを調べました。十分です。
利用可能なファイル記述子の総数は十分なはずです（ただし、これはまだ検証されていません。朝一番に）

私は、pciAutoConfig（）を使用してPCIバスを構成するVxWorksのボードサポートパッケージ（BSP）を使用しています。イーサネットコントローラカードをバスに追加すると、pci表示ルーチンにカードが表示されません。

バスアナライザを使用して、イーサネットアダプタが実際にはPCI-to-PCIブリッジで構成されており、ブリッジの背後に2つのイーサネットコントローラがあることを発見しました。BSPは、イーサネットコントローラに含まれているPCI-to-PCIブリッジを適切に処理していないようです。

私の質問は、PCI-to-PCIブリッジを構成するために、どのライブラリと構成を確認する必要があるかということです。これらの呼び出しは、既存のpciAutoConfig（）呼び出しがあるsysHwInit（）で行われると思います。

pciAutoCfgCtl（）には、バスを構成するためのユーザー定義関数を指すPCI_BRIDGE_PRE_CONFIG_FUNC_SETパラメーターがあります。これが唯一の方法ですか？または、VxWorksライブラリにこれを実行できるものがありますか？

奇妙な問題が発生しています。ある程度追跡できましたが、まだ原因がわかりません。たぶん、誰かがここに光を当てることができますか？

PPCgnu604 ツールチェーンを使用して C++ で開発している VxWorks 5.5 上で PowerPC プロセッサを実行しています。

私は次のようなクラスを持っています:

アプリケーションが開始されると、MyClass のインスタンスが動的に割り当てられ、「実行」関数を指すスレッドが生成されます。基本的に、コマンドをポーリングするだけで、受信時にステータスが返されます。

これはクラスの切り詰められたバージョンであることに注意してください。簡潔にするために、他の多くのメソッドと変数が省略されています。

コマンド メッセージとステータス メッセージの両方がプライベート クラス メンバーとして定義されている場合、動的なメモリ割り当てがないにもかかわらず、メモリ内の使用可能なバイト数が変化するという問題が発生します。これは、決定論的でレートセーフな手順である必要があるもので発生しているため、重要です。

メッセージ宣言の 1 つまたは両方を run 関数に移動すると、追加の割り当てなしで正常に動作します!

C++ の宣言とメモリ割り当てを理解する上で、何か基本的なことが欠けているに違いありません。私の理解では、動的にインスタンス化するクラス インスタンスは、作成時にヒープ (すべてのメンバー変数を含む) に完全に割り当てられます。ここでわかる違いは、メッセージ宣言を実行関数に移動すると、代わりにそれらがスタックに置かれることです。この場合のヒープは、クラス全体のサイズに対応するのに十分な大きさです。特定の部分が使用されるまで十分なメモリが割り当てられていないように見えるのはなぜですか?

メッセージ クラスは、独自の動的割り当てを行いません。(もしそうなら、宣言を移動してもこの場合の動作は変わらず、ヒープのサイズはまだ変化していると思います。)

メモリ割り当てを監視するために、次の VxWorks memLib (または memPartLib) 呼び出しを使用しています。

編集：

明確にするために、MyClass オブジェクトは初期化ルーチンでインスタンス化および初期化され、その後、コードはレート セーフ処理に入ります。この間、シリアル ラインを介してコマンド メッセージを受信すると (コマンドまたはステータス メッセージ オブジェクトとの最初のやり取り)、追加のメモリが割り当てられます (むしろ、空きバイト数が減少します)。動的メモリ割り当ては決定論的ではないため、これは悪いことです。

説明したようにクラス変数を移動することで、問題を取り除くことができました。

POSIXy C ++でレイヤー2パケットを受信するにはどうすればよいですか？パケットには、srcおよびdst MACアドレス、タイプ/長さ、およびカスタム形式のデータのみが含まれます。それらはTCPでもUDPでもIPでもIGMPでもARPでも何でもありません-それらはハードウェアの人たちによって私に与えられた自家製のフォーマットです。

私socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW)はそのから戻ることはありませんrecvfrom()。

うまく送信できますが、ネットワークスタックでどのようなオプションを使用しても受信できません。

（プラットフォームはVxWorksですが、POSIXやLinuxなどを翻訳できます...）

受信コード（現在の化身）：