can bus

0 ist dominant.
1 ist rezessiv.

mark1 schrieb:

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.

Hi mark1,

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

joede

Eins gibt es immer noch zu sagen.

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.

Was bringt mir ne Nachricht mit der hoechste Prioritaet?
dachte zuerst immer die Prioritaet sagt aus welcher teilnehmer senden darf! aber das funktioniert ja jetzt mit Arbitrierung auf der bit ebende!

cu

der Identifier hat ja 11 Bit! und kommt gleich nach dem startbit? das wär dann logisch...das die Arbitrierung ja für diese bit gilt!!!

joede schrieb:

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.

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

kennst du auch den unterschied zwischen ttp/c and ttp/a ?
ttp = time triggert protocol

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

mark1 schrieb:

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.

über CAN als link layer kann man theoretisch alle höheren protokolle laufen lassen. wird halt etwas langsam sein, wenn noch viele andere messages mit niedrigeren IDs unterwegs sind.

sorry, zerstückelung wegen zickiger spamkontrolle.

TrashCAN schrieb:

> 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.

[quote="Tim"]

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.

TrashCAN schrieb:

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...

Tim schrieb:

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? wie hast du's gemacht? rumreichen eines sende-tokens nehme ich an...

CANalratte schrieb:

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.

Tim schrieb:

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?