シナリオ
CANバスに接続されたLinux搭載デバイスがあります。デバイスは定期的に CAN メッセージを送信します。このメッセージによって運ばれるデータの性質は、コマンドではなく測定に似ています。つまり、実際には最新のものだけが有効であり、いくつかのメッセージが失われても、最新のものを正常に受信している限り問題にはなりません。
次に、問題のデバイスは、後続のメッセージ送信間の間隔よりもはるかに長い時間、CAN バスから切断されます。デバイス ロジックは引き続きメッセージを送信しようとしていますが、バスが切断されているため、CAN コントローラーはメッセージを送信できず、メッセージは TX キューに蓄積されています。
しばらくすると、CAN バス接続が復元され、蓄積されたすべてのメッセージがバス上で 1 つずつキックされます。
問題
- CAN バス接続が復元されると、未定義の量の古いメッセージが TX キューから送信されます。
- CAN バス接続がまだ利用できないが、TX キューが既にいっぱいである間、いくつかの最新のメッセージ (つまり、唯一の有効なメッセージ) の送信は破棄されます。
- CAN バス接続が復元されると、TX キューがフラッシュされている間、短期間のトラフィック バーストが発生します。これにより、タイム トリガー バス スケジューリングが使用されている場合に変更される可能性があります (私の場合です)。
質問
私のアプリケーションは SocketCAN ドライバーを使用しているため、基本的には SocketCAN に適用する必要がありますが、他のオプションがあればそれも考慮されます。
考えられる解決策は 2 つあります。メッセージ送信タイムアウトを定義する (事前に定義された時間内にメッセージが送信されなかった場合、メッセージは自動的に破棄されます)、または古いメッセージの送信を手動で中止します (ただし、ソケットではまったく可能ではないかと思います)。 API)。
最初のオプションが私にとって最も現実的であるように思われるので、質問は次のとおりです。
- Linux で CAN インターフェイスの TX タイムアウトを定義するにはどうすればよいですか?
- TX タイムアウト以外に、上記の問題を解決するための他のオプションはありますか?