Telegramm CAN-Bus erstellen

[Hel B. (helbi)]

Hallo,

ich übe es, das CAN-Telegramm zu erstellen und bitte zu Prüfen was ich 
erstellt habe und um die Hilfe.

Das erste Teil (von Start of Frame bis Datenfeld) habe ich gebildet. (s 
Anhangsdatei CAN_Bus_Teil_01). Den Rest vom Telegramm erstelle noch 
später.

Ich bitte Sie zu schauen, ob ich es richtig tue. Ich vermute ich habe 
kein STUFF-Bit gesetzt, aber das muss man denke ich tun. Das habe ich 
noch nicht ganz verstanden: nach 5 gleichen Bitpegeln wird ein Zusatzbit 
mit umgekehrten Polarität eingefügt...
Ist das egal ob im "Nachrichten-ID-Feld", ob in "Steuerfeld", ob in 
"Datafeld" oder zwischen der Felder? Wenn zwischen der Felder - dann 
gehört der Stuff-Bit zu keinem Feld? (beim Sender meine ich; beim 
Empfänger wird Stuff-Bit gelöscht)

Also, in der Frage vermute ich, es fehlt auf dem Bild mindestens ein 
Stuff-Bit in Datafeld. Wo genau muss den Stuff-Bit dargestellt werden: 
nach dem fünften "0" zwischen der Ende Byte D1 und Anfang Byte D2 ?
Und nur ein Stuff-Bit muss hin ?


2. Frage zur Bildung von CRC-Feld. Ich habe gelesen: bei diesem 
Verfahren die zu übertragende Bits werden als Polynom betrachtet.
Wie kommt man dann auf nur 15 Bit im CRC-Prüfsumme? Allein das datafeld 
kann länger als 15 Bit sein... (s. Anhang: Bildchen_02)


Wie komme ich aus dem (auf dem "Bildchen_02") aufgefuhrten CRC-Beispiel 
zu meinem Fall?

Was genau wird als Polynom betrachten: nur Datafeld (in dem fall 2 Bytes 
= schon 16 Bits) oder das ganze Telegramm oder was noch?
Oder ist das was komplizierteres in diesen CRC-15-Bit-Prüfsequenz + 1 
rezessive Begrenzungsbit , was ich jetzt lassen soll?

[Rudolph R. (rudolph)]

Hel B. schrieb:
> ich übe es, das CAN-Telegramm zu erstellen

Warum?
Da kümmert sich der CAN-Controller drum und fertig.
So eine Übung hat nicht mal ansatzweise irgendeinen praktischen Bezug.

[X. X. (chrissu)]

Doch...

Irgendwer muss ja auch die CAN-Controller bauen...

Und zumindest der sollte es mal gemacht haben...

[Rudolph R. (rudolph)]

Chriss X. schrieb:
> Irgendwer muss ja auch die CAN-Controller bauen...

Ja, Bosch hat die gebaut, die IP wird von den Mikro-Controller 
Herstellern gekauft und in den eigenen Controller integriert.

[X. X. (chrissu)]

Also hat dass doch einen sehr praktischen Bezug...
Zumindest für Bosch.

[Hel B. (helbi)]

Es Stellenanzeige für uC-Softwareentwicklung.
Kenntnisse CAN-Bussystem sind erwünscht.

Aber die Stelle ist nicht von Bosch.
Ich denke, wenn die CAN-Kenntnisse sind erwünscht - dann muss ich das 
können - oder?
Wenn ich behaupte, dass ich CAN-Grundkenntnisse verfüge - dann gehört es 
dazu und kann gefragt werden.
Oder?
Oder verstehe ich was falsch?

[Rudolph R. (rudolph)]

Yup, und wir arbeiten alle bei Bosch und erfinden CAN immer wieder neu 
seit 1983.

Hel B. schrieb:
> Oder verstehe ich was falsch?

Etwas tiefere Kenntnisse schaden sicher nicht, aber für die µC 
Software-Entwicklung braucht man wirklich nicht zu wissen, warum sich 
jedes einzelne Bit auf dem CAN tummelt.
Mit "Kenntnisse" ist wohl eher der Umgang mit Botschaften gemeint, das 
versteht hier auch nicht jeder.

[Hel B. (helbi)]

Dann habe ich vielleicht Glück, mit euch zu kommunizieren. Aber ich bin 
Einsteiger.
Mein verständnis nach, muss ich das Protokoll im großen und Ganzen 
kennen (vielleicht ohne CRC-Feld oder mit).

Welche Fragen sind bei einem Vorstellungsgespräch üblich (um Firma sich 
vergevissern könnte, dass der Kandidat theoretische Grundverständnis CAN 
hat)?

[Hel B. (helbi)]

Rudolph R. schrieb:

> Etwas tiefere Kenntnisse schaden sicher nicht, aber für die µC
> Software-Entwicklung braucht man wirklich nicht zu wissen, warum sich
> jedes einzelne Bit auf dem CAN tummelt.
> Mit "Kenntnisse" ist wohl eher der Umgang mit Botschaften gemeint, das
> versteht hier auch nicht jeder.

Umgang mit Botschaften: könnte man das klären:

der Sender hat die Botschaft gesendet. Der Empfänger hat es bekomment 
und bestätigt.
Läuft automatisch, oder? Wo ist hier die Rolle eines SW-Entwicklers?
Oder was muss man z.B. mit Botschaften ein SW-Entwickler tun, wenn an 
seinem uC CAN vorhanden ist?

Was könnte als Frage in einem Kennenlernen Vorstellungsgespräch für 
einen klar definierten Einsteiger kommen (wegen CAN)?

[Rudolph R. (rudolph)]

So Sachen wie CRC und Bit-Stuffing laufen zusammen mit der 
Bus-Arbitrierung automatisch ab im CAN-Controller, da hat man von der 
Software-Seite her gar keinen Einfluss drauf.

Was bleibt ist der Botschafts-Aufbau, 11/29 Bit Identifier, 1...8 Byte 
Nutzdaten, Priorisierung durch die Identifier.
Nebenbei gibt es auch noch verschiedene Geschwindigkeiten mit den CAN 
betrieben wird und LowSpeed/HighSpeed Bus-Pegel.

Dann haben die Controller Message-Boxen und Filter für die Botschaften.
Jeder Knoten darf jederzeit senden, kommt aber je nach Buslast nicht 
sofort damit durch.

Gesendet wird üblicherweise in festen Zeit-Rastern, etwa alle 10ms.

Zusätzlich gibt es auch noch immer mal wieder was neues wie CAN partial 
Networking oder CAN FD.

Wenn man nicht ganz unten ansetzt sieht man den CAN auch nur über die 
API.
initCAN() sendCAN() oder was auch immer der Treiber her gibt.

[Rudolph R. (rudolph)]

Hel B. schrieb:
> Oder was muss man z.B. mit Botschaften ein SW-Entwickler tun, wenn an
> seinem uC CAN vorhanden ist?

Den Identifier festlegen und die Botschaft mit Inhalt füllen.
Wobei das fast noch zu weit geht, die Botschaften werden bei einem 
größeren Projekt eher über die CAN-Datenbasis in die Software gekippt.

Apropos CAN-Datenbasis, schau Dich mal bei Vector um, die haben 
umfangreiches Schulungsmaterial Online.

Und je nach Stelle könnte der sichere Umgang mit Tools wie CANanlyzer 
oder CANoe von Vorteil sein.