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
>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.
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
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.
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.
@ 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
@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...
@ 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
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.
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.
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...
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
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.
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...
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?
@ 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
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.
@ 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
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?
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."
@ 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
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 :-) )
@ 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
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
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).
@ 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
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
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.
@ 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
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!
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...
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
>>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 ;)
@ 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.
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.
>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.
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
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.
@ 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
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.
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.
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 :-)
@Netbird: full ack meiner seits ;) Gruß Hagen
@ 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
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.