Wofür braucht man 14.7456 Mhz Quarz?

http://www.hanneslux.de/avr/tipps/baudratenquarz.html
nur damit er seine Links nicht immer nur selbst werfen muss  :-))

bye

Frank

Thx

schlaumeier.mit einem NICHT baudratenquarz hast du nicht alle üblichen
Baudraten zur Auswahl.Hast wohl nur mit 9600 gearbeitet als du deine
Modelleisenbahn getuned hast, wa? Träumer.

I.d.R. nimmt man an, dass eine Abweichung in der Baudrate von unter 2%
noch eine sichere Übertragung gewährleistet. In den AVR-Datenblättern
steht für alle gebräuchlichen Baudraten und Quarzfrequenzen die
Abweichung drin.

BTW:
Es wäre schön, wenn jemand diesem unverschämten Dummschwätzer-Troll
Pete Nerlinger endlich mal das Maul stopfen könnte! So einen Ton muss
sich auch in einem weitgehend anonymen Forum keiner bieten lassen...

Also, solange der Fehler unter 2% bleibt, habe ich noch nie Probleme
gehabt 115200 kBaud zu verwenden. Ich meine mal irgendwo gelesen zu
haben, dass sogar noch drei Prozent OK sind.

In den PIC18 Dokumentationen werden z.B. für verschiedenen Quarze die
zu erreichenden Übertragungsraten angegeben. In der Tabelle wird auch
immer der Fehler mit angegeben.

Ich verwende derzeit auch einen 15MHz Quarz für meinen LPC2103. Ich
kann zwar nicht mit einem 14,7456MHz Quarz vergleichen, aber zumindest
lässt sich die Programmiergeschwindigkeit bis 115200 steigern, und der
Programmiervorgang wird mit jeder höheren Rate auch tatsächlich
schneller. Da der LPC sich selber die richtige Geschwindigkeit sucht,
glaube ich.

Kannst du mir mal erklären, was dein Trollmüll jetzt soll?

@Martin:
Ist schon richtig, das ist das Problem. Aber bei manchen platzt einem
halt irgendwann der Kragen, v.a. dann, wenn solche "Experten"
Anfänger verunsichern... Werde auch net mehr füttern, versprochen;-)

Zum Thema akzeptable Fehlerrate.
Die hängt auch immer mit der Bitanzahl zusammen.
1 Start + 4 Datenbit sind halt erheblich toleranter als
1 Start + 9 Datenbit + 1 Paritybit
Weil mir die Liste jetzt zu aufwendig ist verweise ich einfach mal auf
das ATMega16 Datenblatt
http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf
Schaut dort mal auf Seite 161 in die Tabellen 61 und 62.

Und dann sollte man noch beachten, das es durchaus unterschiedlich gute
Taktgeber gibt (Stichwort Resonatoren usw.)

cu
Hauke

>1 Start + 4 Datenbit sind halt erheblich toleranter als
>1 Start + 9 Datenbit + 1 Paritybit

Wieso?

was habt ihr? ich hab recht, nur halt etwas "provozierend" gesagt.
aber wie es in wald hinein schallt, so kommt es auch wieder herraus!

Es gibt übrigens noch einen anderen guten Grund für Baudratenquarze, der
bisher nicht aufgeführt wurde:

Man kann nämlich die Baudratenquarzfrequenzen per fortgesetzter Teilung
durch 2 soweit reduzieren, dass man schließlich mit einem einfachen
8Bit-Timer einen glatten Sekundentakt erzeugen kann. Das gilt auch für
die Frequenzen, die noch einen Faktor 3 drin haben, z.B. 11,0592MHz,
denn die gehören zu der wohl mit Abstand größten Controllerfamilie
(8048/8051), die als internen Takt den Quarztakt durch 6 verwendet.

Mit einem Quarz mit glatten MHz ist es dagegen braucht man dagegen
immer mindestens einen 16Bit-Timer oder einen frei einstellbaren
Vorteiler, um einen glatten Sekundentakt zu erzeugen (z.B. 1,0MHz / 64
= 15625).

@HanneS
In Deiner Aufstellung sind die "klassischen" 2,4576 und 4,9512MHz
nicht aufgeführt. Gibt es einen besonderen Grund dafür?

Gruß Johannes

Hi,

@Martin Kohler (mkohler)
> 14.7456MHz zu 15MHz sind eine Abweichung von ca. 1.7% in der
> Clockfrequenz.

Diese Abweichung ist aber für den Fehler bei der Baudrate nicht
maßgeblich. Durch die möglichen Teilerwerte ist der Fehler nämlich für
alle Baudraten unterschiedlich und liegt bis 19200 Baud  z. B. unter
0,4 %. Darüber liegt er bei bis zu 2%.

Dieser Quartz wird dann benuetzt wenn der Chip keinen wirklich guten
Baudratenegenerator hat. Es gibt allerdings echte Probleme wenn man
z.B. USB, CAN und einen Chip ohne vernuenftigen Baudratengenerator hat.

USB und CAN haetten gerne sowas wie 12 MHz und 16 MHz und eine kleine
PLL, das ist allerdings nur vertraeglich mit 115200 oder hoeher, wenn
ein sogenannter Fractional Baudrate Generator zur Verfuegung steht. Der
generiert dann unterschiedliche Bitlaengen aber bleibt locker in der
Spezifikation von weniger als 2% Abweichung.
Also solange nur der UART gebraucht wird ist 14.756 ein wunderschoener
Quartz, mit CAN allerdings schiesst man sich in den Fuss damit.

Robert

@Thomas
Sorry, aber das ist nur bedingt richtig, weil von der Größe des jeweils
ohne weitere Pause gesendeten Datenblocks und des jeweiligen Controllers
abhängig. So "klaut" der U(S)ART eines AVR dadurch, dass er zur
Startbiterkennung drei Low-Samples um die Startbitmitte herum braucht,
stets 1/16 (oder 1/8 bei Double-Speed) Bitzeit nach vorne.

Weiterhin spielt die absolute Genauigkeit des Quarzes eine Rolle
sowie seine Temperaturdrift (typische Computerquarze sind da nicht
so genau). Und wenn tatsächlich gar kein Quarz, sondern ein
Keramikresonator den Clock macht, sind gleich lockere 0,5%
Grundabweichung und +-0,2 bis 0,3% Temperaturdrift drin.

Und schließlich ist noch eine wichtige Frage, ob eine RS232-Verbindung
(Punkt-zu-Punkt) oder ein halbduplex RS485-Bus vorliegt.

Von oben nach unten werden immer größere Anforderungen an die
Synchronisierung gestellt, die praktisch nur durch eine angemessene
Verlängerung des Stopbits aufgefangen werden können. Es hat schon
seinen Sinn, dass sich das gute alte Telex nie mit nur einem einzigen
Stopbit zufrieden gegeben hat, sondern mindestens 1,5 Bitzeiten dafür
verlangt. Und auf einem RS485-Bus soll sogar jeder Sender erstmal mehr
als eine Bytezeit Dauerhigh ver(sch)wenden, um den/die jeweiligen
Empfänger aus dem möglichen Dauerlow (=Break) aufwachen zu lassen...

@HanneS
Ich hab den Eindruck, dass ich Dir irgendwie (zu?) nahe getreten bin.
Tut mir leid, das war nicht meine Absicht.

Gruß Johannes

Vielleicht noch ein nützlicher Hinweis?!?
Mit dem Codevision Code Wizard kann man die Frequenz und die Baudrate
angeben und man kriegt den Fehler in Prozent angezeigt.
Dann muß man nicht selber rechnen oder in Tabellen schauen.
Sollte auch mit der kostenlosen Eval Version funktionieren?!?

Ist doch auch kein Wunder. Warum sollte man auch dasselbe immer und
immer wieder schreiben? Der Sachverhalt ist doch auch recht einfach.
Wenn man möglichst genaue Taktraten haben will, dann nutzt man eben die
krummen Quarze. Klar geht es auch mit fast beliebigen anderen Quarzen
aber da verlässt man sich dann wohl sehr darauf dass das Gegengerät
eben fehlertolerant genug ist, was es ja in vielen Fällen auch ist. Im
Zusammenspiel mit nem PC gibts ja auch selten Schwierigkeiten aber wenn
man z.B. an irgendwelche Industriemaschinen ran muss, sieht das manchmal
schon ganz anders aus. Soll das doch Jeder machen wie er will, Er wird
schon feststellen ob es funktioniert oder eben nicht.

bye

Frank

>Er wird schon feststellen ob es funktioniert oder eben nicht

Das schon, aber wenn es darum geht, warum es nicht geht, dann ist das
Geheule im Forum groß.
Es wird aber niemand gezwungen, auf irgendwelche Threads zu antworten.
Am besten finde ich in solchen Fällen immer, wenn jemand aus einem
Ingenieurbüro seine Meinung vertritt, dass der interne RC-Oszillator
für solche Sachen genau genug sei...

>>> 14.7456MHz zu 15MHz sind eine Abweichung von ca. 1.7% in der
>>> Clockfrequenz.
>> Diese Abweichung ist aber für den Fehler bei der Baudrate nicht
>> maßgeblich.
> Sorry, aber das ist nur bedingt richtig, weil von der Größe des
> jeweils ohne weitere Pause gesendeten Datenblocks und des ...

Die Abweichung zwischen zwei Quarzen ist nicht allein das entscheidende
Kriterium für die Abweichung der Baudrate. Die Abweichung kommt im
wesentlichen durch die nur diskret möglichen Teilerwerte der folgenden
Teilerkette zustande. Diese Aussage ist richtig und hat mit allen
weiteren von dir aufgezählten Fehlerquellen absolut noch gar nichts zu
tun.

Fakt ist, dass z. B. mit einem AVR und dem darin befindlichen Teiler
bei 15 MHz und 19200 Baud ein reiner Baudratenfehler von etwas unter
0,4 % zustande kommt und das dieser Wert offensichtlich unterschiedlich
zu den 1,7 % Abweichung der nominalen Quarzfrequenzen ist, muss doch
nicht weiter belegt werden. Das hat mit Datenblöcken, Temperaturdrift
und Erdstrahlen noch nichts zu tun...

Gruß, Thomas

Fakt ist nunmal,das man mit dem internen R/C-Osszillator und etwas
Handtuning am UBR mit jedem AVR eine Übertragung mit 9600 Baud zum
laufen bekommt.Und wenn sich die Erfahrung auf 1x am STK500 rumspielen
beschränkt,erscheint das als eine brauchbare Lösung.

Und genau diese Leute fangen dann an wild herum zuraten,wenn sie die
selbe Software auf einen anderen AVR flashen und es dann nicht
funktioniert.("Ist doch selbe Hardware und selbe Software,ist mein AVR
kaputt?")

Ich finde Hannes-Seite ist gut gemacht und prima zum lernen
geeignet.Wer keine Hilfe annehmen will,ist dann selber schuld wenn er
es sich schwerer als nötig macht.

Nur bevor man dann anderen derartige Halbwarheiten in einem Forum
übermittelt,sollte man vielleicht erstmal einige Erfahrungen mit
konkreter Hardware sammeln.

>sollte man vielleicht erstmal einige Erfahrungen mit
>konkreter Hardware sammeln.

Wann ist das der Zeitpunkt?

>1x am STK500 rumspielen

Da betrachten sich manche schon als Experten...

Es wird immer Leute geben, die es "besser" wissen. Denen muß man dann
gelegentlich entgegen wirken (manchmal gehöre ich auch dazu...).
Manche begreifen es dann, andere darf man dann als "Troll"
betrachten...
Prometeus lässt grüssen...

Yep, wenn du einen genauen Takt als Referenz hast, ist der RC-Osz
problemlos verwendbar, weil sich der dann im Betrieb automatisch
kalibieren lässt.

Ja, klasse, das werd ich mal meinem Chef und dem nächsten Kunden
vorschlagen: "Leute, nehmt einfach irgendeinen Keulen-AVR mit zweitem
Oszillator und einen Uhrenquarz, dann kriegen wir immer einen sauberen
Baudratentakt hin... Zugegeben, die benötigen >8 MHz für die CPU sind
dann nicht drin, und mit dem angepeilten Tiny kommen wir auch nicht
hin, aber wir haben immerhin eine halbe Lösung zum doppelten Preis!"

Ist doch auch was, oder?

Ich höre schon den Applaus für diese geniale Idee...

Detlef, welche Idee meinst Du?

Die, mit der man den internen Calibrated-RC-Clock hinreichend genau für
einen sowohl Baudrate- als auch Sekundentakt auf >16MHz zwiebeln kann?
Und das nicht nur mit dem Mega169 des Butterfly, sondern auch mit
einem, sagen wir, Tiny2313?

Die hab ich tatsächlich nicht begriffen. Sag sie mir!

Ebenfalls Gute Nacht
Johannes

>Re: Wofür braucht man 14.7456 Mhz Quarz?

Mancheiner baut daraus eine Spange oder Brosche für seine Frau/Freundin
(oder beide).

@Johannes: Das könnte was mit dem Stromverbrauch zu tun haben...
James Krüss: Dann entsteht zwar ein Gedicht, aber sinnvoll ist es
nicht...

@Johannes: Ich habe nur erklärt, warum das beim Butterfly funktioniert.
Dessen 32KHz-Takt dient ja nicht in erster Linie dem Abgleich der
Baudrate, sondern weil darin permanent eine Uhr auf Batterie läuft und
der Power-Save Mode der Weg des minimalem Stromverbrauchs ist.
Unterhalb vom Mega8 geht das mangels zweiten Osziallators sowieso
nicht.

Ich denke, man sollte die 2% Reserven auf die der serielle Bus meist
spezifiziert ist nicht daruch aufgeben, daß man die Grundfrequenz
einseitig in die Ecke fährt. Gerade in Controllern kommt ja auch noch
die dynamische Reaktion auf Interrupts hinzu, sodaß man da einen
Abtast-Jitter erhält und schon mal rasch aus dem Fenster rutscht.

@Jürgen: Der Jitter tritt nur bei Software-UART in Erscheinung, und auch
nur wenn nicht ein USI oder so dabei mithilft.