CAN Verständisprobleme

Gast #6371457
Lesenswert?

Hallo,

Ich habe ein paar Verständnisprobleme zu den CAN Bus (auf Protokoll 
ebene). Ich mache jetz mal ein paar Aussagen:

CAN ist ein Multimasterbus, jeder Teilnehmer ist zunächsteinmal 
gleichberechtigt.
Es gibt eine Priorisierung welche durch den Identifier festgelegt sind. 
Die Nullen sind hierbei die Dominanten Bits.
Der Identifier beschreibt nicht das Device sondern die Information.
Der informationsadressraum beträgt 2^11 * 8 Byte (16KByte) (bei 11 bit 
Identifier).
Der Identifier darf im Bus nur einmal zum Senden verwendet werden, sonst 
wüsste man nicht von welchem Device die Information stammt (es gibt ja 
keine Absenderadresse).

Ein Device kann keine Informationen bei einem anderen Device "erfragen" 
(So wie man das z.b. bei einem Master Slave Bus kennt),
sondern jedes Device schickt seine Daten raus, z.b. bei einer Änderung 
oder bei einem festen Takt.
#6371477
Lesenswert?

CAN schrieb:
> Der informationsadressraum beträgt 2^11 * 8 Byte (16KByte) (bei 11 bit
> Identifier).

Wie kommst darauf? 2^11 = 2048 IDs, wobei Extended auch noch geht je 
nach CAN Standard.

CAN schrieb:
> Ein Device kann keine Informationen bei einem anderen Device "erfragen"
> (So wie man das z.b. bei einem Master Slave Bus kennt),
> sondern jedes Device schickt seine Daten raus

Doch, ist aber etwas verpönt und teilweise wird davon abgeraten. 
Stichwort:
 Remote Frames

Grüße
#6371844
Lesenswert?

CAN schrieb:
> CAN ist ein Multimasterbus, jeder Teilnehmer ist zunächsteinmal
> gleichberechtigt.

Ich würde ja sagen, es hat gar keinen Master, aber ja, alle sind 
gleichberechtigt.

> Es gibt eine Priorisierung welche durch den Identifier festgelegt sind.
> Die Nullen sind hierbei die Dominanten Bits.

Ja. Daraus ergibt sich, dass niedrige IDs eine höhere Priorität haben.

> Der Identifier beschreibt nicht das Device sondern die Information.

Ja.

> Der informationsadressraum beträgt 2^11 * 8 Byte (16KByte) (bei 11 bit
> Identifier).

Sofern man nicht noch ein Transportprotokoll wie z.B. ISO-TP darauf 
legt. Allerdings sind die oberen 16 IDs reserviert und sollen nicht 
benutzt werden. Es stehen also nicht 2048, sondern nur 2032 IDs zur 
Verfügung.

> Der Identifier darf im Bus nur einmal zum Senden verwendet werden, sonst
> wüsste man nicht von welchem Device die Information stammt (es gibt ja
> keine Absenderadresse).

Es ist dem Empfänger aber auch egal, von dem die Daten kommen. Das 
Problem würde ich eher so beschreiben, dass dann zwei Absender separat 
Daten senden und quasi konkurrieren. Wenn sie verschiedene Daten senden, 
kommt Kuddelmuddel raus, und wenn sie die selben Daten senden, ist das 
unnötig.

> Ein Device kann keine Informationen bei einem anderen Device "erfragen"
> (So wie man das z.b. bei einem Master Slave Bus kennt),
> sondern jedes Device schickt seine Daten raus, z.b. bei einer Änderung
> oder bei einem festen Takt.

Das ist die gängige Art, CAN zu verwenden.

Joe J. schrieb:
> Doch, ist aber etwas verpönt und teilweise wird davon abgeraten.
> Stichwort:
>  Remote Frames

Dafür gibt's im Header das RTR-Bit (Remote Transmit Request). Ich habe 
es aber auch noch nie in Verwendung gesehen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren