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).
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.
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...
LotadaC, besser kann man das nicht zusammenfassen!
Danke!