125 kbit / sでの最大CANバスフレーム（メッセージ）レートは？

私のCANバスは125 kbit / sで実行されており、拡張フレーム形式のみを使用しています。送信できるCANフレームの最大レートを教えてください。データ長が常に8バイトであるとします。

このウィキペディアのページによると、各フレームの最大フレーム長は(1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128次のとおりです。

最小3ビットのフレーム間スペースを考慮すると、125 kbit / s未満の最大パケットレートは次のようになります。 125000 / ( 128 + 3) = 954フレーム/秒。

しかし、私のテストでは、それほど高くすることはできませんでした。私が達成できる最大フレームレート（8バイトデータすべてで）は、約850フレーム/秒です。

ここで何が間違っています-私の計算、または私のテスト方法？

Olin Lathropの提案に従って、ビットスタッフィングについて詳しく説明します。

CANはNRZコーディングを使用しているため、1または0の長い実行に満足できません（クロックエッジのあるべき場所を追跡できなくなります）。ビットスタッフィングによってこの潜在的な問題を解決します。送信時に5つの連続した1または0の連続に遭遇した場合、他の極性のビットを挿入し、受信時に5つの連続した1または0に遭遇した場合、後続のビットを無視します（ビットが前と同じでない限り）ビット。この場合、エラーフラグが発行されます。

テストデータに対してすべてゼロまたはすべて1を送信する場合、64個の同一ビットの文字列は、12個の詰められたビットを挿入します。これにより、合計フレーム長が140ビットに増加し、ベストケースのフレームレートは874フレーム/秒になります。データビットがCRCのMSBと同じである場合、そこに別の詰められたビットを取得し、フレームレートは868フレーム/秒に低下します。CRCに1または0が長く続く場合、フレームレートがさらに低下します。同じ考慮事項が識別子にも適用されます。

合計16の詰められたビットは、850.3フレーム/秒の理想的なフレームレートを生成するため、考慮する必要があります。簡単なテストは、交互ビットのテストデータを使用して、フレームレートがどうなるかを確認することです。

Olinは、ビットスタッフィングの説明と、それが理論上のCANスループットにどのように悪影響を与える可能性があるかについて、まさに正しいです。理論から実際のスループットをさらに低下させる可能性があるもう1つのことは、遅延です。CANコントローラーが100％のバス使用率を達成できる場合でも、ホストプロセッサはそのレートでTxおよび/またはRxを処理できない場合があります。これは、CANスタックを実装するプロセッサの速度が遅いか、ファームウェアが非効率的であるか、その両方の結果である可能性があります。

あなたが構築することができる最小の2.0A（標準）フレームは47bitsです...あなたが構築することができ、最小2.0B（拡張）フレームは、フレーム間の間隔の3ビットを含んでいること... 67bitsで、除外は詰め...のビット理論決して詰め込まないフレームを構築できます。実際には、ビットスタッフィングは非常に多く発生します！

CANBus 2.0a / bの最大ボーは1Mビットです。
1Mb / Sでは、1つの（支配的/劣性）ビットは1uSの長さです。0.000'001 S
したがって、67ビットフレーム[最小の理論的 2.0bフレーム]を送信するには、67uSが必要です。別の（67ビット）フレームを送信する前に。
1'000'000 / 67は14,925完全なフレームを提供します（+次のフレームの25ビット）

その速度の1/8で実行しているため、最大でパケットの
1/8 を取得できます14'925 / 8 = 1'865フレーム/秒@ 125Kb

すべての64ビット（8バイト）のデータを使用するまでに、連続する1または0の文字列を
1'000'000 /（67 + 64）= 7'633
7 'にして、ビットスタッフィング「エラー」をトリガーしていないと仮定します。633/8 = 954

そして、それはあなたの配線が完璧であることも仮定しています。あなたの缶バスは120ohm UTPケーブルで作られ、両端で容量的に分離されていますか？または、一方の端に120Ωの抵抗器が付いたランダムな線ですか？

全体として、理論上の最大スループットの90％を得るために、かなりうまくいっていると思います。