Atmega8: was spricht gegen den internen Takt?

z.B. UART bzw. RS232 und Verwandte.

Falls dir das ja zu ungenau war, auch wenn es die Frage korrekt 
beantwortet hat.

Kommt halt sehr auf die Anwendung an, wenn man nur zwei LEDs abwechselnt 
blinken lassen will, reicht der interne Takt.
Will man sie genau im sekundentakt blinken lassen, reicht er eben nicht.

Beim UART ist es genau so, wenn du Glück hast gehts, wenn nicht dann 
gehts eben nicht. Was meistens der Fall sein wird.

Stephan R. schrieb:
> Das heisst, Essig ohne externen Takt?
Du kannst bei der seriellen Schnitte mit ein wenig Aufwand (z.B. 
Autobaud) viel erreichen. Aber bei Zeitmessung (Uhr) wirds dann wieder 
kritisch... :-/

> Schade aber auch gut.
Na gut.

Klaus Wachtler schrieb:
> z.B. UART bzw. RS232 und Verwandte.

Muss nicht sein.  Für "Bürobedingungen" (einigermaßen konstante
Betriebsspannung und Umgebungstemperatur) sind die RC-Oszillatoren
der neueren AVRs allemal RS-232-tauglich, d. h. die ±2 % erreichen
sie typisch (jedoch nicht per Datenblatt garantiert).

Dennoch gibt es natürlich Dinge, für die der RC-Oszillator ungeeignet
ist.  Zeitmessung war ja schon genannt, USB (egal ob durch Software
oder Hardware) ist ebenfalls ein Kandidat.

Wenn man eine externe, genaue Zeitreferenz hat, wie zum Beispiel eine 
RS232-Verbindung, dann kann man den internen Oszillator in 
~0.5%-Schritten nachstimmen. Dies erreicht man, indem man die ankommende 
Bytelaufzeit mit einem Timerwert in´s Verhältnis setzt und den 
erhaltenen Regelwert aufbereitet und in das OSCCAL-Register einträgt. 
Dazu gibt es auch AppNotes bei ATMEL.

> USB (egal ob durch Software oder Hardware) ist ebenfalls ein Kandidat.
Geht nicht gibts nicht:
http://www.sparkfun.com/commerce/product_info.php?products_id=9147
Das ist eine USB-Tastatur mit internem Oszillator

Peter schrieb:
>> wie zum Beispiel eine RS232-Verbindung
> in der Hoffnung das das andere Gerät nicht selbst nur ein RC Kreis hat.
> Und sich dann beide Geräte auf einander verlassen.

Solange es nur um die UART-Übertragung geht: ja und? Dann geht die reale 
Bitrate zwar nach dem Mond, aber wenn sich beide Seiten irgendwie 
darüber einig werden (also beide gleich falsch gehen), ist das egal.

Andreas

Andreas Ferber schrieb:
> Solange es nur um die UART-Übertragung geht: ja und?
Nur, was ist, wenn der eine +2% hat und der andere -2%... :-o

Lothar Miller schrieb:
>> Solange es nur um die UART-Übertragung geht: ja und?
> Nur, was ist, wenn der eine +2% hat und der andere -2%... :-o

Hast du doch selbst geschrieben, Autobaud. Die gleichen sich halt 
aneinander an, aber ob da dann statt 9600 Baud nominal am Ende 9423 Baud 
real rauskommen, wenn beide Seiten mit einem ungenauen Oszillator 
laufen, ist egal.

Andreas

Lothar Miller schrieb:
>> USB (egal ob durch Software oder Hardware) ist ebenfalls ein Kandidat.
> Geht nicht gibts nicht:
> http://www.sparkfun.com/commerce/product_info.php?products_id=9147
> Das ist eine USB-Tastatur mit internem Oszillator

OK, ich hatte nur den Wert für Fullspeed in Erinnerung (±0,25 %),
den kann man mit dem RC-Oszillator eines AVR prinzipbedingt selbst
bei Kalibrierung nicht erreichen, denn die Kalibrierung lässt sich
nur in (ungefähr) 0,5-%-Schritten einstellen.  Bei lowspeed hat
man in der Tat etwas mehr Reserve, da nur ±1,5 % gefordert sind.
Das ist nicht viel strenger als RS-232.