CAN Baudrate berechnen?
- Ersteller Janiiix3
- Erstellt am
TommyB
Team Bitschubse
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.
"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.
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.
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.
TommyB
Team Bitschubse
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.
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.
Premium Benutzer@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.
@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.
TommyB
Team Bitschubse
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:
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.
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.
Zuletzt bearbeitet:
@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.
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.
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...
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:
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:
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
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:
- SYNC_SEG: Das SYNC-Segment (das ist meist von der HW Vorgegeben und beträgt 1 tq
- PROP_SEG: Das Propagation Segement. Das ist das Segment, das dazu dient, physikalische Verzögerungen in der Übertragungsstrecke aufzufangen.
- 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
- 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.
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:
- 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
- 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.
- 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
Zuletzt bearbeitet:
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?
Zuletzt bearbeitet:
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...
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!
Zuletzt bearbeitet:
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
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
falls es noch benötigt wird ein kleines Beispiel:
Man möchte 100.000 bps Baudrate und wählt 25 TQ (hatte dazu mal eine kleine Tabelle erstellt um mit den Zahlen (TQ) jonglieren zu können, um sich dann etwas mit geringer Abweichung aussuchen zu können.) Man könnte sich aber in der Tabellenkalkulation alle Ergebisse für TQ 8-25 anzeigen lassen.
( Systemtakt / TQ ) / Baudrate)
( 8.000.000 Hz / 25 ) / 100.000 = Prescaler 3,2 = gerundet 3
Systemtakt / ( Prescaler gerundet * TQ )
8.000.000 Hz / ( 3 *25 ) = 106.667 Baud
( Abweichende Baudrate / Gewünschte Baudrate ) -1
( 106.667 / 100.000) - 1 = 6,67% Abweichung
wenn man jetzt eine TQ von 20 statt 25 ausprobiert, erhält hat man eine Abweichung von 0%
Generell muss der TQ muss zw. 8 und 25 groß sein.
Hier noch ein Bild woraus man erkennt das das Verhältniss zw. Prob-Seg+PhaseSeg1 und PhaseSeg2 den Abtastzeitpunkt verschiebt.
Bei einem ATMega16M1 stellt man den CAN Baudratenteiler im CANBT1 Register auf 3 ein und die Werte für CANBT2 und CANBT3 für TQ=20 kann man sich aus der Tabelle im Datenblatt ziehen wenn man es nicht selbst zusammenstückeln will. Das wären hier =0x0E und 0x4B
Man möchte 100.000 bps Baudrate und wählt 25 TQ (hatte dazu mal eine kleine Tabelle erstellt um mit den Zahlen (TQ) jonglieren zu können, um sich dann etwas mit geringer Abweichung aussuchen zu können.) Man könnte sich aber in der Tabellenkalkulation alle Ergebisse für TQ 8-25 anzeigen lassen.
( Systemtakt / TQ ) / Baudrate)
( 8.000.000 Hz / 25 ) / 100.000 = Prescaler 3,2 = gerundet 3
Systemtakt / ( Prescaler gerundet * TQ )
8.000.000 Hz / ( 3 *25 ) = 106.667 Baud
( Abweichende Baudrate / Gewünschte Baudrate ) -1
( 106.667 / 100.000) - 1 = 6,67% Abweichung
wenn man jetzt eine TQ von 20 statt 25 ausprobiert, erhält hat man eine Abweichung von 0%
Generell muss der TQ muss zw. 8 und 25 groß sein.
Hier noch ein Bild woraus man erkennt das das Verhältniss zw. Prob-Seg+PhaseSeg1 und PhaseSeg2 den Abtastzeitpunkt verschiebt.
Bei einem ATMega16M1 stellt man den CAN Baudratenteiler im CANBT1 Register auf 3 ein und die Werte für CANBT2 und CANBT3 für TQ=20 kann man sich aus der Tabelle im Datenblatt ziehen wenn man es nicht selbst zusammenstückeln will. Das wären hier =0x0E und 0x4B