www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega 8: ohne Quarz usw. - nur mit int. Oszilator?


Autor: Jürgen M. (jmayer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

Reicht es wenn man bei einem Atmega 8 einfach die komplette 
Quarzbeschaltung an Pin 9 und 10 (XTAL1 und XTAL2) weglässt und die Fuse 
für int. RC-Osszilator setzt?

Muss man sonst noch was für eine solche Minimalbeschaltung beachten?

Gruss
Jürgen

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Muss man sonst noch was für eine solche Minimalbeschaltung beachten?

Ja:

Du kannst dann keine Uhr mehr bauen. Naja, kannst du schon,
aber die läuft nicht besonders genau.
RS232 funktioniert mal, und mal nicht.

Alles was mit präzisem Timing zu tun hat
kannst du vergessen.

Für ein paar blinkende LEDs reicht der interne RC.

Autor: Jürgen M. (jmayer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger wrote:

> Du kannst dann keine Uhr mehr bauen. Naja, kannst du schon,
> aber die läuft nicht besonders genau.

für die Applikation ( eine Rolladensteuerung ) ist das egal.

> RS232 funktioniert mal, und mal nicht.

aha - das hätte ich nicht gedacht. Gibt es dieses Problem auch bei 
niedrigen Baudraten?

Gruss
Jürgen

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Mayer wrote:
>> RS232 funktioniert mal, und mal nicht.
>
> aha - das hätte ich nicht gedacht. Gibt es dieses Problem auch bei
> niedrigen Baudraten?
>
> Gruss
> Jürgen

Bei 2400 Baud sollte es eigentlich auch mit internem OSC gehen...
Hatte es auch schon mit 4800 am laufen.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. wrote:
> Bei 2400 Baud sollte es eigentlich auch mit internem OSC gehen...
Ob es klappt oder nicht hat zunächst nichts mit der Höhe der Baudrate 
zu tun! Es kommt darauf an, wie genau sich eine bestimmte Baudrate mit 
der vorhandenen Taktfrequenz darstellen lässt. Es kann durchaus 
vorkommen, dass eine höhere Baudrate mit geringerer Abweichung erzeugbar 
ist als eine bestimmte geringere. Die prozentuale Abweichung sollte für 
eine sichere Übertragung unter 2 % liegen. Das größere Problem mit den 
RC-Oszillatoren v.a. der älteren AVRs ist aber der Temperaturgang. Es 
kann durchaus sein, dass eine Übertragung bei 20 °C funktioniert, bei 25 
°C aber schon nicht mehr. Bei neueren AVRs soll die Temperaturdrift der 
Oszillatoren allerdings geringer sein.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tim T. (tim_taylor)

>Bei 2400 Baud sollte es eigentlich auch mit internem OSC gehen...
>Hatte es auch schon mit 4800 am laufen.

NEIN! Siehe

AVR-Tutorial: UART

MfG
Falk

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Euch beide:

Ach Leute, schaut doch mal ins Datenblatt des ATMega8 Seite 159ff und 
sagt mir, bei welchen Frequenzen, die der Interne OSC erzeugen kann, die 
Fehlerrate  für 2400/4800Baud bei 0,2% oder weniger liegt.
Genau bei allen.

Das was jetzt noch für ein Problem sorgt, ist wie Johannes richtig sagt 
die Temperaturabhänigkeit und die damit einhergehende Ungenauigkeit des 
internen OSC. Welche sich aber logischerweise bei geringen Baudraten 
weniger stark auswirkt...

Und @Falk:
Wäre nett wenn du mir überlassen würdest was bei mir funktioniert hat 
und was nicht...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tim T. (tim_taylor)

>Ach Leute, schaut doch mal ins Datenblatt des ATMega8 Seite 159ff und
>sagt mir, bei welchen Frequenzen, die der Interne OSC erzeugen kann, die
>Fehlerrate  für 2400/4800Baud bei 0,2% oder weniger liegt.
>Genau bei allen.

FALSCH! Du verwechselst zwei Fehlermechanismen.

- Baudratenfehler durch nichtganzzahlige Teilung des Oszillators 
(Tabelle im Datenblatt)
- Baudratenfehler durch Frequenzfehler des Oszillators (ist im 
Datenblatt Kapitel UART NICHT berücksichtigt)

>Das was jetzt noch für ein Problem sorgt, ist wie Johannes richtig sagt
>die Temperaturabhänigkeit und die damit einhergehende Ungenauigkeit des
>internen OSC. Welche sich aber logischerweise bei geringen Baudraten
>weniger stark auswirkt...

Mit dem Dreisatz hast du's aber nicht besonders? 3% Fehler sind drei 
Prozent Fehler! Bei JEDER Baudrate. Denn dein 8 MHz RC-Oszillatortakt 
ist nicht 8 MHz, sondern 8MHz +/- 5%.

>Und @Falk:
>Wäre nett wenn du mir überlassen würdest was bei mir funktioniert hat
>und was nicht...

Du hast es nicht verstanden. Wie viele andere Dinge. Es KANN 
funktionieren, wenn der Oszillator zufällig (Produktionstoleranz) einen 
kleinen Fehler hat. Es ist aber keinesfalls garantiert. Die Zahl der 
Hilferufe hier "mein UART geht nicht" ist gigantisch. Ein Quarz hat 
garantiert max. +/-100ppm Fehler.

MfG
Falk


MfG
Falk

Autor: 6632 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz Nebenbei. Die Streuung der OSCCAL Werte ist gigantisch. Man kann 
daher nicht fuer ein Exemplar die Baudrate ueber OSCCAL einstellen und 
dann auf die Serie duplizieren. Zumindest muss man beim Brennen 
kalibrieren, wenn die Temperatur und die Spannung schon nicht 
interessiert.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>
> FALSCH! Du verwechselst zwei Fehlermechanismen.
>
> - Baudratenfehler durch nichtganzzahlige Teilung des Oszillators
> (Tabelle im Datenblatt)
Wurde in Johannes Post angeführt.

> - Baudratenfehler durch Frequenzfehler des Oszillators (ist im
> Datenblatt Kapitel UART NICHT berücksichtigt)
S.u.

> Mit dem Dreisatz hast du's aber nicht besonders? 3% Fehler sind drei
> Prozent Fehler! Bei JEDER Baudrate. Denn dein 8 MHz RC-Oszillatortakt
> ist nicht 8 MHz, sondern 8MHz +/- 5%.
Ja und scheint bei dir besonders schwer zu werden wenns von Prozenten 
auf absolute Werte geht. Denk mal drüber nach welche zeitliche 
Abweichung ein Signal bei +5% Fehler auf 2400Baud bedeutet.

> Du hast es nicht verstanden. Wie viele andere Dinge. Es *KANN*
> funktionieren, wenn der Oszillator zufällig (Produktionstoleranz) einen
> kleinen Fehler hat. Es ist aber keinesfalls garantiert. Die Zahl der
> Hilferufe hier "mein UART geht nicht" ist gigantisch. Ein Quarz hat
> garantiert max. +/-100ppm Fehler.
Vorab mir ist schon klar das du keinen Bock drauf hast wieder 1000. 
Postings zu dem Thema durchzulesen, allerdings hatte ich geschrieben 
"sollte" und "hat auch schonmal".
Meine Bilanz dafür: Von 3 Mikrocontrollern die ich mit internem OSC und 
RS232 getestet habe, haben es 3 geschafft (2*Mega16, 1*Mega32). Bis 
diese (meine) Statistik nicht einen Dämpfer bekommt werde ich auch 
weiterhin behaupten das es bei niedrigen Baudraten gehen sollte. Btw. 
bei 19200 gings  trotz 0,2% (rechnerischer Abweichung) bei keinem mehr 
fehlerfrei.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
6632 wrote:
> Ganz Nebenbei. Die Streuung der OSCCAL Werte ist gigantisch. Man kann
> daher nicht fuer ein Exemplar die Baudrate ueber OSCCAL einstellen und
> dann auf die Serie duplizieren. Zumindest muss man beim Brennen
> kalibrieren, wenn die Temperatur und die Spannung schon nicht
> interessiert.

Du wirst wohl das Ding kalibrieren müssen und ohne Spannungsregler kann 
mans auch vergessen, sollte aber klar sein.

PS: In welchen Temperaturbereichen betreibt ihr eure Controller? Die 
meisten die ich benutze stehen irgendwelchen Räumen mit ~23°C, und sogar 
alle die eine RS232 haben...

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also meine AVRs mit internem Oszi. laufen auch alle mit UART, sogar bei 
weit höheren Baudraten. Allerdings! sind alle meine UART Protokolle 
ausgehend vom PC so konstruiert das dieser PC erstmal par 
Synchronisierungsbytes aussendet. An hand derer wird die aktuelle 
Baudrate im AVR berechnet und entsprechend kalibriert. Sogesehen: der 
AVR mit internen Oszi. läuft mit UART problemlos (bei mir ;), wenn man 
berücksichtigt das das UART protokoll so angepasst wurde das der AVR 
sich kalibrieren kann.

Gruß Hagen

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. wrote:

> Ja und scheint bei dir besonders schwer zu werden wenns von Prozenten
> auf absolute Werte geht. Denk mal drüber nach welche zeitliche
> Abweichung ein Signal bei +5% Fehler auf 2400Baud bedeutet.

2400Hz = 416µs. 5% davon = 21µs. Synchronisiert wird beim Startbit, 
darauf folgen 9 unsynchronisierte Bits, jedes davon mit 21µs Fehler, 
ergibt hinten einen kumulierten Zeitfehler von 9*21=188µs. Das ist fast 
die halbe Bitzeit, also wird gegen Ende eines Bytes der Zustand ungefähr 
zu dem Zeitpunkt gesampelt, wo der Transmitter bereits zum nächsten Bit 
wechselt, und nicht mehr ungefähr in der Mitte dazwischen.

Diese Rechnung funktioniert analog bei jeder Bitrate gleich, 5% 
Baudratenfehler entsprechen >40% Phasenverschiebung bei letzten Bit.

Von der absolute Frequenz abhängig ist nur der Effekt, der durch die 
absolute Verzögerung der RS232-Transceivern entsteht.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. wrote:
> Ja und scheint bei dir besonders schwer zu werden wenns von Prozenten
> auf absolute Werte geht. Denk mal drüber nach welche zeitliche
> Abweichung ein Signal bei +5% Fehler auf 2400Baud bedeutet.
Ja, eine Übertragung mit 5% höherer Frequenz bedeutet, dass der Frame um 
5% schneller übertragen wird. Abgesehen davon, dass die absolute 
Abweichung bei niedrigen Frequenzen noch größer ist als bei höheren 
Frequenzen, spielt das keine Rolle. Sobald die Abweichung so groß ist, 
dass eine Flanke falsch zugeordnet wird, kommt Müll raus, und zwar 
(weitestgehend) frequenzunabhängig! Erst bei ziemlich hohen Baudraten 
spielen Schaltverzögerungen u.ä. eine relevante Rolle.

EDIT:
Andreas, Du sagst es...

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> 2400Hz = 416µs. 5% davon = 21µs. Synchronisiert wird beim Startbit,
> darauf folgen 9 unsynchronisierte Bits, jedes davon mit 21µs Fehler,
> ergibt hinten einen kumulierten Zeitfehler von 9*21=188µs. Das ist fast
> die halbe Bitzeit, also wird gegen Ende eines Bytes der Zustand ungefähr
> zu dem Zeitpunkt gesampelt, wo der Transmitter bereits zum nächsten Bit
> wechselt, und nicht mehr ungefähr in der Mitte dazwischen.
>
> Diese Rechnung funktioniert analog bei jeder Bitrate gleich, 5%
> Baudratenfehler entsprechen >40% Phasenverschiebung bei letzten Bit.
>
> Von der absolute Frequenz abhängig ist nur der Effekt, der durch die
> absolute Verzögerung der RS232-Transceivern entsteht.

Hmm, die Argumentation leuchtet 100% ein, nur hab ich jetzt ein 
Problem...
Warum bekomme ich 2400 Baud Kommunikation relativ Problemlos hin und 
19200er nicht?
Bisher habe ich es mir immer damit erklärt das bei höheren Baudraten die 
Signalflanken weniger steil laufen und man damit halt zum 
Triggerzeitpunkt etwas zu spät ankommt. Allerdings wenn ich recht 
überlege ist 19200 noch nicht so schnell das es deshalb passiert oder?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tim T. (tim_taylor)

>Bisher habe ich es mir immer damit erklärt das bei höheren Baudraten die
>Signalflanken weniger steil laufen und man damit halt zum

Wer sagt das? Die Signalflanken sind immer gleich schnell, unabhängig 
von der Baudrate.

>Triggerzeitpunkt etwas zu spät ankommt. Allerdings wenn ich recht
>überlege ist 19200 noch nicht so schnell das es deshalb passiert oder?

Aber dein RC-Oszillator hängt an der Toleranzgrenze + er ist relativ 
instabil. Sprich, die  Frequenz schwankt in sehr kurzer Zeit (einige 
Millisekunden) um +/-1 % meinetwegen. Damit verhaut er des öfteren das 
Timing bei 19200. Lass mal den Takt auf ein IO-Pin ausgeben und miss mal 
mit einem Frequenzzähler. Der Wert wird a) um einige Prozent dabenen 
liegen und b) relativ stark schwanken.
Und dann mach das nochmal mit einem Quarz.

MfG
Falk

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Tim T. (tim_taylor)
>
>>Bisher habe ich es mir immer damit erklärt das bei höheren Baudraten die
>>Signalflanken weniger steil laufen und man damit halt zum
>
> Wer sagt das? Die Signalflanken sind immer gleich schnell, unabhängig
> von der Baudrate.
>
Ok, waren wieder 2 Schritte: Ich dachte an parasitäre Effekte 
(Kapazitäten) die bei höheren Geschwindigkeiten da zu stärkeren 
Verformungen führen.

>>Triggerzeitpunkt etwas zu spät ankommt. Allerdings wenn ich recht
>>überlege ist 19200 noch nicht so schnell das es deshalb passiert oder?
>
> Aber dein RC-Oszillator hängt an der Toleranzgrenze + er ist relativ
> instabil. Sprich, die  Frequenz schwankt in sehr kurzer Zeit (einige
> Millisekunden) um +/-1 % meinetwegen. Damit verhaut er des öfteren das
> Timing bei 19200. Lass mal den Takt auf ein IO-Pin ausgeben und miss mal
> mit einem Frequenzzähler. Der Wert wird a) um einige Prozent dabenen
> liegen und b) relativ stark schwanken.
> Und dann mach das nochmal mit einem Quarz.
Wenn ich meine Tastköpfe finde werde ich nochmal mein Oszi dranhängen.
Meine aber genau das schon gemacht zu haben mit dem Resultat das er zwar 
eine kleine Abweichung hat (~1%) diese aber relativ konstant ist und 
sich nicht oder nur sehr sehr wenig ändert, im Messzeitraum zumindest.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tim T. (tim_taylor)

>Wenn ich meine Tastköpfe finde werde ich nochmal mein Oszi dranhängen.

Das nützt wenig bis nichts. Die Grössenordnung sieht man auf einem Oszi 
nicht (ohne weiteres). OK, geht doch, wenn der Trigger was taugt.
Triggere auf die Fallende Flanke vom Start-Bit, verschiebe die 
Bildschirmmitte af die steigende Flanke vom Stop-Bit. jetzt dreh die 
Zeitauflösung hoch, sagen wir 50ns/DIV. Und dann schau mal RC gegen 
Quarz.

>Meine aber genau das schon gemacht zu haben mit dem Resultat das er zwar
>eine kleine Abweichung hat (~1%) diese aber relativ konstant ist und
>sich nicht oder nur sehr sehr wenig ändert, im Messzeitraum zumindest.

Vor allem bei ziemlich konsatanter Temperatur.

MfG
Falk

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute wenn man Euch manchmal diskutieren sieht... schon lustig ;) Wir 
halten fest: UART mit internem Oszillator nicht verwendbar. Was ist 
daran jetzt so schwer zu verstehen?

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:
> Leute wenn man Euch manchmal diskutieren sieht... schon lustig ;) Wir
> halten fest: UART mit internem Oszillator nicht verwendbar. Was ist
> daran jetzt so schwer zu verstehen?

Das die Allgemeingültigkeit dieser Aussage nicht gegeben ist.

Btw: Hab grade was im Datenblatt des ATmega16 auf Seite 29 gefunden:

"At 5V, 25°C and 1.0, 2.0, 4.0 or 8.0 MHz Oscillator frequency selected, 
this calibration gives a frequency within ± 3% of the nominal frequency.
Using calibration methods as described in application notes available at
www.atmel.com/avr it is possible to achieve ±1% accuracy at any given 
VCC and Temperature."

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tim T. (tim_taylor)

>> Leute wenn man Euch manchmal diskutieren sieht... schon lustig ;) Wir
>> halten fest: UART mit internem Oszillator nicht verwendbar. Was ist
>> daran jetzt so schwer zu verstehen?

>Das die Allgemeingültigkeit dieser Aussage nicht gegeben ist.

Wie wäre es damit.

"Für den stabilen, sicheren und einfachen Betrieb eines UARTs muss ein 
Quarz bzw. Quarzoszillator verwendet werden. Soll der UART mit dem 
internen RC-Oszillator betrieben werden, muss

- Die Versorgungsspannung sehr stabil sein (wird durch die meisten 
Spannungsregler erreicht)
- dieser mind. einmalig kalibiert werden
- bei sich ändernder Temperatur zyklisch kalibriert werden

Zu beachten ist, dass die Kalibrierung im AVR per OSCCAL nicht sehr fein 
möglich ist, und somit bisweilen die enge Toleranz des UARTs von +/-3% 
nur schwer erreichbar ist.
"

Damit sollte nun aber wirklich ALLES gesagt sein.

MfG
Falk

Autor: Netbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G:
> Leute wenn man Euch manchmal diskutieren sieht... schon lustig ;) Wir
> halten fest: UART mit internem Oszillator nicht verwendbar. Was ist
> daran jetzt so schwer zu verstehen?

Manche hier sind einfach zu theoretisch! Probiert's doch aus so wie Tim 
T.!
Er schrieb:
> Meine Bilanz dafür: Von 3 Mikrocontrollern die ich mit internem OSC und
> RS232 getestet habe, haben es 3 geschafft (2*Mega16, 1*Mega32). Bis
> diese (meine) Statistik nicht einen Dämpfer bekommt werde ich auch
> weiterhin behaupten das es bei niedrigen Baudraten gehen sollte.

Meine Bilanz - auch wenn es den Theoretikern schwerfallen mag, das zu 
glauben- : Mit 2400 Baud funktionierten Mega 8 und Mega 16 mit 1MHz so 
wie aus der Fabrik geliefert ohne jedes Problem und ohne Kalibrierung 
und PiPaPo! (Insgesamt etwa 5 MC, habe aber nicht Buch geführt :-) )

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Netbird (Gast)

>glauben- : Mit 2400 Baud funktionierten Mega 8 und Mega 16 mit 1MHz so
>wie aus der Fabrik geliefert ohne jedes Problem und ohne Kalibrierung
>und PiPaPo! (Insgesamt etwa 5 MC, habe aber nicht Buch geführt :-) )

FALSCH! Deine 5 aus DIESER Produktionseinheit und bei DER gerade 
herschenden Temperatur. Allgemein gilt das keinesfalls.

MfG
Falk

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der UART Betrieb ab RC ist gut moeglich wenn man eine Referenzfrequenz 
hat. Die Abstufung der OSCCAL ist auch fein genug. Entgegen den Atmel 
appnotes, die fuer eine Kalibration 300 byte benoetigen, hab ich eine 
mit 60 byte geschrieben. Dabei wird wie bei Atmel der 32kHz Quarz 
verwendet.
http://www.ibrtses.com/embedded/avrosccal.html

Autor: Netbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die erste Frage von Jürgen Mayer zu diesem Thema lautete:
> ... Muss man sonst noch was für eine solche Minimalbeschaltung beachten?

@Falk und @Michael G.:
Könntet Ihr folgende Antwort akzeptieren?

Theoretisch könnte es Probleme mit der Genauigkeit geben, muss es aber 
bei z.B. 2400 Baud nicht, wie die Erfahrungen einiger hier zeigen. 
Probier's einfach aus!

Ich gehe davon aus, dass für Serien-Produzenten für professionellen 
Gebrauch eine andere Antwort angemessen wäre (die hätten die Frage aber 
wohl auch nicht so gestellt).

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Netbird (Gast)

>Könntet Ihr folgende Antwort akzeptieren?

NEIN! Und warum das so ist, haben wir tausendmal erklärt. Was zum Geier 
ist so schlimm an einem Quarz?.

MfG
Falk

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
jetzt muß ich doch auch mal meinen Senf an die Quarz-Nichtbenutzer dazu 
geben ;-)

a) Ein Quartz kostet bei elpro z.B. 39 cents

b) Eine Schaltung mit einem Quartz ist nachbausicher, wenn ein UART 
verwendet werden soll. Ich lese hier ständig: Hiilfeee, mein UART geht 
nicht. Da hat natürlich viele Ursachen, aber diese (RC-Toleranzen) kann 
man dann zumindest mal ausschließen.
Wenn ich das in meiner Stube mache und imstande bin, eine Fehlerursache 
für schlechte Terminalverbindungen zu meinem MC zu finden, dann kann ich 
das ohne Quartz am MC tun. Es ist mir aber 39 cents Wert, das zu lassen.

c) Ein Theoretiker denkt vorher, baut und es funktioniert. Ein Praktiker 
baut, denkt (hoffentlich) und probiert bis es funktioniert. Frage: Was 
geht schneller (und ist billiger) ?

d) Es ist ein Unterschied, ob etwas funktionieren kann oder muß.

e) so, und jetzt sag ich nichts mehr dazu ;-)

Gruß
Andy

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andy wrote:
> Hallo,
> jetzt muß ich doch auch mal meinen Senf an die Quarz-Nichtbenutzer dazu
> geben ;-)
>
> a) Ein Quartz kostet bei elpro z.B. 39 cents
Hab mir grade gestern welche bei Angelika für 24 ct bestellt.

> b) Eine Schaltung mit einem Quartz ist nachbausicher, wenn ein UART
> verwendet werden soll. Ich lese hier ständig: Hiilfeee, mein UART geht
> nicht. Da hat natürlich viele Ursachen, aber diese (RC-Toleranzen) kann
> man dann zumindest mal ausschließen.
Schau dir mal an was hier teilweise abgeht, da gehört sowas noch zu den 
anpruchsvolleren Sachen, die Fehler sind doch meistens einfacherer Art, 
bei UART fallen mir direkt zu großer Fehler der Baudrate, falsche 
Kondensatoren am MAX und falsche Beschaltung desselben ein.

> Wenn ich das in meiner Stube mache und imstande bin, eine Fehlerursache
> für schlechte Terminalverbindungen zu meinem MC zu finden, dann kann ich
> das ohne Quartz am MC tun. Es ist mir aber 39 cents Wert, das zu lassen.
Wieviele basteln wohl hier hauptsächlich am heimischen 
Schreibtisch/Werkbank?
Alle die nicht in der Lage sind die Fehlerursache zu finden sollen halt 
einen Quarz benutzen, wie es ja auch im Tutorial empfohlen wird. 
Generell sage ich ja auch nix gegen nen Quarz, ich bau den eh immer ein 
auch wenn 2 Pins manchmal nett wären, wenn du über 8 MHz willst ist es 
eh entschieden. Nur wenn jemand partout behauptet es würde nicht gehen, 
geht mir die Hutschnur hoch, weil ich nunmal weis das es geht (bei mir 
zumindest)...

> c) Ein Theoretiker denkt vorher, baut und es funktioniert. Ein Praktiker
> baut, denkt (hoffentlich) und probiert bis es funktioniert. Frage: Was
> geht schneller (und ist billiger) ?
Woher glaubst Du bezieht der Theoretiker sein Wissen? Er wird es wohl 
irgendwann mal getestet haben, wenn nicht übernimmt er einfach eine 
Aussage  ungeachtet dessen Wahrheitswert.
Die ersten UART Bastelversuche hatte ich auch mit Quarz gemacht und es 
hat auf anhieb geklappt. Dann kam irgendwann die Frage auf ob der 
Interne OSC das wirklich nicht gebacken bekommt, also ausprobiert und 
auch das lief auf anhieb, jedenfalls bei niedrigen Baudraten. Ich bin 
der Meinung das mir das mehr gebracht hat als einfach die Aussage aus 
dem Tutorial zu übernehmen das der interne OSC zu ungenau ist.

> d) Es ist ein Unterschied, ob etwas funktionieren kann oder muß.
Natürlich. Siehe oben beim heimischen Schreibtisch...

> e) so, und jetzt sag ich nichts mehr dazu ;-)
Ok, ist ja deine Entscheidung.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tim T. (tim_taylor)

>auch das lief auf anhieb, jedenfalls bei niedrigen Baudraten. Ich bin
>der Meinung das mir das mehr gebracht hat als einfach die Aussage aus
>dem Tutorial zu übernehmen das der interne OSC zu ungenau ist.

Du hast ne merkwürdige Logik. Ausserdem sagt das Tutorial NICHT, dass es 
nicht geht. Es sagt lediglich, dass es unzuverlässig ist. Und das IST 
so.

MfG
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Netbird (Gast)
>
>>glauben- : Mit 2400 Baud funktionierten Mega 8 und Mega 16 mit 1MHz so
>>wie aus der Fabrik geliefert ohne jedes Problem und ohne Kalibrierung
>>und PiPaPo! (Insgesamt etwa 5 MC, habe aber nicht Buch geführt :-) )
>
> FALSCH! Deine 5 aus DIESER Produktionseinheit und bei DER gerade
> herschenden Temperatur. Allgemein gilt das keinesfalls.
>
> MfG
> Falk

Warum müssen ausgerechnet Leute, die gerade mal 5 UART Schaltungen 
aufgebaut haben eigentlich immer so einen Stuss reden?

Wenn man mal mehrere Schaltungen aufgebaut hat und die Temperatur 
verändert hätte (siehe Falk) dann würde man merken, dass es alles andere 
als stabil ist.

Ich jedenfalls hatte es schon öfters, dass mit internem Oszillator gar 
nix vernünftiges mehr ankam. Und bis man dann mal den Fehler gefunden 
hat, bei dem internen Oszillator, der doch die letzten 99 male 
vernünftig funktioniert hat.

Viel Spässchen!

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @  Tim T. (tim_taylor)
>
>>auch das lief auf anhieb, jedenfalls bei niedrigen Baudraten. Ich bin
>>der Meinung das mir das mehr gebracht hat als einfach die Aussage aus
>>dem Tutorial zu übernehmen das der interne OSC zu ungenau ist.
>
> Du hast ne merkwürdige Logik. Ausserdem sagt das Tutorial NICHT, dass es
> nicht geht. Es sagt lediglich, dass es unzuverlässig ist. Und das IST
> so.
>
> MfG
> Falk

"Auf Grund permanent wiederkehrender Nachfrage sei hier AUSDRÜCKLICH 
darauf hingewiesen, dass bei Verwendung des UART unbedingt ein Quarz 
oder Ouarzoszillator verwendet werden muss! Der interne RC-Oszillator 
der AVRs ist zu ungenau! Damit kann es in Ausnahmefällen funktionieren, 
muss es aber nicht!"

Stimmt, da steht das UNBEDINGT ein Quarz verwendet werden MUSS und das 
der interne RC-Oszillator zu UNGENAU ist.
Bisher hatte ich wohl bei allen Tests Ausnahmefälle, nur ich würde die 
Regel da doch eventuell anders definieren.

@Simon: Das die Temperatur einen Einfluss hat, wurde doch auch nicht 
bestritten. Nur überleg doch mal in welchem Temperaturbereich die 
meisten MC der hier anwesenden Schreibtischtäter betrieben werden...

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich verstehe diese bescheuerten Diskussionen auch nicht, ist echte 
Korrinthen.....ei.

>"Auf Grund permanent wiederkehrender Nachfrage sei hier AUSDRÜCKLICH
>darauf hingewiesen, dass bei Verwendung des UART unbedingt ein Quarz
>oder Ouarzoszillator verwendet werden muss! Der interne RC-Oszillator
>der AVRs ist zu ungenau! Damit kann es in Ausnahmefällen funktionieren,
>muss es aber nicht!"

Diese Aussage ist doch Schwachsinn. Ich benutze den ATMega168 und dessen 
UART und denoch arbeite ich mit int. RC Oszi. Und warum? Weil ich den 
UART im Master-SPI Modus benutze und nicht im RS232 Modus. Ergo: wenn 
man wirklich Korrinthen....en möchte dann muß man auch exakt klarstellen 
um welche Rahmenbedingungen es sich handelt. Kann man diese 
Rahmenbedingungen nicht exakt beschreiben dann sollte man nicht mit 
Absolutismen Andere belehren. Also sowas wie: AUSDRÜCKLICH und unbedingt 
einen Quarz bei Verwendung des UART usw. usw.

Man kann den UART auch als SUART oder Master-SPI benutzen und dann stört 
der RC. Oszi. eben nicht mehr. Man kann auch den RC. Oszi. kalibrieren, 
man könnte sogar mit präzisem Temperatursensor den RC Oszi. nachstellen, 
man könnte auch das UART Protokoll so ändern das der AVR mit einer 
Baudratedetektion arbeitet unabhängig vom eigentlichen Taktsystem, usw. 
usw.

Also ziemlich viele Gegenargumente, die nichts mehr nur mit Theorie oder 
nur Praxis oder mit dem Arbeitstil einer Person zu tuen haben.

Sowas:

>Alles was mit präzisem Timing zu tun hat
>kannst du vergessen.
>Für ein paar blinkende LEDs reicht der interne RC.

Sind solche Absolutismen. Auch mit dem RC Oszi kann man präzises Timing 
machen. Die Frage ist einfach unter welchen Rahmenbedingungen und wie. 
Wenn nämlich die Stabilität des RC Oz in zb. einem Bereich von 10 
Sekunden ausreichend genau ist dann kann ich sehr wohl in einer 
entsprechneden Auflösung die auch ausreichend für die Zielsetzung ist, 
eine Relativmessung per RC Oz durchführen, und habe meine geforderte 
Genauigkeit erreicht. Aus Sicht dieser Zielsetzung definiert sich 
nämlich auch die benötigte Genauigkeit und die ist dann auch 
ausreichend.

