Willkommen in unserer Community

Werde Teil unserer Community und registriere dich jetzt kostenlos ...

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

CAN Baudrate berechnen?

Dieses Thema im Forum "Hardware" wurde erstellt von Janiiix3, 3. Oktober 2017.

  1. Janiiix3

    Janiiix3 Mitglied

    Registriert seit:
    28. September 2013
    Beiträge:
    987
    Zustimmungen:
    6
    Ort:
    Hannover
    Sprachen:
    C
    Map
    Nabend.

    Es gibt hier doch sicherlich CAN erfahrene User oder?
    Mich würde mal genau interessieren, wie es mit der Berechnung aussieht. Es ist wohl mit irgendwelchen Zeit Quanten? Verbunden?

    Wie genau berechne ich diese?
     
    hdusel gefällt das.
  2. TommyB

    TommyB Premium Benutzer

    Registriert seit:
    17. Mai 2010
    Beiträge:
    1.612
    Zustimmungen:
    45
    Ort:
    127.0.0.1 ;)
    Sprachen:
    Assembler, LunaAVR, VB.Net, Python, C#
    Och mensch Jan,
    "wie berechne ich die Länge von Obst?"

    Was willst du machen? Was ist die Ausgangssituation? Welchen Chip / welches System willst du ansteuern?
    CAN ist nur eine serielles Schnittstelle wie I²C, SPI, RS-232, RS-485, ... auch. Das sagt überhaupt nichts aus, schon gar nicht über das Timing. Über das Protokoll was verwendet wird erst recht nicht.

    Ich habe ein SPI Display schon mit 4MHz Clock befeuert und es ging, es würde aber auch mit 1Hz gehen, dauert halt nur etwas länger. Ist halt vom Gegenüber abhängig. Afaik ist nur USB extrem strikt (auf beiden Seiten) was das Timing angeht.
     
  3. Janiiix3

    Janiiix3 Mitglied

    Registriert seit:
    28. September 2013
    Beiträge:
    987
    Zustimmungen:
    6
    Ort:
    Hannover
    Sprachen:
    C
    Map
    Die Ausgangssituation ist doch relativ. Mich interessiert einfach nur wie man das Bit Timing berechnet.
    Es wird wohl 1 Bit in mehrere Zeit Quartalen betrachtet. Um dieses zum Sync. und zur Fehlerkorrektur zu benutzen.

    Mich würde jetzt Interessieren, wie ich das ganze Timing berechne. Unabhänging vom welchem System oder geschweige denn einer Anwendung.
     
    hdusel gefällt das.
  4. TommyB

    TommyB Premium Benutzer

    Registriert seit:
    17. Mai 2010
    Beiträge:
    1.612
    Zustimmungen:
    45
    Ort:
    127.0.0.1 ;)
    Sprachen:
    Assembler, LunaAVR, VB.Net, Python, C#
    Das handelt jeder IC anders. Die meisten AVRs machen meine ich 8 Samples pro Bit, bei gedoppelter Bitrate nur 4. Davon ist aber eher abzuraten weil sich da das ein oder andere fehlerhafte Bit einschleusen könnte. Bei UART zumindest. Bei seriellen Verbindungen mit Clock Signal (wie SPI) ist das natürlich nicht notwendig.

    Ein Timing wird da nicht berechnet. 8 Samples pro Bit, also Baud*8, in diesem Fall. Gibt garantiert auch Chips die nehmen mehr oder weniger.
     
  5. Hemi

    Hemi Premium Benutzer

    Registriert seit:
    30. November 2008
    Beiträge:
    956
    Zustimmungen:
    4
    Ort:
    Korntal-Münchingen, Germany
    Sprachen:
    C, C++, PHP, Java
    Map
    @Thomas: Ganz so einfach wie bei UART ist es bei CAN nicht. Die Botschaft, die auf dem Bus landet, ist viel größer als nur Nutzdaten... Da wäre arbitration field (mit sof), control field, data field, crc field, ack field, end of frame, ims..

    @Janiiix3: Was willst Du genau berechnen? Von welchem CAN reden wir? LowSpeed? HighSpeed? CAN-FD? Wie lang ist der Identifier? Willst Du Netto- (nur Nutzdaten oder alles, also mit CAN-ID und DLC) oder Brutto berechnen? So lässt es sich nicht berechnen. CAN ist ein ereignisgesteuertes Protokol... Du stellst die Geschwindigkeit ein (sagen wir mal 500kbit/s) und dann hast Du eben die Buslast. Deswegen verstehe ich nicht, was Du genau willst.
     
  6. TommyB

    TommyB Premium Benutzer

    Registriert seit:
    17. Mai 2010
    Beiträge:
    1.612
    Zustimmungen:
    45
    Ort:
    127.0.0.1 ;)
    Sprachen:
    Assembler, LunaAVR, VB.Net, Python, C#
    @Hemi Das stimmt garantiert. Aber es ging ja so wie ich es verstanden habe um die Berechnung der Geschwindigkeit/Baudrate und nicht um das CAN Protokoll selbst ;)
    Ist ja wie Eisfischen. Ohne Loch.
     
  7. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.698
    Zustimmungen:
    38
    Ort:
    Hennigsdorf
    Sprachen:
    BascomAVR, Assembler
    Map
    Eben.
    Du kannst auch beim UART irgendein Protokoll drüberstricken (zB mit dem Multi Prozessor Communication Mode) - die Frage zielte aber nur auf die Baudrate, die Zeit eines Bits ab.
    Und die wird eben festgelegt.
    Beim CAN gibt es aber Bedingungen, zB daß der Anstieg und Abfall der Signale nur einen gewissen Teil der gesamt-Bitzeit haben darf. Diese Zeiten sind abhängig von der "Länge" des Busses (inklusive Verzweigungen (Stichleitungen)), und der Anzahl der Teilnehmer. Diese Zeiten beschränken also die Maximale Baudrate.
    UART arbeitet (üblicherweise) mit Push-Pull-Ausgängen - die Flanken sind also recht steil.
    Bein CAN sind die beiden Leitungen über Terminatoren (?) an den Busenden quasi kurzgeschlossen, haben im Ruhezustand bzw einem Null-Bit denselben Pegel. Eine "1" zwingt die beiden CAN-Leitungen (dominant) auseinander, die Rückkehr zur "0" erfolgt rezessiv über die Terminatoren. Die Flanken hängen also von der Gesamtkapazität des Busses (inklusive Teilnehmer) ab.

    Nachtrag:
    AVR-UART...
    nicht ganz...
    es werden in beiden Fällen drei Samples genommen, und davon die Majorität (Mehrheit) gebildet (demokratisch abgestimmt ;) )
    Im normalen Modus läuft das Sampling mit dem sechzehnfachen der Baudrate, verwendet werden die Samples 8, 9 und 10.
    Bei doppelter Bitrate läuft das Sampling mit dem achtfachen der Baudrate, verwendet werden die Samples 4, 5 und 6.
     
    #7 LotadaC, 14. Oktober 2017
    Zuletzt bearbeitet: 14. Oktober 2017
  8. Hemi

    Hemi Premium Benutzer

    Registriert seit:
    30. November 2008
    Beiträge:
    956
    Zustimmungen:
    4
    Ort:
    Korntal-Münchingen, Germany
    Sprachen:
    C, C++, PHP, Java
    Map
    Ja, aber Du kannst CAN nicht mit UART vergleichen. Bits ist das Eine, aber Du hast noch den CAN-Controller der auf den Pins sitzt...

    Ausserdem man gibt doch die Geschwindigkeit vor? Was will man da berechnen?

    Es kommt drauf an, wie es terminiert ist. Bei HighSpeed sind beide Enden mit 120Ohm terminiert, bei LowSeed wird jeder Node terminiert.
     
  9. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.698
    Zustimmungen:
    38
    Ort:
    Hennigsdorf
    Sprachen:
    BascomAVR, Assembler
    Map
    Ich weiß nicht, was Jan da konkret hat. Möglicherweise ist es auch ein AT90CAN... , also mit integriertem CAN-Controller, und da muß dann natürlich auch unter anderem ein Baudrateprescaler an die festgelegte Baudrate/CAN Frequenz angepaßt werden.
    Beim AVR-UART wird die Baudrate vorgegeben, man muß einen Teiler (Baudrateregister - UBRR) ausrechnen um diese mit dem Systemtakt zu treffen.
    Beim CAN wird auch eine Baudrate vorgegeben, vielleicht(!) zielt Jans Frage hier auf das entsprechende Äquivalent (CAN Bit Timing Register - CANBT3..1) ab...

    Du kannst sicher (masochistisch veranlagt) auch alles in Software in einen AVR stricken...
     
  10. hdusel

    hdusel Premium Benutzer

    Registriert seit:
    21. Februar 2016
    Beiträge:
    9
    Zustimmungen:
    1
    Ort:
    München
    Sprachen:
    C, Assembler, C++, Java, Python
    Map
    Servus miteinander,

    Der CAN Controller versucht seinen eignen Bitrate Clock anhand des Timings im Datensignal zu synchronisieren. Daher wird hier nicht nur eine einfache Baudrate - wie bei SPI / UART -verwendet, sondern es werden "tolerierbare Zeiten" vorgegeben.

    Anhand dieser Zeiten / Zeitfenster kann dann der CAN-Controller den effektiven Clock aus dem Datensignal "rekonstruieren".

    Bei CAN wird das Timing (i.d.R.) von dem sog. "Time Quanta" abgeleitet.

    Das ist ein Zeitmaßstab, der ein "Vielfaches" der eigentlichen Bitrate beträgt. Der Time Quanta wird von einer Clock-Source (Meist der CPU-Clock) bestimmt und dann entsprechend durch einen Prescaler eingestellt.

    Wenn ich oben schreibe "Vielfaches", dann meine ich damit dass die Bitrate effektiv n + "Time Quanta" (ich nennen es im Folgenden 'tq') meint, wobei der Faktor n die Summe aus vier Parametern ist:

    1. SYNC_SEG: Das SYNC-Segment (das ist meist von der HW Vorgegeben und beträgt 1 tq
    2. PROP_SEG: Das Propagation Segement. Das ist das Segment, das dazu dient, physikalische Verzögerungen in der Übertragungsstrecke aufzufangen.
    3. PHASE_SEG_1: Bildet die zu tolerierbare Zeit nach der "Propagation", also bei HIGH->LOW Wechsel die im Bitrahmen toleriebrare HIGH-Zeit, bei LOW->HIGH dann analog die Zeit für LOW
    4. PHASE_SEG_2: Bildet die zu tolerierbare Zeit nach der PHASE_SEG_1 und bildet damit das Ende des akzeptablen Zeitfensters für ein Bit auf dem CAN-Bus. Oder mit anderen Worten: Zusammen mit PHASE_SEG_1 erfüllen diese beide Zeiten den Zweck, Toleranzen in den Oszillatorfrequenzen der Busteilnehmer auszugleichen / aufzufangen.
    (Wer an Details interessiert ist, der möge sich dieses Dokument von Bosch ansehen)

    Also ist:
    n = SYNC_SEG + PROP_SEG + PHASE_SEG_1 + PHASE_SEG_2

    Gleichzeitig gilt:
    tq = CAN_Bitzeit / n

    die CAN_Bitzeit ist ja durch den Bus vorgegeben (z.B. 1MBit / s)

    Die o.G. 4 Zeiten / Parameter werden sich in jedem CAN-Controller in ähnlicher Form auch so in seinen Konfigurationsregistern wiederfinden.

    Vier Unbekannte zu bestimmen klingt erst mal nicht trivial, ist aber in der Realität nicht allzu schwierig, denn es gibt einige Faustformeln / Annahmen:
    1. SYNC_SEG ist meist fest von der CAN HW vorgegeben / im Controller fix implementiert und oftmals nicht veränderbar. Er beträgt 1 Tq - also bezogen auf Tq den Wert 1
    2. SYNC_SEG + PROP_SEG + PHASE_SEG_1 sollte 75% der Zeit der effektiven Bitrate sein. Als gute Praxis lege man PHASE_SEG_1 auf ungefähr 1,5 ... 2 x PHASE_SEG_2 fest.
    3. aus 2. folgt, dass PHASE_SEG_2 dann nach Adam Riese 25% der Bitratenzeit sein muss.

    Also um die Werte zu bestimmen ist hier lediglich triviale Schulmathematik nötig und ist somit gar nicht schwer, wenn man die o.G. Fausformeln annimmt / Annahmen trifft.

    Aber ACHTUNG!

    Es gilt immer auf den jeweils gültigen Wertebereich der Parameterfelder zu achten. Wie die jeweiligen Wertebereiche sind, sollte das entsprechende Prozessormanual aussagen.

    Also wenn "rechnerisch" 18 herauskommt und man in ein 4 bit Feld dann diesen Wert schreibt hat man effektiv den Wert 2 gesetzt was freilich reichlich falsch ist!

    Meist hilft es dann den Algorithums zur Bestimmung der Werte so zu schreiben, dass dieser iterativ vorgeht...

    Mein oben Geschriebenes zeigt noch viel anschaulicher die Seite http://www.bittiming.can-wiki.info
     
    #10 hdusel, 2. Dezember 2017
    Zuletzt bearbeitet: 3. Dezember 2017
  11. hdusel

    hdusel Premium Benutzer

    Registriert seit:
    21. Februar 2016
    Beiträge:
    9
    Zustimmungen:
    1
    Ort:
    München
    Sprachen:
    C, Assembler, C++, Java, Python
    Map
    Was einerseits stimmt und durchaus interessant für die Berechnung der Netto Bitrate ist - also die der effektiven Geschwindigkeit mit dem man die Daten (Payload) über den Bus schafft.

    Erschwerend kommen dann noch so Eigenheiten wie das sog. "Bit-Stuffing" hinzu, das auf dem Physical-Layer (da drum kümmert sich die CAN-Hardware) verhindert, dass mehr als 5 identische Bits in Folge übertragen werden. Liegt so eine Konstellation vor, dann fügt die CAN-HW ein "Stopfbit" ein, welches den inversen Pegel der identischen Bits hat. Das hat dann zur Folge, dass die effektive Übertragungsgeschwindigkeit sinkt.

    Aber für die Berechnung des Bittimings sind diese Felder erst mal irrelevant! Die Bitgeschwindigkeit wird von den Teilnehmern vorgegeben und die muss bei allen Busteilnehmern gleich sein!

    Wie gesagt, Die Bitgeschwindigkeit ist (mit Ausnahme von CAN-FD) erst mal konstant. Dass die Nettobitrate sich mit dem ganzen Overhead dann freilich noch ändert, stimmt. Aber ich glaube darum geht es Janiiix3 - wie ich ihn verstanden habe - erst mal nicht.

    Er möchte wissen, wie man den Controller auf die Bitrate auf dem Bus einstellt. Und das ist dann (bei non CAN-FD) eben eine fixe Zahl (z.B. 1 MBit/s oder 1µs per Bit). @Janiiix3 Liege ich da richtig?
     
    #11 hdusel, 3. Dezember 2017
    Zuletzt bearbeitet: 3. Dezember 2017
  12. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.698
    Zustimmungen:
    38
    Ort:
    Hennigsdorf
    Sprachen:
    BascomAVR, Assembler
    Map
    Hmm... eigentlich ist der Unterschied zum UART (des AVR) gar nicht so(!) groß.
    Der UART synchronisiert auf ein Byte (genauer: auf das Startbit), beim Can wird (zusätzlich?) auf jedes Bit mit einer Flanke synchronisiert. Da CAN-Telegramme (deutlich) länger als ein Byte sein können/sind, muß außerdem ausgeschlossen werden, daß die Flankensynchronisation beim fehlen selbiger versagt - deswegen die bereits genannten stuffing-bits (zusätzliche Flanken).
    Beim UART liegt der sampling Point (bzw die drei) in der Mitte eines Bits, beim CAN etwa (mit einer gewissen Variabilität) bei dreiviertel...
    Für beide benötigt man also ein vielfaches der Baudrate als Clock. Beim UART das 16 bzw 8fache (double speed), beim CAN wegen der höheren Variabilität auch eine variabler einstellbare...
    Grundsätzlich wird in beiden Fällen die sampling-clock vorgegeben (die beim UART auf das Byte, beim CAN auf jede Flanke synchronisiert wird), beim CAN wird zusätzlich der sample-point eingestellt.

    Daß das weitere Protokoll dann ein anderes Thema ist, wurde ja bereits gesagt (man kann sich ja auch beim UART irgendein Protokoll drüberstricken - beim CAN ist das halt bereits vorgegeben).

    Ich hatte das jetzt mehr aus den Datenblättern der CAN-AVR rausgelesen - die verlinkte seite ist natürlich sehr interessant/kompakt...
     
    hdusel gefällt das.
  13. hdusel

    hdusel Premium Benutzer

    Registriert seit:
    21. Februar 2016
    Beiträge:
    9
    Zustimmungen:
    1
    Ort:
    München
    Sprachen:
    C, Assembler, C++, Java, Python
    Map
    Danke LotadaC, dass Du diesen wichtigen Punkt hier heraushebst!

    Das Stuffing ist primär für diesen Zweck da, sonst verliert man bei monotonen Bitfolgen die Synchronisation.

    Übrigens ist auch die Tatsache, dass Stufung passieren kann auch der Grund, weshalb man - im Gegensatz zum UART sich bei CAN eben nicht auf einen fixen Frame auf dem physical Layer (auf der Leitung) verlassen kann.

    Beim UART sagt man z.B. als Format "8E2" (8 Databits, even Party, 2 Stoppbits), dann ist klar: 1 Frame besteht dann immer aus: 1 Startbit + 8 Databit + 1 Partybit + 2 Stoppbits = 12 Bits.
    Damit kann man dann mit einer Fixen (überabgetasteten) Samplingfrequenz arbeiten.
    Und da der UART nicht "stopft", herrscht genau dieser Frame auch auf der Leitung.

    Was bei CAN so einfach nicht geht, weil ein Frame auf dem physical layer eben durch die Stopfbits eben nicht fix ist.

    Abgesehenen davon ist die Länge eines CAN Frame auch schon auf logischer Ebene nicht so fest, wie bei einem UART, dann in ihm stecken - je nach Art der Message ID 11 bit (CAN 2.0A) oder 29 bit (CAN 2.0A) für die Message ID (Mixed Betrieb ist im Bus laut CAN 2.0B erlaubt) und freilich von 0 bis zu 64 Bits für den eigentlichen Payload. Mit noch zusätzliche Verwaltungsbits (RTR, ACK, Sync, CRC, etc. ) kommt man da bei einem CAN2.0A Frame mit SID (11 bit) und 8 byte payload auf brutto ca. 113 bits / frame.

    Was ich damit sagen will: Die Tatsache, dass ein Can-Frame in seiner Länge variieren kann, erfordert viel mehr Aufwand bei seiner Bitsynchronisation als dies bei einem fixen Frameaufbau (bsp. UART) nötig ist. Deshalb ist das Konfigurieren des CAN Sync/Bittiming auch etwas komplizierter ;)

    Ach noch was zu den Stoppbits. Der CAN Controller prüft ganz genau ob die Regel "nie mehr als 5 monotone Bits in Serie" eingehalten wird. Verletzt ein Teilnehmer diese Regel, wird er einen Errorframe auf dem Bus (und als ISR/Flag) reporten!

    Und nun wird's richtig lustig, denn ein Errorframe ersetzt ganz bewusst diese "5 monotone bit" Regel, denn er legt den Bus für mehr als die 5 bits auf dominant um wiederum bei allen angeschlossenen Busteilnehmern einen CAN Frame Error zu provozieren. Nu so finden alle wieder im Fehlerfall zusammen ;-) Details dazu liefert die CAN Spezifikation oder auch der CAN Artikel in Wikipedia.

    Aber keine Sorge: Um die Erzeugung und das erneute Senden (resend) der Daten im Fehlerfall kümmert sich i.d.R. die CAN Hardware. Zumindest kam ich noch keinen CAN Controller zu sehen, bei dem man das aktiv in SW machen musste.

    LotadaC, besser kann man das nicht zusammenfassen! :) Danke!
     
    #13 hdusel, 5. Dezember 2017 um 07:38 Uhr
    Zuletzt bearbeitet: 5. Dezember 2017 um 09:54 Uhr
  14. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.698
    Zustimmungen:
    38
    Ort:
    Hennigsdorf
    Sprachen:
    BascomAVR, Assembler
    Map
    Jan hat ja seit zwei Monaten nichts mehr dazu geantwortet. Seine Frage war, wie die Baudrate (Bit pro Sekunde, und Stuffing-Bits sind eben auch Bits, genau wie Start-, Stop- und Paritätsbits) bei CAN handzuhaben ist. Zumindest habe ich die Frage so verstanden.
    Und genau das ist meiner Meinung nach hinreichend beantwortet worden - insbesondere auch durch Dich, bzw durch die verlinkte Seite, wo es sogar einen Online-Rechner gibt, der die benötigten Registerinhalte ausspuckt...

    Wenn - falls - Jan noch weitere Fragen hat (zB zum Protokoll usw), muß er sie stellen (obwohl ja auch hierzu bereits viel geschrieben wurde).

    Wünsche allen weiterhin eine besinnliche Vorweihnachtszeit,
    LotadaC
     

Diese Seite empfehlen

  • Über uns

    Unsere immer weiter wachsende Community beschäftigt sich mit Themenbereichen rund um Mikrocontroller- und Kleinstrechnersysteme. Neben den Themen Design von Schaltungen, Layout und Software, beschäftigen wir uns auch mit der herkömmlichen Elektrotechnik.

    Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  • Coffee Time

    Unser makerconnect-Team arbeitet hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und unser eigener makerconnekt-Server regelmäßig gewartet wird. Wir nehmen das Thema Datensicherung und Datenschutz sehr ernst und sind hier sehr aktiv, auch sorgen wir uns darum, dass alles Drumherum stimmt!

    Dir gefällt das Forum und die Arbeit unseres Teams und du möchtest es unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft, unser Team freut sich auch über eine Spende für die Kaffeekasse :-)
    Vielen Dank!
    Dein makerconnect-Team

    Spende uns! (Paypal)