Bit-Stuffing CAN

weiß niemand was??

CAN kann icht nicht, bitstuffing ist mir aber von HDLC ein Begriff.

Da war die Definition so: Nach 5 Einsen kommt zwangsläufig eine Null,
die beim Empfänger ignoriert wird. Damit bei NRZ wird sichergestellt,
daß eine bestimmte "Mindestfrequenz" erreicht wird.

Die "Flags", die am Anfang und Ende eines Paketes gesendet wurden,
hatten 7 Einsen und waren damit eindeutig zu identifizieren.

Ich vermute, daß jeder Fehler im bitstuffing zu ungültigen Daten führen
dürfte, spätestens wenn der CRC-Check zuschlägt.

> übermorgen is Prüfung :-(
<Elternmodus>Und seit wann weißt Du das?</Elternmodus>

Viel Erfolg,
Falk

"Da steht drin, dass das EOF Field aus 7 rezessiven Bits
besteht, und somit bewusst gegen die Bitstuffing-Regel verstoßen wird.
Warum wird bewusst dagegen verstoßen?"

Ganz einfach, um es von Daten unterscheiden zu können.


Peter

...
wenn ich es recht verstanden habe, dann sammelt der Controller die
Stuffing Bits wieder raus, so dass am Ende wieder die gemeinen Daten
rauskommen.

>Da steht drin, dass das EOF Field aus 7 rezessiven Bits
>besteht, und somit bewusst gegen die Bitstuffing-Regel verstoßen
wird.
>Warum wird bewusst dagegen verstoßen?

Beim CAN will man einen Übertragungsfehler noch vor Abschluss der
betroffenen Nachricht an alle Teilnehmer melden. Wenn ein Teilnehmer
den DLC falsch liest (z.B.: 8 statt 4 Datenbyte) -> kommt er beim EOF
(da ja das Bit-Stuffing verletzt ist) drauf das der Rahmen schon zu
Ende ist und wird einen Fehler signalisieren...

>Fügt dann der Sender nach dem 5ten high ne 0 ein, oder wird das dann
>beim EOF nicht gemacht?
>Oder andersrum gefragt, prüft der Empfänger die komplette Nachricht
>nach Bitstuffing-Fehlern oder wird nur ein bestimmter Bereich
>geprüft?
Beim EOF wird bewußt das Bitstuffing verletzt um obigen Fehler zu
erkennen!

Danke euch schonmal.

Hmmm..naja gut ok. Aber wird dann bei der Übertragung das Stuff-Bit im
EOF rein gemacht oder nicht? Dass die Stuff-Bits beim Empfang wieder
raus gemacht werden is klar. Könnte man das auch so begründen, dass
somit gewährleistet ist, dass mindestens einmal pro Nachricht das
Stuff-Bit zur Synchronisation vorhanden ist?

"
Beim CAN will man einen Übertragungsfehler noch vor Abschluss der
betroffenen Nachricht an alle Teilnehmer melden. Wenn ein Teilnehmer
den DLC falsch liest (z.B.: 8 statt 4 Datenbyte) -> kommt er beim EOF
(da ja das Bit-Stuffing verletzt ist) drauf das der Rahmen schon zu
Ende ist und wird einen Fehler signalisieren...
"

Aber das widerum würde bedeuten, dass im EOF kein Stuff-Bit eingefügt
würde. Also gilt die Bit-Stuffing-Regel nicht für die ganze Nachricht,
sondern nur für nen bestimmten Teil?
Ok, das macht Sinn, aber dann muss der Empfänger eben auch das EOF
erkennen weil er sonst nen Bitstuffing Fehler meldet wenn 7  gleiche
Bits am tück kommen.