BitStuffing & CAN

[Timm (Gast)]

Hallo
BitStaffing bei CAN bedeutet ja das nach fünf gleichen Bits
ein invertiertes eingeführt wird
aber was passiert bei folgenden bitmuster?
0000 0100 00

macht er daraus 0000 0110 000

MFG Timm

[Wolfgang B. (logox2)]

ja

[Timm (Gast)]

Das bedeutet dann das wenn ich direckt auf dem Bus messe
das ich dan zb zwei gleiche id sehen kann wenn ich die stuffing bits
nicht berücksichtige

[Wolfgang B. (logox2)]

ja.

[Stefan (Gast)]

Ahm, ist vom Ausdruck ger etwas schwer zu interpretieren, was Du fragen 
wolltest, aber wenn Du auf dem Bus 5 gleiche aufeinander folgende 
Zustände siehst, ignorierst Du einfach das darauf folgende.
Etwas anderes würde der CAN-Protokollhändler auch nicht machen - von 
seiner Fehlererkennung mal abgesehen.

[Lutz (Gast)]

Hab ich mich auch schon gefragt. Aber einfach das darauf folgende Bit 
ignorieren würde ja bedeuten, daß ich die m. W. festgelegte 
Telegrammlänge beim Can-Protokoll um dieses Stuffingbit verlängern 
müßte, um die ursprünglich festgelegte Bitlänge eines Telegramms zu 
erreichen?

[Timm (Gast)]

Die Stufing Bits velängern auf jeden Fall das Protokol

[Timm (Gast)]

Habt ihr schon einmal so einen CAN Controller in Betriebgenommen
zb den MCP2515

[Lutz (Gast)]

In Betrieb genommen noch nicht, aber im Datenblatt fleißig am Lesen. Der 
Wikieintrag http://de.wikipedia.org/wiki/Bitstopfen sagt ja:

"Beim Bitstuffing werden nach fünf gleichen Bits ein inverses Bit 
eingefügt, und dadurch wird eine monotone Folge unterbrochen. Der 
Empfänger kennt dieses Verfahren und entfernt beim Empfang einer Folge 
von fünf gleichen Bits das folgende sechste Bit und erhält damit die 
ursprünglichen Daten."

Bei CAN habe ich so einiges noch nicht verstanden, z.B.:

1.) Auf S. 10 des Datenblattes des MCP2515 wird angezeigt, in welchem 
Bereich des Telegramms Bitstuffing bei Bedarf durchgeführt wird. Nur ist 
in der ganzen Beschreibung jedes Bit an seiner Position im Telegramm 
schon festgelegt, so daß ein Zusatzbit da gar nicht reinpaßt. Das einzig 
Variable am ganzen Telegramm ist die Anzahl der "Nutzbytes" (Data Field 
0 <= N <= 8). Ein Standard Data Frame ist z.B. 44 + 8N bit lang, also 
fix. Oder wird das Telegramm erst im Message Assembly Buffer "durch den 
Präprozessor gejagt" und dann "korrigiert" in die Receive-Buffer 
geschrieben?

2.) Woran erkennt das Protokoll nun, ob nicht sowieso nach 5 gleichen 
Bits "zufällig" ein inverses Bit kommt? Das wäre dann allerdings egal, 
wenn es so ablaufen würde, wie unter 1.) am Ende vermutet.

[Matthias L. (Gast)]

>Bit an seiner Position im Telegramm schon festgelegt

Nun, ich kenne micht nicht im Detail mit Bitstopfen aus, aber ich würde 
das mal so sehen:

Das Telegramm, welches zu senden ist, folgt aus dem Protokoll (hier CAN)
Darin ist die Bedeutung und die Position jedes Bits festgelegt.

Dieses Telegramm ist nun zu senden. Beim Senden ist die Bedeutung der 
Bits egal. Es geht nur um HIGH/LOW. Hier müssen entsprechende 
Mechanismen greifen, um die Übertragung möglichst störsicher zu machen, 
zB Bitstopfen.

Diese können beim Empfänger entfernt werden, danach erscheint das 
auszuwertende Telegramm.

Hm..

[Timm (Gast)]

Also Bit Stuffing ist klar

Es geht jetzt mehr um das Bittimig
da kann man ja verschiedene Dinge berechnen.
zb
SYNC
PROPSEG
PSEG1 und 2
usw

hat das schon mal jemand gemacht

[yalu (Gast)]

Die Suche nach

  can-bus bit timing

o.ä. liefert alles, was du wissen möchtest, einschließlich mehrerer
Online-Rechner, z.B. diesen hier:

  http://www.kvaser.com/can/protocol/timing_calc.htm

[Lutz (Gast)]

>Es geht jetzt mehr um das Bittimig da kann man ja verschiedene Dinge >berechnen.
>zb
>SYNC
>PROPSEG
>PSEG1 und 2
>usw

Da kann Dir vielleicht die Appnote von Microchip (Understanding 
Microchips CAN Module Bit Timing) weiterhelfen:

http://ww1.microchip.com/downloads/en/AppNotes/00754.pdf