mich würde es mal interessieren welche Datenübertragungsraten bei serieller Übertragung zw. 2 AVRs möglich sind wenn keine genaue externe Taktquelle zum Einsatz kommt sondern nur der interne Taktgenerator. Hat schon jemand Erfahrungen hierbei gesammelt?
Kommt auf die Länge der übertragenen Strings an. Würde sagen, nicht schneller als 2400 Baud. Ansonsten immer mindestens keramischer Resonator.
Wenn du statt einer asynchronen Schnittstelle (UART) auf eine synchrone zurückgreifst (SPI) dürfte auch eine Datenrate im MBit-Bereich kein Problem sein (brutto).
Ich würde sagen, dass das auf die eingesetzten avrs ankommt. XMegas haben bspw. einen genaueren Takt, als Megas.
Hannes schrieb: > Kommt auf die Länge der übertragenen Strings an. > Würde sagen, nicht schneller als 2400 Baud. Was hat die Geschwindigkeit mit dem Baudratenfehler zu tun. Wenn sich bei asynchroner Übertragung eines Zeichens der Fehler beim letzten Bit zu sehr aufsummiert hat, geht es schief. Dabei kommt es einzig und alleine auf den relativen Fehler (Prozent der Übertragungszeit) drauf an. Mit der Länge des Strings hat das überhaupt nichts zu tun, da bei der asynchronen Übertragung nach jedem einzelnen Zeichen die Karten neu gemischt werden.
Michael schrieb: > Was hat die Geschwindigkeit mit dem Baudratenfehler zu tun. Wenn sich > bei asynchroner Übertragung eines Zeichens der Fehler beim letzten Bit > zu sehr aufsummiert hat, geht es schief. Dabei kommt es einzig und > alleine auf den relativen Fehler (Prozent der Übertragungszeit) drauf > an. Genau, so ist es. Die Taktungenauigkeit hat keinen Einfluss auf die Baudrate, sondern nur auf die maximale sinnvolle Wortlänge. Wenn die Frequenz um +/- 5 % schwankt, kann ich asynchron eben keine 8 Bits sicher übertragen, sondern muss mich mit 4 Bits zufrieden geben. Jedes Byte wird dann eben in zwei Nibbles aufgeteilt und in zwei Portionen versendet. Dann sind solche Frequenzunterschiede überhaupt kein Problem.
Ich kauf einen kleinen SMD Quarz fuer 19 cents. Weshalb sollte ich es ueberhaupt ohne Quartz probieren wollen ? ZB wenn ich extrem energie sparen will. Dann kann man einen 32kHz Uhren Quarz verwenden und den internen RC auf diesen Quarz tunen. Sonst macht es wenig sinn auf einen quartz verzichten zu wollen.
Wie schon gesagt wurde: SPI oder I2C ist ja so, dass der Master den Takt sendet, daher ist die Genauigkeit des internen Oszillators völlig egal.
Thomas O. schrieb: > mich würde es mal interessieren welche Datenübertragungsraten bei > serieller Übertragung zw. 2 AVRs möglich sind wenn keine genaue externe > Taktquelle zum Einsatz kommt sondern nur der interne Taktgenerator. > > Hat schon jemand Erfahrungen hierbei gesammelt? Der interne Oszillator wird bei 25°C und 3V kalibriert. Unter diesen Bedingungen sind 4800 oder 9600 mit gesetztem U2X-Bit gegenüber PC relativ problemlos. Bei zwei gleichen AVR sollte das eigentlich egal sein, da die Abweichung vom Solltakt bei beiden gleich ist. Sofern sie unter gleichen Bedingungen betrieben werden. Ansonsten muß man die Oszillatoren selbst kalibrieren. Bei Kalibrierung auf eine Baudratenfrequenz(7,3728MHz), sind 115K2 gegen PC problemlos. Sind bei den AVRs beide Oszillatorfrequenzen gleich, ist jede Übertragungsrate möglich. Mag sein, daß die ultraorthodoxen Fundamentalisten das anders sehen. Aber die kennen auch nur den Atmega8. Bei den neueren Controllern und so neu sind die auch nicht mehr, funktioniert es. mfg. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Kalibrieren_des_internen_Oszillators_mit_Timer2_als_Zeitbasis
:
Bearbeitet durch User
Wenn einer der beiden AVRs eine gelegentliche automatische Erkennung der Bitrate anhand bekannter empfangener Daten durchführt, dann ist die Antwort auf die Frage nur von der Zeitauflösung dessen Taktes abhängig, nicht aber von der Genauigkeit des Taktes des Kollegen.
:
Bearbeitet durch User
Hannes schrieb: > Kommt auf die Länge der übertragenen Strings an. Nein, kommt es nicht. Es kommt primär darauf an, ob die Übertragung synchron oder asynchron erfolgt. Bei synchroner Übertragung spielt der genaue Takt der Peers keine Rolle. Er muß nur generell hoch genug sein. Bei asynchroner Übertragung hingegen spielt er natürlich eine Rolle, weil halt die asynchrone Übertragung darauf angewiesen ist, daß innerhalb eines Sync-Frames die Takte der Peers höchstens um einen bestimmten Betrag auseinander laufen. Der Sync-Frame einer UART reicht nun aber vom Beginn des Startbits bis zur Mitte des Stopbits eines jeden Datenworts. Deswegen spielt die Länge des Strings für das Problem der Taktsynchronität überhaupt keine Rolle, sehr wohl aber die Anzahl der benutzten Bits pro Datenwort. Je weniger Datenbits und je mehr Stopbits, desto weniger wahrscheinlich ist, daß ein Fehler durch auseinander laufende Takte der Peers entsteht. Nur bei sehr armseligen Implementierungen von Soft-UARTs, die sich nicht wenigstens an jedem Startbit neu synchronisieren, spielt tatsächlich die Stringlänge eine Rolle. Allerdings ist nirgendwo garantiert, dass die Datenworte immer in dichter Folge unmittelbar nacheinander eintreffen. Ganz im Gegenteil, es ist sogar ausdrücklich definiert, das die Abstände beliebig groß sein können, nur die Untergrenze steht fest, nämlich durch die festgelegte Anzahl der Stopbits. Implementierungen, die sich darauf verlassen, daß nach einem Stopbit immer unmittelbar das Startbit des nächsten Datenworts folgt, sind deshalb, ganz unabhängig von der Taktquelle, eigentlich als komplett unbrauchbar einzustufen. Allerdings gibt es einen Grenzfall. Nämlich den Fall, wenn man die Kontrolle über beide Peers hat, Datenbursts bekannter Länge austauscht und innerhalb der Bursts die maximale Übertragungsrate erzielen möchte. Dann wäre so eine Implementierung vielleicht akzeptabel. Ich würd's trotzdem auch in diesem Spezialfall nicht so machen. Jedenfalls nicht ohne Not.
Ich habe mit RC-Oszillator + UART nur schlechte Erfahrung gemacht. Sowohl mit Atmegas als auch mit Xmegas. Die Frequenz hängt zu sehr von der Temperatur ab.
Stefan us schrieb: > Ich habe mit RC-Oszillator + UART nur schlechte Erfahrung gemacht. > Sowohl mit Atmegas als auch mit Xmegas. Das kann nur eins bedeuten: Du bist nicht in der Lage, die Grenzen und Möglichkeiten zu berechnen und hast deshalb versucht, angesichts der Umstände unrealistisch höhe Bitraten zu erzielen, die die eben keine Funktion mehr garantierbar ist. Vorher ein wenig nachdenken und nachrechnen schützt ganz ungemein vor der Gewinnung von schlechten Erfahrungen... Übrigens: alles für eine recht genaue Abschätzung des zuverlässig Machbaren Nötige steht in den verdammten Datenblättern drinne. Man muß sie nur lesen und verstehen können...
Also wenn man sich den Bootloader von Peter Danegger mal anschaut... der macht da eine SW-UART mit 115200 baud in der Standard-Einstellung. Und das funktioniert ohne jeden Quarz. Ich selbst habe seit Jahren etwas mit 19200 baud mit der HW-UART zuverlässig ohne Quarz laufen. Wobei ich aber alle paar tausend Zeichen die Bit-Länge mal nachmesse und ggf. das Kalibrierbyte etwas nachjustiere. Und da ist noch viel mehr drin, siehe oben
Thomas Eckmann schrieb: > Unter diesen Bedingungen sind 4800 oder 9600 ... relativ problemlos. Jetzt würde mich ernsthaft interessieren, wo du dies Beziehung zur Baudraten ausgräbst. Hier geht es nicht um irgendwelchen Jitter auf der Übertragungsstrecke, sondern um die Zeitfehler durch abweichende Taktfrequenz.
Michael schrieb: > Thomas Eckmann schrieb: >> Unter diesen Bedingungen sind 4800 oder 9600 ... relativ problemlos. > > Jetzt würde mich ernsthaft interessieren, wo du dies Beziehung zur > Baudraten ausgräbst. > Hier geht es nicht um irgendwelchen Jitter auf der Übertragungsstrecke, > sondern um die Zeitfehler durch abweichende Taktfrequenz. Erstens grabe ich nichts aus, zweitens musst du mir nicht erklären, worum es hier geht. Und drittens kann ich rechnen. Bei 1MHz beträgt der Fehler in der Übertragungsrate bei 2400/4800/9600 0,2%. Alle anderen Baudraten liefern größere Fehlerraten. Diese kann man nicht verwenden, ob mit oder ohne Quarz. Bei 8Mhz gehen sogar 76800. mfg.
Thomas Eckmann schrieb: > Alle anderen Baudraten liefern größere Fehlerraten. In der ursprünglichen Frage geht es um 2 AVRs, nicht um PC und AVR. Folglich besteht kein Zwang, Standardraten zu verwenden.
:
Bearbeitet durch User
A. K. schrieb: > Thomas Eckmann schrieb: >> Alle anderen Baudraten liefern größere Fehlerraten. > > In der ursprünglichen Frage geht es um 2 AVRs, nicht um PC und AVR. > Folglich besteht kein Zwang, Standardraten zu verwenden. Hättest du meinen Beitrag oben gelesen, hättest du dir dienen sparen können. Thomas Eckmann schrieb: > Sind bei den AVRs beide Oszillatorfrequenzen gleich, ist jede > Übertragungsrate möglich. mfg.
Hallo, danke für eure Antworten, habe die Frage nicht gerade sehr genau spezifiziert. Ich will nun endlich meinen Hausbus verwirklichen, mit CAN Transceivern und einem eigen Protokoll in Software, wobei ich mich stark an CAN orientiere z.B.kürzerer Identifier mit Abritierung, Bitstuffing... Und da die Platinen möglichst klein ausfallen sollen will ich da auf einen externen Quarz oder Quarzoszillator verzichten. Durch das Bitstuffing hat man ja spätestens nach 5 Bits wieder eine neue Synchronisation.
In so einem Fall kann man auch jeweils periodisch ein paar Synch bytes uebertragen, und die Baudrate neu abgleichen.
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.