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?
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.
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.
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.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
CAN_Bus_Teil_01.jpg
(91 KB)
Bildchen_02.jpg
(83 KB)
