Hallo, geht um einen AT90CAN128, der aus Stromspargründen (3,3V) und RS232-Baudrate bis 57,6kBd mit 7,3728MHz betrieben werden soll. Die CAN-Baudrate soll 250kBd betragen. Daraus mögliche Einstellung ist Bitzeit=15*TQ (Tq-soll wäre allerdings 14,75 -> 1,7%Fehler) Aufteilung der 15*TQ geplant: Tsyns = 1 Tprs = 4 (Register CANBT1) Tphs1 = 5 (Register CANBT2) Tphs2 = 5 (Register CANBT3) D.h. Abtastung anfänglich bei 67% Bitzeit. Kann das laufen? Ein Test ist mir momentan nicht möglich, Projektplanung muß aber weitergehen. Das Auseinanderlaufen müßte doch durch die Zwangssynchronisation nach spätestens 5 Bit (per Bitstuffing) im Rahmen bleiben?! Oder gibt es einen Quarz 7..10,6MHz, der RS232 und CAN glücklich macht? Danke für Hinweise! Frank
Dallas/Maxim Application Note 2935. Async ist toleranter als CAN, also besser CAN genau und UART ungenau als andersrum. So sind bei CAN offiziell nur 0,5% drin, bis 125Kbps noch 1,5%. Async jedoch 2,5% noch kein Problem.
6MHz passt doch ganz gut. Exakt 250kBaud beim CAN, 0,2% bei UART.
Danke bisher! @A.K. 57,6kBd-RS232 bei 8MHz hat einen Fehler von 2,1%. Noch tolerabel aber eng, wenn das RS232-Gegenüber nen Fehler in entgegengesetzter Richtung aufweist. @crazy_horse 6MHz wird mir zu knapp - bei 7MHz schon an der Schmerzgrenze, da ich einen Timer-Int 48000/s brauche. Dann hätte ich bei 6MHz nur 125Maschinenzyklen/Timer-Int.
Aber er will ja 7..10,6MHz. 10MHz passen da besser ins Bild.
2% würde ich nicht machen. Und die Spannung etwas anheben, dann kannst du mit 3,8V/12MHz arbeiten? Oder einen MC ohne CAN verwenden und einen MCP2515 dranstricken? Dann kannst du jedem Teil den passenden Quarz spendieren...
10MHz mit Teiler 11 ergibt einen Fehler von ca. 1,4%. Da sehe ich kein Problem drin.
Hab jetzt ne Grundlage zu entscheiden, ob 10MHz-Lösung oder 12MHz@3,8V oder größeren HW-Aufwand durch z.B. MCP2515 + 2. Quarz zum Einsatz kommt. Dank an Euch beide, Frank:-)
CAN synchronisiert spätestens nach 5 Bits, UART nur nach 10. CAN ist also wesentlich unempfindlicher als UART. Das Problem ist nur, aus den Datenblättern schlau zu werden, wie sich die einzelnen Bitphasen zusammenrechnen. Man kriegt den Eindruck, die Datenblattschreiber wissen es selbst nicht so genau. Meistens übernimmt man die Bittimings aus den Beispielen, aber die passen leider nur, wenn alles Quarzgenau auf volle MHz-Zahlen ist. Will man krumme Quarze nehmen, bleibt einem wohl nur, selber zu experimentiern. Aber gehen muß es prinzipiell auch mit krummen Quarzen. Peter
Hallo Peter, mein (oben angedeuteter) Gedanke war gleichfalls: CAN-Sync spätestens nach 5 Bit RS232-Sync nach 10 Bit Aber sonst jeder (incl. Datenblätter/AppNotes) sagt einem, CAN wäre kritischer... Falls ich nen Test fahren kann, mailde ich Bescheid, ab welcher Baudratenabweichung Fehler erscheinen;-)) Nur der Samplepoint bei üblichen 75% (statt logisch erscheinenden 50%) verschärft die Timinganforderung doch wieder auf RS232-Niveau (25% Headroom bei Sync_after_5Bit zu 50% Headroom bei Sync_after_10Bit) BTW: Ist 75% Samplepoint üblich, um Einschwingvorgänge (Reflexionen) abzuwarten? Gruß Frank
Wenn nun allerdings bei Maxim/Dallas und anderswo für CAN je nach Bitrate eine Toleranz von 0,5%-1,5% angegeben wird, u.A. mit Bezug auf den CAN-Standard, würde ich diese Angaben nicht gänzlich hinter eigenen Theorien verschwinden lassen. Jedenfalls nicht, ohne den Hintergund nachgelesen zu haben.
Wer sich in das Thema Frequenztoleranzen von CAN Bus reinarbeiten will: http://www.freescale.com/files/microcontrollers/doc/app_note/AN1798.pdf. Kann man sich dann ausrechnen, welche Toleranz bei welcher Länge und Bitrate noch drin ist. Kurzfassung: Peters Theorie scheitert an Ausbreitungsverzögerungen, d.h. die Leitungslänge mischt kräftig mit.
Bitte 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.