Wie hoch ist die maximale CAN-Bus-Frame-Rate (Nachrichtenrate) bei 125 kbit / s?

Mein CAN-Bus läuft mit 125 kbit / s und verwendet ausschließlich das Extended-Frame-Format. Ich würde gerne wissen, wie hoch die maximale Rate von CAN-Frames ist, die ich senden kann. Angenommen, die Datenlänge beträgt immer acht Bytes.

Laut dieser Wikipedia-Seite hat jeder Frame eine maximale Frame-Länge von (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128Bits:

Geben Sie hier eine Bildbeschreibung ein

Unter Berücksichtigung von mindestens drei Bits Abstand Zwischenrahmen sollte die maximale Paketrate unter 125 kbit / s sein: 125000 / ( 128 + 3) = 954Bilder pro Sekunde.

Aber in meinem Test konnte ich nicht so hoch kommen. Die maximale Bildrate, die ich erreichen kann (mit allen 8-Byte-Daten), liegt bei 850 Bildern pro Sekunde.

Was ist hier falsch - meine Berechnung oder meine Testmethode?

communication can speed

— Penghe Geng
quelle

Schauen Sie es sich mit einem Zielfernrohr an und sehen Sie, was Sie tatsächlich bekommen. Möglicherweise ist Ihre Hardware nicht bereit, unmittelbar nach dem Senden eines neuen Frames einen neuen Frame zu senden. Berücksichtigen Sie auch die ACK-Zeit? Ihre unbeschriftete Bitsumme ist nicht hilfreich, um uns mitzuteilen, was genau Sie zählen.

— Olin Lathrop

In der Praxis ist es schwierig, über einen CAN-Bus eine 100% ige Busauslastung für längere Zeit zu erzielen, da ACK-Zeiten und Interframe-Abstände erforderlich sind. Möglicherweise kann Ihr CAN-Controller für längere Zeit keine 100% ige Busauslastung unterstützen.

— Tristan Seifert

Je nachdem, welche Daten Sie genau senden, kann Bitstuffing Ihre Bildgröße um bis zu 10% erhöhen.

— WhatRoughBeast

@xiaobai - Nein, die Länge des Datenfelds ändert sich. Einen Link haben Sie bereits angegeben. Lesen Sie die gesamte Seite. Wenn Ihre Tests alle Nullen oder alle Einsen senden, würde das viel erklären.

— WhatRoughBeast

ACK kann die Übertragungszeit beeinflussen, wenn Sie dies nicht berücksichtigen. Wiederum sagt uns Ihr unbeschriftetes Durcheinander von summierten Zahlen nicht, was Sie wirklich addieren und was Sie daher möglicherweise vermissen.

— Olin Lathrop

Antworten:

Per Olin Lathrops Vorschlag werde ich auf das Füllen von Bits eingehen.

CAN verwendet NRZ-Codierung und ist daher mit langen Reihen von Einsen oder Nullen nicht zufrieden (es verliert den Überblick darüber, wo sich die Taktflanken befinden sollten). Es löst dieses potenzielle Problem durch Bit-Füllung. Wenn es beim Senden auf einen Durchlauf von 5 aufeinanderfolgenden Einsen oder Nullen trifft, fügt es ein Bit der anderen Polarität ein, und wenn es beim Empfangen auf 5 aufeinanderfolgende Einsen oder Nullen trifft, ignoriert es das nachfolgende Bit (es sei denn, das Bit ist dasselbe wie das vorherige Bits, in diesem Fall wird ein Fehlerflag ausgegeben).

Wenn Sie alle Nullen oder alle Einsen für Ihre Testdaten senden, führt eine Zeichenfolge von 64 identischen Bits zum Einfügen von 12 angefüllten Bits. Dies erhöht die Gesamtframelänge auf 140 Bit bei einer besten Framerate von 874 Frames / Sek. Wenn die Datenbits mit dem MSB des CRC übereinstimmen, erhalten Sie dort ein weiteres gefülltes Bit, und die Bildrate sinkt auf 868 Bilder / Sek. Wenn der CRC lange Läufe von Einsen oder Nullen hat, wird die Bildrate noch weiter reduziert. Die gleiche Überlegung gilt für Ihre Kennungen.

Insgesamt 16 gefüllte Bits ergeben eine ideale Bildrate von 850,3 Bildern / Sek., Das sollten Sie berücksichtigen. Ein schneller Test wäre, Testdaten mit alternierenden Bits zu verwenden und zu sehen, was mit Ihrer Bildrate passiert.

— WhatRoughBeast
quelle

Ja, in meinem ursprünglichen Test gibt es tatsächlich viele Nullen in der Nutzlast und der ID. Nachdem ich sichergestellt habe, dass weder in den Daten noch in der ID 5 aufeinanderfolgende Nullen vorhanden sind, kann ich jetzt 940 Bilder / Sek. Erhalten, was sehr nahe an der berechneten Grenze liegt. Vielen Dank für die tolle Antwort.

— Penghe Geng

Olin hat Recht mit seiner Beschreibung des Bit-Stopfens und wie sich dies nachteilig auf den theoretischen CAN-Durchsatz auswirken kann. Eine andere Sache, die den tatsächlichen Durchsatz gegenüber dem theoretischen noch weiter verschlechtern kann, ist die Latenz. Selbst wenn Ihr CAN-Controller eine Busauslastung von 100% erreichen kann, ist der Host-Prozessor möglicherweise nicht in der Lage, Tx und / oder Rx mit dieser Rate zu verarbeiten. Dies kann das Ergebnis eines langsamen Prozessors und / oder einer ineffizienten Firmware sein, die den CAN-Stack implementiert.

— Trent Weaver
quelle

Der kleinste 2.0a (Standard) -Frame, den Sie erstellen können, ist 47 Bit ... Der kleinste 2.0b (Extended) -Frame, den Sie erstellen können, ist 67 Bit ... Das schließt 3 Bit Abstand zwischen Frames und EXKLUSIVE Bitfüllung ein ... Theoretisch wir können einen Rahmen bauen, der niemals stopft; In Wirklichkeit wird ein bisschen Füllung ziemlich viel passieren!

Das maximale Baud für CANBus 2.0a / b ist 1Mbit.
Bei 1 Mbit / s ist ein einzelnes (dominantes / rezessives) Bit 1 us lang, d. H. 0.000'001 S
Die Übertragung eines 67-Bit-Frames [des kleinsten theoretischen 2.0-Bit-Frames] dauert 67uS - bevor ein anderer (67-Bit-) Frame übertragen werden kann.
1'000'000 / 67 ergibt 14'925 vollständige Frames (+ 25Bits des nächsten Frames)

Da Sie mit
1/8 dieser Geschwindigkeit laufen, können Sie höchstens 1/8 der Pakete 14'925 / 8 = 1'865 Frames / Sekunde bei 125Kb erhalten

Wenn Sie alle 64-Bit-Daten (8-Byte-Daten) verwenden und davon ausgehen, dass Sie keine Bitstopf-Fehler ausgelöst haben, indem Sie Zeichenfolgen mit aufeinanderfolgenden
Einsen oder Nullen verwenden. 1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

Und das setzt voraus, dass Ihre Verkabelung perfekt ist. Ist Ihr Dosenbus aus 120 Ohm UTP-Kabel gefertigt und an beiden Enden kapazitiv entkoppelt? Oder eine zufällige Leitung mit einem 120-Ohm-Widerstand an einem Ende?

Insgesamt würde ich sagen, dass Sie ziemlich gut abschneiden, um 90% des theoretischen Maximaldurchsatzes zu erzielen.

— BlueChip
quelle