Hallo zusammen, ich habe gerade ein Problem mit dem Verständnis der Synchronisation bei CAN (nicht FD). Wie ist diese richtig umzusetzen? Ich möchte den CAN Controller in VHDL umsetzen. Ich kenne die Verilog Version von OpenCores, habe aber Probleme diese zu verstehen. Ich beziehe mich mal auf folgende Seite um das Timing zu berechnen: http://www.bittiming.can-wiki.info/ Ich gehe von einen Bosch C_CAN / D_CAN Controller aus mit einer "Clock Rate" von 96MHz und einem "Sample Point" von 87.5%. Die Anzahl der "Time Quantas" werden hier mit 16 berechnet, Seg1 mit 13 und Seg2 mit 2. Dies gibt einen Sample Point von 87.5% (Sync_Seg + Seg1 / #TQ = 14 / 16). Weiterhin wird ein SJW von 1 angenommen, was der bevorzugte Wert für CANopen und DeviceNet sein soll. Bis hier hin habe ich noch alles verstanden. Weiterhin gibt es noch ein Dokument von Bosch "The Configuration of the CAN Bit Timing": http://www.oertel-halle.de/files/cia99paper.pdf Im Abschnitt 3, "Phase Buffer Segments and Synchronisation" wird erklärt wir die Synchronisation funktioniert. "Hard Synchronisation" versteh ich, das Problem ist bei "Bit Resynchronisation". Generell gilt: "An edge is synchronous if it occurs inside of Sync_Seg, otherwise the distance between edge and the end of Sync_Seg is the edge phase error, measured in time quanta. If the edge occurs before Sync_Seg, the phase error is negative, else it is positive." Es wird hier von vielfachen der TQ gesprochen. Wenn jetzt aber wie empfohlen die SJW auf 1 steht, ist der Bereich der Synchronisation sehr gering. Macht es hier nicht mehr Sinn SJW auf einen höheren Wert zu stellen? Bei einer "Clock Rate" von 96MHz, sollte man dann nicht mit einer höheren Anzahl der "Time Quantas" arbeiten? Beispiel ist hier der Bosch M_CAN Controller. Hier wird mit 48 und 64 gearbeitet. Viele Grüße, Michael
Mal so wie ich das verstehe: Der Bit Timer Count wird eingestellt bei Detektion von SOF Bit. Also zB bei CAN Rate 1M auf 96-1 und dann wird runtergzählt bis 0. Der Resync bei jedem Übergang von rezessiv zu dominant, kann korrigieren, falls e /= 0. Ein TQ besteht aus mehreren Ticks von deiner 96M Clock. Wenn du also einen TQ springst, dann sind das schon mehrere Ticks.
Das Problem hat sich jetzt aufgelöst. Mein Fehler war das ich für die Flankenerkennung den 96MHz Clock für die "Soft Sync" benutzt habe. Aber hier darf man für die "Flankenerkennung" nur die "Time-Quantum" Werte benutzen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.