Kollisionsprüfung
Jeder Teilnehmer darf Daten ohne besondere Aufforderung irgend eines Masters verschicken. Wie bei Ethernet kann es dazu kommen, dass mehrere Teilnehmer gleichzeitig senden. Die Nachricht mit dem niedrigsten Identifier setzt sich am Bus durch
Der Identifier mit der niedrigsten Binärzahl hat somit die höchste Priorität.
Den Vorgang zur Kollisionsprüfung über den Identifier nennt man „bitweise Arbitrierung“. Entsprechend dem "Wired-and-Mechanismus", bei dem der dominante Zustand (logisch 0) den rezessiven Zustand (logisch 1) überschreibt, verlieren all diejenigen Knoten den Wettstreit um die Buszuteilung, die rezessiv senden, aber auf dem Bus dominant beobachten. Alle "Verlierer" werden automatisch zu Empfängern der Nachricht mit der höchsten Priorität und versuchen erst dann wieder zu senden, wenn der Bus frei wird.
Der CANbus ist somit ein Bussystem mit bedarfsabhängiger Buszuteilung.
Auch gleichzeitige Buszugriffe mehrerer Knoten müssen immer zu einer eindeutigen Busvergabe führen. Durch das Verfahren der bitweisen Arbitrierung über die Identifier der zur Übertragung anstehenden Botschaften wird jede Kollision nach einer berechenbaren Zeit eindeutig aufgelöst: Im CAN Standard Format sind es maximal 13 Bitzeiten, im erweiterten Format sind es maximal 33 Bitzeiten.

was ich da nicht verstehe ist: man hat ja den identifier der die priorität festlegt aber dann sagt man auf einmal wieder:
Entsprechend dem "Wired-and-Mechanismus", bei dem der dominante Zustand (logisch 0) den rezessiven Zustand (logisch 1) überschreibt, verlieren all diejenigen Knoten den Wettstreit um die Buszuteilung, die rezessiv senden, aber auf dem Bus dominant beobachten

was ist dann nicht rezessiv senden und dominant beobachten? rezessiv senden ist doch senden von low bit? aber was ist dominant empfangen? high bit empfangen?

was ist der Wired-and-Mechanismus?

bye

schaut euch mal das bild an!
da gewinnt der s2! ich bin verwirrt...wo ist da nun die priorität?
ich lese ja auch: the frame with the highest priority is guaranteed to obtain access to the bus.

was ist der Wired-and-Mechanismus?

das ist eine fest verdrahtete 'logische und-verknüpfung'. damit auf dem bus eine '1' erscheint müssen alle eine 1 senden oder gar nicht senden. sobald einer eine '0' sendet, wird der bus auch '0' d.h. die sender der einsen haben pech gehabt.

auch wenn eigentlich schon alles gesagt ist, vielleicht nochmal im Detail, wie die Arbitrierung funktioniert:
1. Jeder Knoten liest auf dem Bus mit, auch wenn er sendet
2. Der dominante Pegel ist die 0, der Rezessive die 1 -> sendet ein Knoten eine 1 und liest eine 0 weiss er, dass ein anderer Knoten die 0 geschrieben hat und zieht sich vom Bus zurueck
3. Die Nachricht mit der niedrigsten ID (also die, die die meisten 0er enthaelt) hat die hoechste Prioritaet

Es fangen also wie in Deinem Link drei Knoten gleichzeitig an zu senden.
- Das erste Bit ist bei allen gleich -> alle denken weiter sie sind Sender
- Auch das zweite Bit ist fuer alle gleich (eine 1) -> alle deknen weiter sie sind Sender
- Beim dritten Bit schreibt S1 eine 1 auf den Bus, die wird aber von S2 und S3 mit deren 0 'ueberstimmt' (wired AND). Da S1 mitliest bekommt er mit, dass seine 1 von mindestens einem anderen Knoten 'ueberschrieben' wurde und damit seine Nachricht warten muss -> S1 schaltet auf Empfang, S2 und S3 sind weiterhin Sender
- Die naechsten Bits sind fuer S2 und S3 alle gleich -> beide denken weiter sie sind Sender
- Dann jedoch schreibt S3 eine 1 auf den Bus und S2 eine 0. Dadurch liest S3 die 0 ein, weiss, dass er eine 1 geschrieben hat und merkt dadurch, dass ein anderer Knoten senden darf -> er schaltet auf Empfang um

Hoffe mal, das war ausfuehrlich genug

Viele Gruesse

Damit das wired and funktionieren kann, synchronisieren sich die Sender auf Bitebene. Das bedeutet, dass die Bits immer "aufeinder liegen".

Nach was zur Umsetzung der Software. Es muss sichergestellt werden, dass jeder CAN-Teilnehmer eine eindeutige ID bekommt! Die Bus-Arbitrierung kann sonst nicht funktionieren. CAN-Protokolle wie OpenCAN implementieren deshalb sehr aufwendige Adressvergabemechanismen.

cu

Damit das wired and funktionieren kann, synchronisieren sich die Sender auf Bitebene. Das bedeutet, dass die Bits immer "aufeinder liegen".

ja, deshalb arbeitet CAN auch mit festen baudraten.

joede schrieb:

Nach was zur Umsetzung der Software. Es muss sichergestellt werden, dass jeder CAN-Teilnehmer eine eindeutige ID bekommt!

nö, warum? die IDs beziehen sich auf die messages. teilnehmer haben keine IDs (auf low level CAN ebene), sie müssen nur wissen, was die messages zu bedeuten haben.

mark1 schrieb:

