-
Thread
UART-Fehler :(
ob du die CLKDIV Fuse ausgeschaltet hast. Dein µC läuft dann zwar mit 8Mhz aber immer noch am internen Oszillator.
> den Quarz rausziehe! > Oha. Das ist aber ein deutliches Indiz dafür, dass der µC auf 'interner Oszillator' läuft.
-
Thread
ATtiny Interner Oszilator Problem
habe einen Attiny 13A an dem man ja kein externes Quarz anschließen > kann. Ich habe also den internen benutzt Nein, hast du nicht. Kannst du garnicht. Einfach deshalb, weil es keinen internen Quarz gibt. Intern gibt's nur einen (recht ungenauen) RC-Oszillator. > doch die SoftUart funktioniert
Für UART besteht die Anforderung, dass die Taktfrequenz nicht mehr als etwa 2% vom Soll abweicht. Mit dem internen RC-Oszillator des atiny13 kann es passieren, dass die Abweichung wegen Spannungsabweichung
-
Thread
ATtiny841 - Quarz notwendig wenn UART benutzt?
Hallo, eigentlich wollte ich vom ATtiny841 den internen Oszillator verwenden. Nun habe ich im Wiki gelesen, dass man einen externen Quarz nehmen soll, wenn man die UART verwendet. Wegen Baudratenfehlern. Nur hat doch der 841er einen stabilisierten internen
zum Stopbit) voneinander zeitlich entfernt haben. Summa summarum, normalerweise genügt der interne RC-Oszillator der AVRs für UART, aber es ist eben nicht über den Temperaturbereich und über Exemplarstreuungen garantiert.
-
Thread
UART und interner Oszillator oder doch Quarz?
bzw. möchte ich gleich noch eine frage anhängen: da mir die UART-zeichen wichtig sind bei der Anwendung, sollte ich die Frequenz besser auf 7.3728MHz legen?? geht das mit dem internen Oszillator? Übertragungsrate reicht mir 9600kbps danke!
ändert auch nichts an der Spannungs- und Temperaturabhängigkeit. Beim Atxmega geht aber auch der interne Oszillator für alle möglichen Baudraten, da er zum einen genauer ist und zum anderen der UART-Teiler genauer eingestellt werden kann.
-
Thread
Atmega 8: ohne Quarz usw. - nur mit int. Oszilator?
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!
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
-
Thread
ATtiny kalibrieren anhand der internen Temperatur
schrieb im Beitrag #2614810: > Nach einer gewissen Menge ohne Pause übertragener Bits sind > die UARTs so weit auseinandergedriftet, dass Fehler auftreten. Bei jedem Startbit wird der UART neu synchronisiert. MfG Klaus
Quarz mit scheinbar "krummer" Frequenz. Aber mit ein paar Vorkehrungen gehen auch 115200 Baud mit internen Oszillator ganz gut. Unterm Strich: Die Mikrosekunden pro Bit spielen keine Rolle, es geht um die 16 Takte, die der Baudratengenerator pro Bit liefert. @cyblord Wenn du UART-Beschreibungen
-
Thread
Attiny 85 intern oder extern 8 mhz
habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts *immer* mit dem internen RC Oszillator... Ein relativer Fehler bleibt doch immer gleich, egal ob 9600 oder 115200 Bd.
habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts *immer* mit dem internen RC Oszillator - noch nie was > gegenteiliges festgestellt. Mit geringen Baudraten kannst du allenfalls den systematischen Fehler gering halten, aber rein garnix gegen den absoluten Taktfehler
-
Thread
AVR Uart Problem
Eine Hardware die UART verwendet ohne einen Quarz oder Quarzoszillator, sprich sich auf den internen RC-Oszillator verlässt, ist, ohne weitere Software für einen laufende Kalibrierung, eine Fehlentwicklung. Dafür spricht
einmalige Kalibrierung wird Dir nicht helfen. Mit der Änderung der > Temperatur läuft Dir der RC-Oszillator wieder weg. ATMEL sagt, dass der interne RC-Oszillator max. +-10% Fehler hat. Damit der Empfang (so wie der Tiny2313 abtastet) einigermassen klappt, darf der Fehler aber nicht größer als
-
Thread
Welcher µC ist einfach zu programmieren
Lothar schrieb im Beitrag #4653891: > Bitte was? Die haben mehrere interne Oszillatoren z.B. die 72 MHz > Version eben 72 MHz und 50 MHz und 80 kHz die man im Programm umschalten > kann - also nichts mit verfusen. EFM8 mit USB haben einen 48 MHz > internen präzisen Oszillator
#4654604: > CAN beispielsweise überträgt ca. 130 Bit in einem Frame, da werden 2% > garantiert zum Fehler führen wenn man z.B 8x 0x00 im Datenpaket > überträgt Wie gesagt daher haben die Silabs 8051 mit CAN auch einen +/- 0.5% internen Oszillator.
-
Thread
Welche max. Datenübertragungsrate bei internen Taktgeber?
. 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
Ich habe mit RC-Oszillator + UART nur schlechte Erfahrung gemacht. Sowohl mit Atmegas als auch mit Xmegas. Die Frequenz hängt zu sehr von der Temperatur ab.
-
Thread
Atmel AVR: RC-Takt genau genug für Low-Speed-RS232?
gelegentlichen Update von Firmware per Bootloader oder zum Ausgeben von Logmeldungen genügt mir der RC Oszillator. Für ernsthafte UART Kommunikation würde ich den RC Oszillator bei keinem µC verwenden.
Und das hast du - woher ? Ben B. schrieb im Beitrag #5545670: > Edit: Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog > haben? Wird der von dem internen RC-Oszillator der CPU abgeleitet und > wie genau ist der? Im bestem Fall so genau wie der interne RC-Oszillator, meistens aber
-
Thread
Beschleunigungssensor
Programmiere erst seit 5 Monaten. Kannst du das bitte genauer erklären was du meinst? Wieso geht UART bei Internem RC-Oszillator eh nicht?
doug schrieb im Beitrag #2864307: > Wieso geht UART bei Internem RC-Oszillator eh nicht? AVR Checkliste für UART: http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
-
Thread
AVR128DA28 9600Baud mit 24MHz
Der interne RC-Oszillator ist hinreichend genau für den UART. Selbst mit 32MHz geht das prima bei der DA / DB Serie wie auch bei den neuen Tinys. Da braucht man wirklich nicht nach einem Fehler zu suchen.
Datenrate ausgeben. Quarze brauchts keine mehr: Wilhelm M. schrieb im Beitrag #7122657: > Der interne RC-Oszillator ist hinreichend genau für den UART.
-
Thread
Baudratenquarz auch bei Verwendung von FTDI o.ä.?
Beitrag #6907646: > Benötigt man dafür einen externen bzw. Baudratenquarz oder genügt dazu > der interne RC-Oszillator des Mega8? Du brauchst einen Quarz/Resonator, aber es muss kein Baudratenquarz sein, denn der ATmega hat ausreichend flexible Vorteiler im UART, um viele Baudraten zu erreichen. Daher
> Benötigt man dafür einen externen bzw. Baudratenquarz oder genügt dazu > der interne RC-Oszillator des Mega8? Um mal deine eigentliche Frage zu beantworten, RC-Oszillatoren sind in aller Regel nicht genau genug um RS232 zuverlaessig laufen zu haben. Es gibt Microcontroller wo der
-
Thread
Attiny2313 UART: Lese-Störungen
Pull-Up-Widerstand die Baudrate? > da mir das locker reicht und ich doch theoretisch >mit dem internen Quarz vom Attiny auskommen müsste, oder? Falsch. Der Fehler durch den internen RC-Oszillator wird durch die Baudrate nicht beeinflusst. 9600Bd bei 1MHz gibt einen Fehler von 7%. Da kannst du eigentlich
möglicherweise ein Wertobjekt an diesem Faden. Ich benutze für Debug Ausgaben und andere Spielchen oft den internen Oszillator mit UART, das geht auch in 95% der Fälle problemlos. Aber beim Modellbau sind die restlichen 5% nach Murphy Gesetz genau die, die das Modell in die Botanik schicken.
-
Thread
Verknüpfung UART und manueller Portpin
Auch für niedrige Baudraten ist der interne Oszillator zu ungenau für UART. ...
>Auch für niedrige Baudraten ist der interne Oszillator zu ungenau für UART. Wenn die Kurven im Datenblatt korrekt sind, dann ist diese Aussage falsch: Ist die Spannung stabilisiert, und man läd den OSCCAL mit einem Wert, so dass der AVR
-
Thread
Quarz Atmega32
...nun noch eine Frage: Was genau ist den der Unterschied zwischen einem Quarz, Crystal und Oszillator? Ich möchte meinen Atmega32L mit dem internen Oszillator betreiben. Der µC soll SPI und UART benutzen. Soll ich nun, wie Daniel(x2) schon sagte, einen Quarz parallel an XTAL 1 und 2 schalten?
Um einen externen Quarz zu nutzen, müssen die Fuses entsprechend gesetzt werden. Ein beliebter Fehler ist es, die Fuse-Einstellung zu vergessen. Der ATmega läuft dann zwar, aber mit der falschen Frequenz (nämlich der des internen RC-Oszillators). EXTERNER Oszillator ------------------- Auch als
-
Thread
UART funktioniert nur mit internem Oszillator!
auf: Benutze ich das alte Hyper-Terminal mit dem internen 8 MHz Oszillator funktioniert eigentlich alles wunderbar, die Startmeldung wird ausgegeben und ich kann Befehle eintippen ( z.B. led1_on ). Setze ich jedoch die Fuses für den externen Oszillator
dem STK500) erhalt ich nur noch "Zeichensalat". Das neue Hyper-Terminal zeigt mir, egal ob mit internem oder externem Oszillator, keine Zeichenketten an. Es wird also beispielsweise keine Startmeldung ausgegeben. Tippe ich einzelne Zeichen ein werden diese jedoch angezeigt?! Ich verstehe die Welt
-
Thread
NMEA wird nicht richtig empfangen (SkyTraq 6 ST22, ATmega8L)
Nein, ich möchte es eigentlich über den internen Oszillator regeln. Oder überfordere ich den Atmega8L damit komplett?
Der interne Oszillator kann gegen einen 32kHz Quarz laufen gelassen werden.
-
Thread
Wie ungenau ist der interne Quarz
ich im CTC Modus arbeite, fast ein wenig viel. Mache ich hier irgendetwas falsch, oder kann der interne Oszillator wirklich so ungenau sein? Vielen Dank im Voraus!
Hi >Dabei habe ich jetzt festgestellt, dass der interne Quarz >wohl ziemlich ungenau sein muss. Gibt es nicht. Das ist ein RC-Oszillator. >Mache ich hier irgendetwas falsch, oder kann der interne Oszillator >wirklich so ungenau sein? Ja.
-
Thread
Fehler beim Receive UART
Hallo, bei der Kommunikation zwischen PC und meinem PIC24F kann ich keinen einzigen korrekten Zeichen empfangen (aus uC Seite). Die Register sind korrekt eingestellt, Baude Rate auch, und das Senden in PC Richtung klappt 100%, mit dem Terminal bekomme ich alles was ich sende. Nur bei dem Empfang ist ständig einen Frame Error => irgendwas mit dem StopBit stimmt nicht, obwohl mit dem Oszi sieht alles richtig und gut aus!! hat jemand noch eine Idee was da sein könnte, oder was ich noch prüfen kann? Gruß
-
Thread
USART Atmega32
> Und der interne Oszi ist doch 4 MHz und > nicht 1 MHz( Das lege ich doch im Makefile fest) oder? Was meinst du denn, wie dein Makefile den Oszillator im Chip ändern soll? Nein, sorry. Im Makefile legst du
und ich hab dort 4 MHz eingestellt also habe ich doch dann mit den richtigen Fuses( auch auf 4MHz internen Oszillator) einen 4MHz Takt oder nicht?
-
Thread
ATmega8 UART
Der interne RC-Oszillator ist für UART-Übertragung zu ungenau. Du solltest einen Baudratenquarz verwenden, z.B. 3,6864MHz oder ein ganzzahliges Vielfaches davon. Der Mega8 wird mit aktiviertem internen Oszillator
ich daraus schließen dass ich ohne einen > externen quarz bzw. mit meinen 1mhz nichts mit dem > UART anfangen kann? Im Prinzip ja. Der interne RC-Oszillator hat je nach Einstellung Abweichungen im Prozent-Bereich. Dazu kommt noch eine starke Temperaturdrift (Im Datenblatt unter Electrical Characteristics
-
Thread
Falsche Zeichen per UART
#4421779: > Die Fuse-Bits sind 0xE1 und 0xD9 Es ist übrigens auch keine allzu gute Idee, den /internen/ RC-Oszillator mit seinen +-3% Fehler für die serielle Schnitte zu verwenden: [pre] At 5V, 25°C and 1.0MHz Oscillator frequency selected, this calibration gives a frequency within ±3% of the nominal
#4421779: >> Die Fuse-Bits sind 0xE1 und 0xD9 > Es ist übrigens auch keine allzu gute Idee, den /internen/ RC-Oszillator > mit seinen +-3% Fehler für die serielle Schnitte zu verwenden: Na da kann man dann selbst kalibrieren, dann kommt man auf 1 %…ist dann zwar immer noch sehr grenzwertig, kann aber
-
Thread
UART einzelne Zeichen senden
Beliebter Fehler: Der AVR läuft mit internem Oszillator. Der ist ohne Nachjustierung aber meist zu ungenau, um im Baudratentoleranzbereich von PCs zu bleiben. ALso: Externer Quarz angeschlossen und aktiviert?
Umrechnungsformel von 16 in 8 ändern) wird die Abweichung bei 9600 bd stark reduziert. Trotzdem nimmt man bei UART-Anwendungen besser einen Quarz, da der interne RC-Oszillator nicht besonders genau ist.
-
Thread
Uart bringt manchmal Schrott
sich die Frage erübrigt. http://www.mikrocontroller.net/search?query=interner+oszillator+rs232 http://www.mikrocontroller.net/search?query=interner+oszillator+fehler+uart http://www.mikrocontroller.net/search?query=interner+oszillator+schrott
daneben. Für seriele Schnittsellen sollte die Bautrate auf besser als 2% stimmen sonst kommt es zu Fehlern. Der interne Oszillator ist meist nicht so genau, läßt sich aber abgleichen (siehe Datenblatt, OSCAL). Ich hatte das mal probiert und der interne Oszillator lag ca. 5% daneben. Nach Abgleich ging
-
Thread
Zeichen fehlerhaft über RS232 an/von ATmega16
externer Quarz oder interner RC-Oszillator? MW
Debug hats gelangt. Die meisten meiner µC Anwendungen sind eh zeitunkritisch so das ich oft den internen RC nehme. Aber wie ich schon sagte: RC Oszillator und UART ist Pfui wenns zuverlässig sein soll. Grüße Björn
-
Thread
UART bei Stm32 mit internem RC
moin wie stabil ist UART wenn ich nur den internen RC verwende? Controller ist auf kurzem Weg mit einem ESP8266 verbunden. Eine Baudrate von 38400 scheint problemlos zu funktionieren. Aber wie könnten sich Temperaturschwankungen
L.Q.O. schrieb im Beitrag #7238615: > wie stabil ist UART wenn ich nur den internen RC verwende? Kommt auf das konkrete STM32-Derivat an. Bei manchen ist er genauer, bei manchen ungenauer, also am besten einfach ins Datenblatt schauen, ob der RC-Oszillator
-
Thread
internen RC Osci syncronisieren
hatte es so verstanden, dass es primär um den Austausch serieller Daten geht und das nur mit dem internen Oszillator. Die OSCCAL-Geschichte nur mittel zum Zweck. Veit D. schrieb im Beitrag #4727302: > Wenn man zum Bsp. 2 > ATtinys mit internen RC aufeinander loslässt und die sollen sich erstmal
002.cpp * * Created: 03.10.2016 20:50:04 * Author: Devil-Elec * µC : ATtiny841 mit internen 8MHz Oszillator * * Interrupt-Vector Namen Übersicht: * C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\iotn841.h */ #include <avr/io.h> #include
-
Thread
UART "kauderwelsch"
Interner RC Oszillator verwendet? Der liegt manchmal etwas daneben.
Hi >Interner RC Oszillator verwendet? Der liegt manchmal etwas daneben. Braucht es nicht. Bei 1MHz und 9600Bd beträgt der Baudratenfehler 7%. MfG Spess
-
Thread
Atmega328P Serial Problem
1% Abweichung oder weniger ist Pflicht, der ATmega328P hat aber +-2%. Wertest Du überhaupt die Uart Fehler aus? Overrun / framing error ?
Michael K. schrieb im Beitrag #5736303: > Wertest Du überhaupt die Uart Fehler aus? > Overrun / framing error ? Im Moment noch nicht, werde ich mal nachholen. Matthias S. schrieb im Beitrag #5736306: > Gerade bei 8Mhz und 115200 Baud gibts mit (U2xN = 0) 8,5% Fehler
-
Thread
welche Einstellungen bei der Fleury-UART-Bibliothek
Hi >Liegt es daran, dass der Fehler zu groß ist? Oder ist der interne >Oszillator zu ungenau? Ersteres resultiert aus letzterem. Du könntest mit dem OSCCAL-Register die Frequenz des internen RC-Oszillators in einen brauchbaren
Meine Erfahrung: Der interne Oszillator von moderneren Atmel-Controllern ist durchaus recht stabil und auch bei den in Wohnräumen vorkommenden Temperaturschwankungen kann man den schon für UART verwenden, wenn man weiss was man
-
Thread
UART @ 1MBit -> over-/undershoots beseitigen
Ralf schrieb im Beitrag #3212647: >>>SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz Hast du auch überprüft mit welchen Fehler der UART-Baudrategenerator die 921k6-Baud generieren kann? Bei höheren Baudraten hat man da normalerweise einen größeren Fehler und
@Holger: > Das heisst du hast versucht einen internen RC Oscillator > für eine UART Verbindung zu benutzen? Kein Wunder das das > nicht funktioniert. Da muss kein Datenblatt neu geschrieben werden. Richtig lesen bitte: für 115k2 -> ja, interner Oszillator
-
Thread
Quarz vs. Quarzoszillator vs. Keramikschwinger
Anfänger schrieb im Beitrag #2087499: > Da kann ich doch gleich den internen Takt benutzen oder? Der Resonator ist trotzdem noch genauer als der interne RC-Oszillator.
. Oszillatoren nicht gut genug für UART sind.
-
Thread
Taktfrequenz vom ATxmega
32MHz CPU-Takt verwandeln. Ich denke, dass in vielen Fällen, besonders wenn das UART eher langsam ist (9600 Baud beispielsweise) sogar der interne Oszillator ausreichen wird. Ich hatte bisher mit dem internen Oszillator (2 MHz) und 9600 Baud UART gar keine Probleme :)
Mich würde ja mal interessieren wie die das mit der internen Referenz hinbekommen. Die interne Referenz leidet doch unter den gleichen Ungenauigkeiten und Temperatureinflüssen wie der interne Oszillator... Bei einer externen Referenz kann ich mir solche
-
Thread
ATtiny841: Optiboot funktioniert bei 8 MHz nur mit internem Oszillator
aber, denn wenn ich das Programm über den ISP-Programmer aufspiele geht alles exakt wie mit dem internen Oszillator und auch der UART funktioniert offensichtlich mit der gewünschten Baudrate. Der UART zum FTDI ist übrigens der einzige Grund warum ich bei 8 MHz überhaupt ein Quarz brauche. Bei allem anderen
aber, denn wenn ich das Programm über den > ISP-Programmer aufspiele geht alles exakt wie mit dem internen > Oszillator und auch der UART funktioniert offensichtlich mit der > gewünschten Baudrate.
-
Thread
Interner Oszillator ausreichend oder doch Quarz
nur die relative Differenz zweier Ereignisse. Da könnte noch gehen. Ansonsten: Fort gesetzte Fehler summieren sich. Ein integrierter Oszillator mit garantierten 1% über den Temperaturbereich ginge eben noch so für einen UART. Für eine Uhr, auch die Notlaufuhr einer DCF77-Uhr, eher nicht.
Es ist im Prinzip egal, wie du misst. Denn der Fehler so groß, wie die Genauigkeit deiner Zeitbasis. Also z.B. 50 ppm bei einem Quarz oder 1% bei einem Oszillator. Sprich: der relative Fehler bleibt also unabhängig von der Messgröße konstant. Der absolute
-
Thread
F_CPU calibrieren und in eeprom abspeichern
des Taktes. Das ist hier kein gutes Argument, da der TO dem ATmega328P verwenden möchte. Sein Fehler ist es, den internen RC-Oszillator verwenden zu wollen, was bei neueren Controllern aber auch kein Problem wäre. ATmega habe ich bevorzugt mit 18,432 MHz betrieben. Das war immer ein guter Kompromiß
Mi N. schrieb im Beitrag #7832911: > Sein Fehler ist es, den internen RC-Oszillator verwenden zu > wollen, Das sehe ich nicht, in diesem Thread. Ihm möchte F_CPU ins EEPROM stopfen. (Wie sinnfrei das auch scheinen mag) Wie gesagt: Ich sehe
-
Thread
AVR UART Interner Externer Timer
mit Atmegas und Attinys meistens mit dem internen Oszillator und habe bei seriellem Interface zum PC als Feedbackkanal eigentlich keine großen Probleme - funktioniert bei z.B. 38.400 Baud sehr gut. Aber in einer Produktivschaltung die so etwas tut
OSCCAL-Register lädst. Außerdem ergeben selbst genaue 1/2/4/8MHz bei den meisten Baudraten schon einen Fehler. Externe Quarze sind um Größenordnungen genauer und stabiler als der interne RC-Oszillator. MfG Spess
-
Thread
AVR F_CPU kalibrieren
Gefühl, ihr seid alle irgendwie daneben. Oder habe ich das total missverstanden? Der TO will den internen Oszillator nehmen und damit eine möglichst genaue Sekunde erhalten (mit von ihm akzeptierten Ungenauigkeiten). Keine externen Quarz - denn wozu soll er dann den internen Oszillator abgleichen wollen
Ziel war, den Prozessor nicht mit einem dauerhaft angeschlossenen Quarz zu betreiben, sondern den internen Oszillator mit den vorhandenen Möglichkeiten abzugleichen. Klar ist dazu irgend eine Referenz notwendig. Habe selber einen Tiny25 als DCF-Uhr programmiert. Er läuft mit dem internen Oszillator
-
Thread
Messkette: Wo ist der Fehler?
ich installiert, d.h. die USB-UART-Brücke wird vom PC anerkannt. Der C-Code ist definitiv korrekt. Ich weiß echt nicht worin jetzt noch das Problem besteht. Könnte es sein, dass ich beim flashen einen Fehler gemacht habe, oder ich
verehrte Forummitglieder, ich bin dem Rat nachgegangen eine String in den C-Code direkt über die UART des AT90USB1287 und über die USB-UART-Brücke an Tera Term zu verschicken. Das Lämpchen der RX der USB-UART-Brücke flimmert unentwegt. Doch trotzdem wird mir der String bei Tera Term nicht angezeigt.
-
Thread
Atxmega startet nicht korrekt
Robert schrieb im Beitrag #4929441: > Wenn es keine ultrahohen UART-Frequenzen werden sollen ist auch der > interne Takt beim Xmega für diesen Zweck hinreichend stabil. Die prozentuale Abweichung ist unabhängig von der absoluten Geschwindigkeit. 5% Fehler sind sowohl
Lothar M. schrieb im Beitrag #4931074: > Robert schrieb: > Wenn es keine ultrahohen UART-Frequenzen werden sollen ist auch der > interne Takt beim Xmega für diesen Zweck hinreichend stabil. > > Die prozentuale Abweichung ist unabhängig von der absoluten > Geschwindigkeit. 5% Fehler
-
Thread
AVR mega32 uart empfang geht nicht
AVR im speziellen ist die Frage immer: Wie (temperatur)stabil ist das Ganze?. Und da scheidet der interne Oszillator schlicht und ergreifend aus. Siehe Datenblatt, das Ding schwankt gut und gern +/-3% im gesamten Temperatur- und Versorgungsspannungsbereich. Dazu kommt der prinzipbedingte Fehler bei der
Sibirien bis in die Sahara nachgebaut werden kann und auch läuft. Und gerade Anfänger tun gut daran, den UART erstmal nur mit Quarz zu betreiben. Und auch die Leute die wissen wie der Hase läuft werden selten in die Verlegenheit kommen, den UART mit internem Oszillator zu betreiben. MfG Falk
-
Thread
UART mit atmega 16
Schaltung: Das ist erstmal uninteressant. Uns interessiert, wie Du den Takt erzeugst bzw. ob Du den internen RC-Oszillator verwendest. >Kann der Fehler auch durch nicht genau Elkos auftauchen ? Nicht diese Elkos in diesem Zusammenhang.
mit AVR-GCC . Zum Flashen verwende ich das Gerät "JTAG ICE". Der Atmega 16 arbeitet mit dem internen RC-Oszillator
-
Thread
Extra Oszillator schalten?
Hallo! Der interne Oszillator kann nicht alle Frequenzen 'erstellen' und ist leider auch relativ ungenau / temperaturabhängig. Für Aufgaben, in denen exaktes Timing notwendig ist (z.B. UART, RTC) ist der interne Oscillatopr
Ich hab' mal gelesen, dass das UART mit dem internen Oszillator nur keine hohen Datenraten erlaubt. Weis einer die Toleranzwerte des Internen Oszillators?
-
Thread
rpi <--> avr uart Übertragungsfehler bei Quarzbetrieb
Beitrag #7741288: > Bei >= 234000 ist die Fehlerrate extrem hoch http://www.gjlay.de/helferlein/avr-uart-rechner.html Deine Zahlen kurz eingesetzt kommen da teilweise 8% Fehler raus. Harald schrieb im Beitrag #7741288: > Keine Aussetzer gibt es jedoch wenn der avr mit dem internen RC - > Oszillator
Hi >Die 500000 funktionieren mit 8 MHz Takt aus dem internen RC - >Oszillator. Dann ändere mal mit Kältespray/Heißluft die Temperatur des Atmega. MfG Spess
-
Thread
uart interface pic18
NOCLKDIV // 1:1 mode (for 48MHz CPU) ... // -> 48 MHZ interne Oszillator Clock void InitializeUSART_115200(void) { unsigned char c; UART_TRISRx=1; // RX -> Eingang -> geht an BT_UART_RX UART_TRISTx=0; // TX -> Ausgang ->
Yo, sehe ich auch so. Interner Oszillator läuft auf 1MHz per default ... Kein Problem mit 115200 bei mir wenn man den Oszillator über das OSCCON vernünftig einstellt. Vergiss den externen vorerst mal ! #include <p18cxxx.h
-
Thread
UART sendet nicht das was er soll (kein offset problem)
. Lern erstmal ein paar Grundlagen. > > http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART > > MFG > Falk Danke erst mal, -ich habe nur einen Internen Takt zu verfügung. -die verbindung und die Übertragung funktioniert Prinzipiell -zeichen könne ohne fehler übertragen
_delay_ms( 1 ); } [/C] wenns dann geht, dann hast du ziemlich sicher ein Problem mit dem internen Oszillator. Du kannst auch mal probieren, auf 2 Stoppbits zu erhöhen. > Ps: Hilfsbedürftige ins Lächerliche zu ziehen ist nicht die feine Art Wenn jemand den internen Oszillator zur UART
-
Thread
Fragen zu Quarzoszillatoren für Mikrocontroller
der UART meist nur mit Fehler (<1%) einstellbar. Macht aber wenig, denn erst bei etwa 5% bekommt die UART Probleme. Ein Quarz hat Vorteile gegenüber einem externen Osz: -nahezu jeder Kontroller enthält
der UART meist > nur mit Fehler (<1%) einstellbar. Macht aber wenig, denn erst bei etwa > 5% bekommt die UART Probleme. Wenn man die Geräte auf beiden Seiten der Leitung baut, kann man so mit besonders
-
Thread
Serielle, Hyperterminal
/* Oszillator-Frequenz in Hz */ #endif #define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1) //Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt) #define UART_BAUD_RATE 9600 volatile
will sehr wohl die 9600 Baud mit dem internen RC-Oszillator verwenden. mach ich vielleich einen Fehler mit dem hyperterminal? stimmt ansich der code??