Hallo, ich benutze den CAN Controller MCP2515 und würde gerne wissen, was passiert wenn 2 meiner Nodes eine CAN Nachricht mit gleicher ID aber unterschiedlichem Payload senden (kein RTR). Die Arbitrierung läuft ja ,soweit ich das im Datenblatt ersehen konnte, auch nach der ID weiter. Was passiert aber nun wenn der Controller mit seiner Message "verliert" und genau die ID die er gerade absetzen wollte soweben auf dem Bus war? Bei RTR hab ich gelesen, das die RTR Nachricht dann sinnvollerweise verworfen wird, aber was passiert bei einer Nachricht die das RTR Bit nicht gesetzt hat? Vielen Dank schonmal Gruß Philipp
Bin mir nicht ganz sicher, was da passiert. Zwei Erklärungen habe ich: 1.) Der zweite Sender merkt, dass auf dem Bus was nicht stimmt (schreibt ja rezessiv und liest dominant) also vermerkt er einen Tx-Error (+8) und schickt ein ErrorFrame. Die Botschaft wird dadurch von allen Busteilnehmern verworfen und wiederholt - auch vom ersten, eigentlichen Sender. Das Spiel wiederholt sich, bis sich der zweite Sender wegen Erreichen seiner TX-Fehlerschwelle vom Bus zurückzieht. (Er zieht sich vom Bus als erster zurück, weil er seinen Tx-Fehlerzähler als aktiver Sender schneller inkrementiert wie die anderen Knoten, die nur passiv einen Fehler erkennen). Danach kommt endlich die Nachricht des ersten Senders durch. 2.) Das Rücklesen der gerade gesendeten Daten findet nur in der Arbitrierungsphase statt, danach nicht mehr. Also merkt der zweite Sender vom Problem nichts - schreibt also munter weiter. Tritt jetzt der Fall ein, dass der zweite Sender den ersten Sender mit einem dominanten Bit überschreibt, dann kommts in den restlichen Knoten zu Fehlern (je nach Fehlerbit kann das z.B. ein CRC-Fehler, Bitstuffingfehler usw. sein). Die anderen Knoten senden einen Errorframe, der die beiden Sender veranlasst ihre Nachrichten zu wiederholen. Das Spiel beginnt von vorne, bis sich die beiden selbst abschalten. Grund siehe unter 1. Überschreibt der zweite Sender keine Bits des ersten Senders, so würde das Problem eigentlich gar nicht auffallen... Hm. @all: Kann ein CAN-Experte hier weiterhelfen? Und nein, die Arbitrierung (=wer darf den Bus benutzen) ist per Definition nach dem RTR-Bit beendet. Deshalb niemals zwei CanIds von 2 unterschiedlichen Knoten verschicken lassen!
Ok vielen Dank scheint ja echt ne Frage zu sein die man so einfach nicht beantworten kann :) Dann muss ich mir wohl was anderes überlegen Gruß Philipp
Hi, ich verstehe nur nicht ganz, warum du nicht einfach auf eine andere CAN ausweichst. Schliesslich warst du bereits in der Annahme, durch den Nachrichteninhalt die Priorität der Nachrichte weiter zu bestimmen. Die kannst du ja dann ganz einfach um den Bereich dein CAN_ID einfügen. Es gibt ja auch noch CAN 2.0b, falls dir die 2^11 Identifier ausgehen ;-) grüße
Hi, ich habe mal eine andere Frage. Wie werden diese ID's festgelegt? Sind diese in Hardware implementiert und haben eine allgemein gehaltene Bedeutung. Oder werden diese in der Software der einzelnen Busteilnehmer festgelegt. Wenn diese von jedem Controller per Software verwaltet werden, ergibt sich bei mir folgender Gedanke. Da ja die 0 bei CAN dominant ist, kann man fuer jeden Busteilnehmer und dessen Bedeutung, seine eigene Prioritätsstufe mittels ID festlegen. Somit wäre die ID 0x000 (11bit), diese welche die hoechste Priorität hat. Alle anderen werden darauf aufgebaut und wuerden nach Prorität das Senderecht bekommen. Damit es wie in diesem Post beschrieben nicht zu einem Buskonflikt kommt. Muesste jede ID nur einmal als Sendeversuch (RTR=0) auftreten. Der CAN - Bus selbst ist ja nur eine OSI-Schicht 2. Das heisst er baut auf beliebige Uebertragungsmedien(Schicht 1) auf und wird von einer selbsterdachten Kontrollsoftware(Schicht 3) gesteuert. Gibt es da schon offene Programmieralgorithmen fuer Mikrokontroller welche sozusagen die Schicht 3 oder hoeher darstellen? Wenn ja, wo finde ich diese? MfG Daniel
"Da ja die 0 bei CAN dominant ist, kann man fuer jeden Busteilnehmer und dessen Bedeutung, seine eigene Prioritätsstufe mittels ID festlegen. Somit wäre die ID 0x000 (11bit), diese welche die hoechste Priorität hat. Alle anderen werden darauf aufgebaut und wuerden nach Prorität das Senderecht bekommen. Damit es wie in diesem Post beschrieben nicht zu einem Buskonflikt kommt. Muesste jede ID nur einmal als Sendeversuch (RTR=0) auftreten." Genau so ist das auch gedacht. Gruss Axel
Thread beobachten
Seitenaufteilung abschaltenBitte 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.