Was bringt mir ne Nachricht mit der hoechste Prioritaet?

die killt alles andere d.h. sie setzt sich immer durch, z.b. könnte sie bedeuten 'der airbag muss jetzt aufgepumpt werden', was verständlicherweise vorrang vor einer message des blinkerhebels hat.

beide verwenden tdma, das ttp/a verwendet eine Round Description List...jeder slot wird fix einer nachricht zugeordnet! das ist doch das gleiche wie die MEDL (Message Descriptor List) im ttp/c ?

joede schrieb:

Nach was zur Umsetzung der Software. Es muss sichergestellt werden, dass jeder CAN-Teilnehmer eine eindeutige ID bekommt!

nö, warum? die IDs beziehen sich auf die messages. teilnehmer haben keine IDs (auf low level CAN ebene), sie müssen nur wissen, was die messages zu bedeuten haben.

Ähmm. Mein Fehler, sorry. Ich meinte mit ID nicht die CAN-Message-ID sondern eine Geräteadresse. CAN arbeitet ja mit Message-Broadcasts. Jeder bekommt die Message und nur wen sie interessiert verarbeitet sie. Das ist nicht wie bei TCP eine verbindungsorientierte Kommunikation.

Trotzdem kommt es vor, dass man eine Message gezielt an einen Konten schicken will (zumindest wollte ich das bisher immer ). Gerade wenn mehrere Knoten gleichen Gerätetyps im Netz sind, ist das gezielte ansprechen ohne Geräteadresse schwer.

Dies wäre der Fall, wenn man zum Beispiel die Seriennummer eines Knotens haben möchte. Zu diesem Zweck habe ich eine spezielle Message-ID mit der Geräteadresse versehen. So reagiert nur der adressierte Knoten.

Ein anderer Anwendungsfall wären "alive checks" in Form eines "Ping".

> Ich hab ja mal ein Protokoll vergewaltigen müssen, so dass alle Geräte im Verbund auf demselben Identifier gesendet haben. Das war eine schöne Frickelei

sollte aber eigentlich funzen.

> Ich hab ja mal ein Protokoll vergewaltigen müssen, so dass alle Geräte im Verbund auf demselben Identifier gesendet haben. Das war eine schöne Frickelei

sollte aber eigentlich funzen.

Klar, man muss halt irgendwie absichern, dass nie zwei (oder noch mehr) Teilnehmer gleichzeitig versuchen zu senden.

TrashCAN schrieb:

Klar, man muss halt irgendwie absichern, dass nie zwei (oder noch mehr) Teilnehmer gleichzeitig versuchen zu senden.

warum? wenn eine message nicht durchkommt, weil z.b. eine 1 von einer 0 niedergeknüppelt wurde, stimmt z.b. der crc nicht mehr, d.h. keiner ack'd und die message wird automatisch 'retransmitted'. soweit ich weiss, regelt die CAN hardware das selbständig und feuert die message so lange raus, bis das ACK kommt.

Tim schrieb:

Klar, man muss halt irgendwie absichern, dass nie zwei (oder noch mehr) Teilnehmer gleichzeitig versuchen zu senden.

warum? wenn eine message nicht durchkommt, weil z.b. eine 1 von einer 0 niedergeknüppelt wurde, stimmt z.b. der crc nicht mehr, d.h. keiner ack'd und die message wird automatisch 'retransmitted'. soweit ich weiss, regelt die CAN hardware das selbständig und feuert die message so lange raus, bis das ACK kommt.

Ja, die paar Error-Frames und die zusätzliche Buslast ist ja kein Problem...

Ja, die paar Error-Frames und die zusätzliche Buslast ist ja kein Problem...

kann, aber muss nicht und wenn, dann haben doch sowieso nur messages mit höherer ID darunter zu leiden.

sind error frames nicht optional?

Optional? Wenn ein Teilnehmer die Arbitrierung gewinnt und dann auf dem Bus anstelle seine rezessiven Bits ein dominantes sieht, gibts einen Error-Frame.

CANalratte schrieb:

wie hast du's gemacht? rumreichen eines sende-tokens nehme ich an...

Nö. Das war so ein Ping-Pong-Protokoll. Der Client sendet einen Request, darin ist u.a. eine IDE drin, die einen der Teilnehmer eindeutig anspricht. Empfängt dieser die Botschaft, darf er sofort senden. Die anderen sehen das und machen nichts. Sollte aber der angesprochene Teilnehmer aus einem Grund nicht existieren, dann sendet ein anderer Teilnehmer (der mit der niedrigsten ID) einen Fehler zurück, nach einer gewissen Zeit (abhängig von der eigenen ID).

Edit: Den Client durfte ich nicht anfassen. Deswegen das Gefrickel.

Optional? Wenn ein Teilnehmer die Arbitrierung gewinnt und dann auf dem Bus anstelle seine rezessiven Bits ein dominantes sieht, gibts einen Error-Frame.

ach so, ich kann mich dunkel daran erinnern mal irgendwo gesehen zu haben, dass man die erzeugung von error frames auch abschalten kann. aber eigentlich dürfte das wiederholen einer message (was ja ganz normal ist) keinen error frame auslösen, es sei denn, der teilnehmer ist nicht mit dem bus synchronisiert und haut dominante bits mitten in eine übertragung. error frames gibts doch eigentlich nur, wenn irgendwas richtig kaputt war, z.b. keiner ack'd, crc falsch, usw. ansonsten ist es das übliche spiel: die message mit der kleineren ID gewinnt und der andere muss eben seine message danach wiederholen muss. oder täusche ich mich?