CAN プロトコルがどのように機能するかをよく理解しています。2 つのノードが同時にネットワークを使用しようとすると、低い ID のフレームが優先され、もう一方のノードがこれを検出して停止します。
これは、socketcan を使用すると抽象化されるようです。ファイル ディスクリプタと同じように、単純に読み書きします。私は何かを誤解しているかもしれませんが、ほとんどのドキュメント ( http://lxr.free-electrons.com/source/Documentation/networking/can.txt ) を確認しましたが、明確に説明されているとは思いません。
フレームが最小の id フレームになるまで write() はブロックしますか、それともネットワークの準備が整うまでソケットはフレームをバッファリングできますか? その場合、これが発生したときにユーザーに通知されますか、それともループバックを使用しますか?
writeチャネル競合をブロックしません。write TCP ソケットと同じ理由でブロックされる可能性があります(ほとんどありません)。
CAN ペリフェラルは、カーネルから送信されるフレームを受信し、メディア アクセス コントロール プロトコル (MAC プロトコル) を実行してネットワーク経由で送信します。SocketCAN は、プロトコルのこの層について何も知りません。
フレームがバッファリングされる場所はペリフェラル/ドライバに依存します: チェーンの kernel-driver-peripheral は、独自の制御フロー メカニズムを備えた 3 つのチェーンされた FIFO として動作しますが、通常、(必要な場合) 最も多くバッファリングするのはドライバです (必要な場合)。利用可能なメモリが少なくなります。
SocketCAN インターフェイス (リンクの 4.1.2 を参照) を使用して特定のフラグを提供することにより、CAN スタック プロトコルのエラー (いわゆる「エラー フレーム」によって通知される) をサブスクライブすることができます。これは、でエラー情報を取得する方法です。アプリケーション層。
もちろん、ループバック インターフェイスをチェックすることで、正しく送信されたフレームをチェックできますが、これはやり過ぎです。代わりに、上記のエラー レポート メカニズムを使用する必要があり、その方が使いやすいです。