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
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
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.
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?
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.
>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..
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
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
>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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.