Welche max. Datenübertragungsrate bei internen Taktgeber?

Gast #3444678
Lesenswert?

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.
(Firma: guloshop.de) #3444763
Lesenswert?

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.
#3444787
Lesenswert?

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.
#3445011
Lesenswert?

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
Gast #3445036
Lesenswert?

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.
Gast #3445083
Lesenswert?

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...
Gast #3445109
Lesenswert?

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
Gast #3445159
Lesenswert?

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.
#3445179
Lesenswert?

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.
#3445195
Lesenswert?

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.
#3445731
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren