Telegramm CAN-Bus erstellen

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.

Doch...

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

Und zumindest der sollte es mal gemacht haben...

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.

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

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?

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.

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)?

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)?

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.

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.