CAN-Bus Telegramm

Guten Tag,

ich lerne jetzt Telegrammprotokoll von CAN-Bus und übe es, ein CAN-Telegramm zu bilden. Das ist eine selbst ausgedachte Übung für mich welches ich als Telegramm darstellen trainieren wollte und brachte eure Hilfe.
Das erste Teil (von Start of Frame bis Datenfeld) habe ich gebildet. (s Anhangsdatei CAN_Bus_Teil_01). Den Rest vom Telegramm kommt 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?

Siehe hier:

http://www.mikrocontroller.net/topic/401462

ich sage gleich vorweg, dass ich mich nur begrenzt mit CAN auskenne.
Ich verstehe die Grundstruktur der Telegramme und welche Möglichkeiten und Limitierungen damit verbunden sind.
Ich habe mich jedoch niemals mit der Art und Weise des CRC Mechanismus beschäftigt und brauchte dieses Wissen bisher nicht unbedingt.

Wenn du dich auf ein Vorstellungsgespräch vorbereitest, wie du es angedeutet hast in dem anderen Forum, ist es (Nach meiner persönlichen Meinung) wichtiger es anwenden zu können!

Hast du schonmal praktisch versucht 2 µController miteinander per CAN zu verbinden und kommunizieren zu lassen?

Ich arbeite zufällig bei einer Firma welche "intelligente" Industriesensoren Herstellt als Firmware Entwickler.
Zu meiner Bewerbung musste ich zum einen aufzeigen dass ich mich mit den gemessenen Prozessgrößen auskenne und verstehe welche Informationen wichtig sind. Außerdem sollte ich anhand eines Schaltplans erklären welche Komponenten darauf verwendet wurden und mit Hilfe der Datenblätter die Verschaltung herleiten.

Dann gab man mir noch ein Stück Quellcode dessen Verlauf ich dem Schaltplan zuordnen musste.

Natürlich wurden im Quellcode bewusst Fehler eingebaut auf die ich Aufmerksam werden sollte!

Entschuldigung an dieser Stelle dass ich Off-Topic gegangen bin, aber ich denke dass dir mit meinem Erfahrungsbericht auch geholfen werden konnte :)

PS: Wenn ich jetzt einen Bewerber bewerten müsste, würde mich vor allem Interessieren was für praktische ERfahrungen er gemacht hat. Ob er sich mit der Thematik jenseits des Controllers und der Elektronik grundsätzlich auskennt und ob er auch mal "über den Tellerrand hinausdenkt" (Zur Übersetzung: Ob er ein Problem auch mal mit einer kreativen Alternative lösen kann) oder ob er eventuell Tallente und Erfahrungen hat, welche für erweiterte Aufgabengebiete nützlich sein könnten.

Ich muss gelegentlich dafür sorgen, dass Roboter (in diesem Fall Industrieroboter, nicht die selbstgebauten) über CAN mit den Dingen an denen sie arbeiten reden können.

Dabei ist mir noch kein CAN-Interface begegnet, das diese Checksummengeschichten nicht in Hardware abwickelt. Diese Dinge sind wahrscheinlich nur für wirkliche Low Level Entwickler relevant. Also wirklich für Leute, die z.B. CAN-Chips entwickeln oder sich um Signalqualität und EMV kümmern.

Für Softwareentwickler sind bei CAN viel eher Dinge wie ISO 15765, CAN Datenbanken usw. interessant.

Anders wäre es z.B. bei LIN. Das wird teilweise bei Microcontrollern über UART implementiert. Wer sowas entwickelt, muss sich sicher mit mehr Details auskennen.