Ich behaupte auch das je nach Projektziel der RC Oszillator eben nicht 
ausreicht um par LEDs zum blinken zu bringen. Wenn man nämlich die LEDs 
hoch exakt im Sekundentakt blinken lassen möchte dann reicht die 
Genauigkeit des RC-Oszi. eben nicht mehr aus, dann muß ein Quarz her. 
Also auch hier wieder, je nach Projektziel verändern sich die 
Standpunkte.

Davon abgesehen vertrete ich aber auch die Auffassung das es, wenn man 
mit dem UART und RS232 asynchron kommunizieren möchte, es am einfachsten 
ist einen Baudraten-Quarz zu benutzen. Es stimmt das man sich einiges an 
Fehlerquellen damit beseitigt, aber auch wiederrum einhandeln kann. Ich 
erinnere nur an die Threads bei dem durch falsche Fusebits im 
Zusammenhang mit der Taktung Probleme entstanden.
Andererseits stimmt es aber auch das man bei bekannten 
Rahmenbedingungen, und dazu gehört insbesondere der persönliche Anspruch 
an das Projekt (also Hobby, professionelles Produkt, mal eben testen 
usw.), sehr wohl eine zeitlich gesehen stabile RS232 Kommunikation mit 
dem internen RC Oszi. hinbekommt.

Gruß Hagen

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Alles was mit präzisem Timing zu tun hat
>>kannst du vergessen.
>>Für ein paar blinkende LEDs reicht der interne RC.

>Sind solche Absolutismen. Auch mit dem RC Oszi kann man präzises Timing
>machen.

Na hoffentlich baut keiner einen Igor-Plug USB mit
Int-RC ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  holger (Gast)

>Na hoffentlich baut keiner einen Igor-Plug USB mit
>Int-RC ;)

Warum? LOW Speed USB ist bis +/-2,5% spezifiziert. Oder warens 1,5%?

MfG
Falk

P.S. An die restlichen RC-Jünger. Macht mal Jungs, ihr seid cool.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen wrote:
> Diese Aussage ist doch Schwachsinn. Ich benutze den ATMega168 und dessen
> UART und denoch arbeite ich mit int. RC Oszi. Und warum? Weil ich den
> UART im Master-SPI Modus benutze und nicht im RS232 Modus.
Das USART-Modul der Controllers hat mehrere Betriebsarten, und eine 
davon ist UART. Und UART bedeutet "Universal ASYNCHRONOUS 
Receiver/Transmitter Interface". Und genau um die ASYNCHRONE 
Datenübertragung geht es hier, weshalb die Aussage im Tut ("..., dass 
bei Verwendung des UART unbedingt ein Quarz oder Ouarzoszillator 
verwendet werden muss!") vielleicht in Sachen "muss" ein klein wenig 
übertrieben ist, aber dennoch in der Grundsache völlig korrekt ist.

Wenn Du das USART-Modul im synchronen (USRT) oder Master-SPI-Modus 
betreibst, dann wird es nicht als UART betrieben, weshalb die Aussage 
dann gar nicht zutrifft, auch wenn man noch so viele Korinthen anal in 
die Welt setzt.

Ich denke, es wäre sinnvoller, das Tutorial so zu ändern, dass aus dem 
"muss" eine "dringende Empfehlung zur Verwendung eines Quarzes 
(Baudratenquarz ist in den meisten Anwendungen nicht erforderlich) für 
jegliche Art asynchroner Datenübertragung, insbesondere UART" wird. Mit 
dem Hinweis vielleicht, dass es mit dem internen RC-Oszillator klappen 
kann, aber keineswegs muss, so dass wenigstens die Zahl der Postings 
mit dem Betreff "UART mit internem Oszillator funzt nicht" reduziert 
werden kann. Es bleibt jedem selbst überlassen, es auszuprobieren, aber 
wenigstens wissen Einsteiger dann, wenn es nicht funktioniert, auch, 
woran es liegen könnte.

In diesem Sinne

Gehet hin in Frieden.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>P.S. An die restlichen RC-Jünger. Macht mal Jungs, ihr seid cool.

Sind sie nicht. Die verbreiten den Müll auch noch global ins Netz.

RC Osci und präzises Timing ?
Alleine bei RC Osci bekommt man als halbwegs erfahrener
Elektroniker/Programmierer kalte Füsse.

Jeder der einen RC Osci als präzise Taktquelle
bezeichnet hat nicht alle Tassen im Schrank.

Sorry für die rüde Ansprache, aber das musste sein.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Guete... ;) Das Thema scheint unerschoepflich zu sein. OK ich hab 
ja nich gesagt dass es unmoeglich ist, aber ich persoenlich wuerde nen 
Quarz benutzen, fertig, das vereinfacht die Dinge allgemein, die UART 
ist zickig genug, da brauch ich nicht auch noch 
Temperaturabhaengigkeiten usw. und das nur um die 30ct fuer den Quarz zu 
sparen. Aber Ihr koennt das ja machen, wie ihr wollt.

Michael

