Grundlagen CAN-Bus

Maik Gast #759304
Lesenswert?
• ▲
▼ 
Hallo,

nachdem ich hier ein wenig rumgesucht habe sind mir schon einige 
interessante Threads zum Thema CAN-Bus aufgefallen. Leider konnten meine 
Fragen bzgl. Stuff-Bitting nicht vollkommen beantwortet werden.

Mich interessiert eigentlich weniger der technische Zusammenhang 
(Ansteuerung und Kommunikation über den CAN-Bus kann ich ganz gut und 
habe ich bereits mit unterschiedlichen Controllern bzw. CAN-Tools 
gemacht).

Gibt es eine einleuchtende Begründung dafür, warum beim Stuffing nach 5 
gleichen Bits ein invertiertes eingeführt wird? Warum nicht nach 4, 6, 
oder 7...?

In der Spec von Bosch wird nur beschrieben, wie das Stuffing 
funktioniert. Leider konnte ich nichts zur Motivation finden.

Hat es was damit zu tun, dass man dadurch Fehlerframes (min. 6 dominante 
oder rezessive Bits) erkennen will, und somit die Zahl 5 irgendein 
Optimum dargstellt?

Teilweise liest man auch, dass es was mit der Synchronisation zu tun 
hat. Diese wird aber nur bei rezessiv auf dominant neu durchgeführt, und 
es soll lt. Spec Situationen geben, in den bis zu 29 Bitzeiten keine 
Synchronisation durchgeführt wird. Ist also die (harte) Synchronisation 
ein Grund für das Stuffing? Hätte da nicht ein festes Schema mit 
definiertem Start und Stop Bit o. ä. auch gereicht und zu einem festen 
Datenrahmen geführt?

Ich danke euch für die Beantwortung
Maik.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Andreas K. #759361
Lesenswert?
• ▲
▼ 
Microchip drückt sich etwas anders aus: "Resynchronization can only 
occur on recessive-to-dominant edges. This implies that there can be a 
maximum of ten bits between resynchronization due to bit stuffing" 
[AN754, S.7].

Bosch selbst schreibt in einem Paper, dass in CAN 1.1 beide Wechsel zur 
Synchronisation führten und erst seit 1.2 nur noch ein Wechsel genutzt 
wird. Was darauf hindeutet, dass ursprünglich die klassische 
bitsynchrone Übertragung nach HDLC/SDLC bei der Definition des Bit 
Stuffing Pate gestanden haben könnte.

Die CAN 2.0 Spezifikation erwähnt zwar deine 29 Bits, aber in meiner 
Interpretation ist damit die Error Recovery gemeint: "Corrupted messages 
are flagged by any node detecting an error. Such messages are aborted 
and will be retransmitted automatically. The recovery time from 
detecting an error until the start of the next message is at most 29 bit 
times, if there is no further error." [S.8].
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Maik Gast #759441
Lesenswert?
• ▲
▼ 
Hallo Andreas,

danke für die Antwort. Mit rezessiv zu dominant hast du natürlich recht. 
Der Hinweis auf HDLC ist interessant. Schau ich mir bei Gelegenheit mal 
an.

Das was ich mit den 29 Bit meine ist folgendes:

"The maximum length between two transitions which can be used for
resynchronization is 29 bit times."

Quelle: http://www.semiconductors.bosch.de/pdf/can2spec.pdf S. 68 
(Resynchronization Jump Width)

Da eine Flanke wohl nur unter bestimmten Bedingungen zur Synchronisation 
verwendet werden kann, scheint es zu solchen langen Zeiten kommen zu 
können.

Aber trotzdem würde mich interessieren, ob jemand Informationen, hat 
warum gerade die Zahl 5 für Stuff-Bits verwendet wurde.

Maik
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank Gast #779345
Lesenswert?
• ▲
▼ 
Hallo!

Die Zahl 5 stellt angeblich das Optimum für die Re-Synchronisierung und 
den Datendurchsatz dar.

Aufgrund der Oszillatortoleranzen kann ein Bit kürzer oder länger sein. 
Wenn keine Synchronisierung erfolgt, summiert sich der Fehler auf und 
die CAN-Knoten können sich ggf. nicht mehr verstehen. (sample point)
Wenn das Stuff-Bit bereits nach 4 Bits eingefügt wird, dann verlängert 
sich der CAN Frame dementsprechend und die Zeit, in der auf dem Bus 
nicht mehr gesendet werden kann, wird auch größer, damit sinkt der 
Datendurchsatz.
Das CAN Protokoll beinhaltet auch eine Fehlererkennung. Wird vom CAN 
Controller eine Protokollverletzung festgestellt, dann wird ein ERROR 
Frame gesendet. Dieses ERROR Frame ist dann 6 dominante Bits lang und 
kann somit von allen anderen Knoten erkannt werden. Wenn das Stuff-Bit 
erste nach 6 Bit eingefügt wird, dann muss das ERROR Frame mindestens 7 
Bit lang sein. Somit würde wiederum der Datendurchsatz sinken.

Aber wahrscheinlich kommt der Wert aus dem UART Protokoll 1Byte=8Bit + 
Start und Stopbit sind insgesamt 10 Bit, davon die Hälfte sind 5. 
Passt!!!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren