CAN-Bus - Latenzzeit

In der Literatur findet man immerwieder die Aussage, dass die Latenzzeit für eine Hochpiore Nachrischt 132 µs (bei 1MBps) beträgt. Das entspricht genau der Zeit, die ein sendewilliger Teilnehmer bei sofortigem Buszugriff braucht um das komplette Telegramm (mit 8 Byte Datefeld) zu übermitteln. Meiner Meinung nach wird dabei erstens übersehen, dass das Telegramm durch Bitstuffing um ein Paar Bitzeit verlängert sein kann; und zweitens, dass auch eine hochpriore Nachricht erstmal warten muss bis der Bus frei ist. Sprich: wenn ein TN gerade dann auf die Idee kommt zu senden, wenn mit der Sendung einer Nachricht begonnen wurde muss er uU. doppelt so lange warten.

Ist das richtig, oder hab ich einen Denkfehler danke

Reply to
steffenweissbach
Loading thread data ...

Mit allem Overhad (Bitstuffing usw.) hat eine 8Byte Message ca. 116 Bit Länge. Somit erhalte ich eine theoretische Übertragungszeit von

116us. Die 132us scheinen mir realistisch. Natürlich erfüllt ein Datenbus von sich aus den Realtime Aspekt nicht. Wenn man aber weiss, wie viel verkehr auf dem Bus ist, kann man eine gute Abschätzung machen. In der Praxis ist ein Busmonitor nützlich.

Gruss Stefan

Reply to
navigator

Ich komme beim Bitzählen für Extended-CAN (29-Bit-Identifier) immer auf 131 Bits (einschl. 3 Bits IFS) plus bis zu 23 Stuff-Bits.

Bei Standard-CAN (11-Bit-Identifier) sind's 111 Bits plus bis zu 19 Stuff-Bits.

Kann das jemand bestätigen?

-- snipped-for-privacy@gmx.net

Reply to
Bart Thanner

Das mit den 111 Bit ist richtig. Stuffbits kkönnen dabei aber theoretisch 24 auftreten. Die stuffintensivste Bitfolge würde mit 5 gleichen Bits beginnen, und dann immer abwechselnde jeweil 4 gleiche mit unterschiedlichem Wert. Das Stuffbit das aus den ersten 5 resultiert erzeugt eine neu stuffbedürftige Bitfolge

1111100001111000011110000.... aber das ist ziemlich theoretisch.
Reply to
steffenweissbach

Ich glaube nicht, dass das Stuffbit das erste Bit einer "stuffbedürftigen Bitfolge" ist.

In der CAN Specification heisst es: "... Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted stream."

Ich lese hier "inserts a complementary bit" und verstehe das so, dass das Stuffbit "eingefügt" wird. Dann geht's von neuem mit der Zählerei los.

Also: 11111(0)00000(1)11111(0)... (Stuffbits in Klammern)

-- snipped-for-privacy@gmx.net

Reply to
Bart Thanner

Allerdings ist deine beispielhafte Bitfolge nicht ganz richtig weil da

6 gleiche Bits auftreten, was von anderen Teilnehmern als Stuffingfehler registriert wird.

Kann aber sein, dass du prinzipiell recht hast für mein Beispiel würde das dann so aussehen.

1111100001111000011110000 11111(0)00001111000011110000

Bin aber noch unsicher. Die Frage ist, sieht sich der Sender die gestuffte Bitfolge nochmal an um sie nötigenfalls nochmal zu stuffen, oder zählt er einfach bit für bit und fügt was ein wenn's ihm nicht gefällt? Vielleicht weiß da jemand mehr.

Reply to
steffenweissbach

Ich habe nachgemessen (bei 1 MBits/s, DLC=0).

Messung 1: 11-Bit-Identifier 0x155

---------------------------------- S00101010101... (SOF, 001, 0101 0101, ... - ohne Stuffbits)

Messung 2: 11-Bit-Identifier 0x078

---------------------------------- S0000(1)1111(0)000... (SOF, 000, 0111, 1000, ... - zwei Stuffbits)

Es erscheinen im gestufften Bitstrom höchstens FÜNF gleiche Bits hintereinander. Dann wird ein komplementäres eingefügt. Das wiederum zählt gleich für die nächste Runde. In Messung 2 wird eine Stuff-"1" eingefügt, dann kommen VIER Daten-"1"er, dann muss eine Stuff-"0" kommen.

Plots bei

formatting link

-- snipped-for-privacy@gmx.net

formatting link

Reply to
Bart Thanner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.