Autor: 6632 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie schade, all die Diskussionen nur weil Atmel es noch nicht 
hingekriegt hat. Die PIC RC sind viel enger spezifiziert. Vielleicht 
schafft das Atmel auch mal.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 6632 (Gast)

>Irgendwie schade, all die Diskussionen nur weil Atmel es noch nicht
>hingekriegt hat. Die PIC RC sind viel enger spezifiziert. Vielleicht
>schafft das Atmel auch mal.

Jaja, und morgen kommt der Weihnachtsmann. Die PICs sind da keinen Deut 
besser. Schau dir die Datenblätter GENAU an.

MFG
Falk

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. wrote:

> Woher glaubst Du bezieht der Theoretiker sein Wissen? Er wird es wohl
> irgendwann mal getestet haben, wenn nicht übernimmt er einfach eine
> Aussage  ungeachtet dessen Wahrheitswert.

Es gibt eine dritte Möglichkeit: Herleitung aus bekannten und 
bestätigtem Wissen unter Einsatz der grauen Zellen.

Ich verwende in bestimmten Fällen auch UART mit internem RC. Nämlich 
wenn diese UART nur für Debug-Ausgabe im Lab benötigt wird, oder für nen 
Bootloader mit Autobauding (z.B. PeDas). Aber wenn die UART produktiv 
für irgendwas verwendet wird, dann immer mit mindestens 
Keramikschwinger.

Autor: die ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:
> die UART ist zickig genug

Hab' ich was nicht mitbekommen? Die UART in den AVR's ist problemlos 
handhabbar.

Der interne RC Oszillator ist primär für einfache Anwendungen gedacht um 
Platz, Geld und/oder Zeit zu sparen. Wer sauber implementieren will 
sollte einen Quarz nutzen. Anderenfalls sollte man wenigstens wissen was 
man tut.

Autor: Netbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint Menschen zu geben, die nur in sehr engen Bereichen denken. 
Bei Ingenieuren und Technikern kann das problematisch werden, weil sie 
auch die Rahmenbedingungen beachten sollen, unter denen eine technische 
Lösung arbeiten soll.

Die Anfangsfrage handelte von Datenübertragung unter minimalistischen 
Bedingungen. Für mich heißt das manchmal (ja, ich denke nach!)

* Ich habe eine kleine Schaltung ohne zeitkritische Anteile
* Ich brauche mal eben zum Probieren eine Übertragung
* Ich arbeite weder an der Antarktis noch in Madagaskar, sondern in 
meinem Arbeitszimmer mit üblichen Raumtemperaturen.
* Ich habe für meine Hau-Ruck-Schaltung weder eine Platine noch Lust, 
überflüssige Sachen zu löten (obwohl ich sogar Quarze hier habe!)
* Ich verkaufe meine Wald-/Wiesenlösung nicht und promoviere damit 
nicht.

Dann probiere ich eine kleine Datenrate ohne Quarz und es funktioniert 
-und wenn nicht, bin ich nicht böse, sondern baue etwas aufwändiger, 
wenn es für mich wichtig ist- .

Falk schrieb:
>Ausserdem sagt das Tutorial NICHT, dass es
>nicht geht. Es sagt lediglich, dass es unzuverlässig ist. Und das IST
so.

Ja eben! Warum kannst du dann nicht meinen Antwortvorschlag vom 18.1., 
15.43 nicht annehmen? Der sagt nämlich genau dieses.

Ich verdeutliche noch einmal die Bedeutung des Kontextes an einem 
konstruierten Beispiel aus einem anderen Bereich.

Frage: Ich möchte mich möglichst einfach vor Regen schützen. Geht ein 
Regenschirm?

Meine Antwort: Ok, ja. Meistens schon. Hab' ich shon 5x probiert. (Ich 
antworte als Pragmatiker)
(Wenn ich dem Frager nichts zutraue, frage ich vielleicht noch: Unter 
welche Umständen soll er dich denn schützen?)

Antwort theoretisch/ 100% Niveau:
Auf keinen Fall! Das haben wir genau durchdacht und sind nach Studium 
aller Regenschirmdatenblätter zum Ergebnis gekommen:
Damit bist du nicht gegen Regen geschützt, wenn du
- im Sturm an der Nordseeküste wanderst
- stundenlang an der Pinne einer Jolle in der Regenfront segelst
- eine Fahrradtour machst
- im Dschungel Tiere beobachten willst
...

Falk würde vielleicht noch ergänzen:
Das Regenschutz- Tutorial sagt NICHT, dass ein Regenschirm nicht geht. 
Es sagt lediglich, dass ein Regenschirm unzuverlässig ist. Und das IST 
so.

Viel Erfolg und ein schönes Wochenende an alle Praktiker, Theoretiker 
und sonstige Menschen   :-)

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Netbird: full ack meiner seits ;)

Gruß Hagen

Autor: die ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-D   nice

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Netbird (Gast)

>Falk würde vielleicht noch ergänzen:
>Das Regenschutz- Tutorial sagt NICHT, dass ein Regenschirm nicht geht.
>Es sagt lediglich, dass ein Regenschirm unzuverlässig ist. Und das IST
>so.

Nicht alles was hinkt ist ein Vergleich ;-)

MfG
Falk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.