can bus

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?