-
Thread
Tastenschlagzeug mit NXP LPC 935 selber bauen
Baudrate von 31250 Bauds erzeugt werden kann. Die Betriebsart 1 bedeutet: 8 bit UART mit variabler Baudrate. Genau das brauch ich. Die Stop und Start Bits kommen von der UART selber diese müssen nicht programmiert werden. Die CCLK ist der RC-Oszillator. Vermutlich der interne
> Wenn man nun von dem internen 7,3728MHz Takt ausgeht kommt man mit > Timer1 auf folgende mögliche Baudraten: Stimmt fasst, da ist dir beim Abschreiben ein kleiner Fehler unterlaufen. Der RC- Oszillator hat 7,3738 MHz.
-
Thread
Na wunderbar - Fusebits: Ausgesperrt aber mit den richtigen Eingaben?
Extosc ist doch ein oszillator und kein quarz... versuche es mal mit externem Takt
Sean Goff schrieb im Beitrag #3486581: > Extosc ist doch ein oszillator und kein quarz... versuche es mal mit > externem Takt Glaub ich nicht, sonst wär der Schmus mit 258CK,64MS Unsinn. Eher: EXTOSC = interner Oszillator mit externem Quarz. Was du meinst heisst
-
Thread
UART zwischen 2 atmega16
Wenn du nicht weisst, was eine Fuse ist, dann verwendest du die R/C Oszillatoren. Und die sind für UART Kommunikation nicht genau genug.
gibt und dann z.B. eine quarzgetaktete Sekunde schältet und sich dann ansieht, was der Timer1 mit internem Oszillator dabei rausbekommt. Verändert man dann mit Föhn, Kältespray und LNT die Bedingungen, erkennt man schnell die Tendenzen, die bei allen Controllern gleich sind. DÜ per UART funktioniert
-
Thread
Wann nehme ich welchen Quarz?
wenn man einen LCD nehmen will? Dann nimmt man gar keinen Quarz. Für fast alle LCD reicht der interne RC-Oszillator. > Wie sieht es aus, wenn man mehrere UART realisieren will? Dann muss man rechnen, welche Baudraten man nutzen will, wie man den Prescaler wählt und ob sich das ausgeht. Das ist
Beitrag #5240134: > Für eine Eieruhr oder den Belichtungstimer kann ich also bedenkenlos den > MC-internen Oszillator verwenden? ja, reicht locker. Im Datenblatt ist normalerweise der Fehler angegeben. Bei einigermassen guten µC hast du z.B. 1% Fehler. Bei halbwegs konstanter Zimmertemperatur eher noch
-
Thread
AVR Timer/Counter Zeit berechnen
Marc V. schrieb im Beitrag #5537680: > Selbst ein Fehler von 30% ist absolut uninteressant, Stabilität ist > wichtig. Fehler ist auch uninteressant nur die Stabilität ist mal beim internen RC für gewisse Anwendung nicht optimal. Ebenso kann die UART
interne RC und mal nur zur Info auf die UART verwiesen ab S.163. Diese Tables beziehen sich alle auf einen externen Quarz viel Spaß mit dem internen RC als Basistakt bei der UART... Die Umgebung mal nicht
-
Thread
Serielle Datenübertragung vom ATMega8 zum PC
abgestimmt. Bei 1MHz gehen z.B. 300, 1200, 2400, 4800 mit unter 1% Genauigkeit. (9600 ergibt einen Fehler von 7%) Wenn ich das Datenblatt richtig interpretiere, geht der interne Oszillator bei 1MHz mit bis zu 3% Abweichung......
Hi >mit welcher baudrate kann ich denn noch arbeiten? Bei <=4800Bd liegt der Fehler bei 0,2%. Aber wie schon mehrmals gesagt ist der interne RC-Oszillator für eine stabile Verbindung ungeeignet. MfG Spess
-
Thread
Welchen Mikrocontroller für Millisekunden-Stoppuhr?
Manfred P. schrieb im Beitrag #7830166: >> Der interne Taktgeber ist in der Tat ungenau, >> hat aber 8 MHz. > Wie ungenau? > Welche? Die Masse meiner hat 16 MHz Normalerweise meinen Leute hier im Forum den internen R/C Oszillator. Dieser hat bei
klassischen AVR 8 MHz +/-10%, soweit ich mich erinnere. Im gleichen Beitrag wie ich darauf hin der (interne) Quarz-Oszillator > nicht weniger genau, als ein 32 kHz Uhrenquarz ist.
-
Thread
ATmega328PB: UART(MC) empfängt falsche Daten
in AS7 nochmal nachgeguckt wegen den Fusebits: CKDIV8 ist aktiv, genauso wie von CKSEL[3:0] der interne RC-Oszillator als Quelle ausgewählt ist. Jetzt habe ich im aktuellen Datenblatt von 2018 nachgesehen. Bei F_CPU=1MHz hat der UART des MC eine Fehlerquote von 8,5%. Daher wollte ich die F_CPU auf
Ruhepegel ungefähr 5V betragen. Da er aber nur ein paar mV gemessen hat, muss wohl die Verbindung fehlen, kaputt sein oder der USB-UART Adapter ist kaputt.
-
Thread
Atmega328p und DS1307
Verzeihung, dass ich mich falsch ausgedrückt habe. Ich meinte selbstverständlich den internen Oszillator.
gesetzt? Welchen I2C Clock nutzt du? > Ich durchsuche nun nicht den ganzen Code, irgendwo wird dein Fehler > sein. Die Diskussion hatten wir gestern schon. Er benutzen den internen Oszillator am ATMega328P F_CPU wird auf 8000000 gesetzt. Wir hatten den über den Quarz am DS1307 gesprochen, weil
-
Thread
Raspberry pi Pico rp2040 RS485 Implementierung
Jetzt mal ehrlich, wie oft muss hier eigentlich noch erklärt werden das mit hochgradig ungenauen internen Oszillatoren bestenfalls LEDs zum Blinken gebracht werden aber KEINESFALLS UART Kommunikation. Das ganze Setup ist dermaßen Übel und sinn-befreit das es einem die Sprache verschlägt. Drop Mic.
Norbert schrieb im Beitrag #7194353: >> Der Attiny läuft mit dem internen Oszillator > Das Problem taucht auch bei niedrigeren Baudraten genau so auf. Wenn der Oszillator 10% falsch läuft, dann ist die Übertragung bei 115200 ebenso 10% falsch wie auch bei 300 Baud.
-
Thread
Seltsame RS232 - Ausgabe
_DAS_ kann jetzt der zu schlechte interne oszillator sein. wenn du mit der baudrate runtergehst und die fehler dabei weniger werden, wars das.
Hi >DAS kann jetzt der zu schlechte interne oszillator sein. >wenn du mit der baudrate runtergehst und die fehler dabei weniger >werden, wars das. Begründung! MfG Spess
-
Thread
Mega8 Uart Empfangs Problem
@ UB (Gast) >Nutze den internen Oszillator (8Mhz,9600Baud) und die Lib von Peter >Fleury. MÖÖÖP! Fehler! >Ist ess Möglich das der PC trotz richtiger Baud-Rate "zu schnell" sendet >??? [[AVR-Tutorial: UART]] MfG Falk
@ Paul Baumann (Gast) >Hm, 8Mhz und 9600Baud ergibt nur einen Fehler von 0,2%. Warum sollte das >nicht gehen? "Nutze den internen Oszillator (8Mhz,9600Baud)" Der hat keine 0,2%, eher 2% und mehr. Sihe Link. MFG Falk
-
Thread
Genauigkeit, Toleranz UART vs RC Oszillator
Hi, ich habe vor einen Mega8 mit dem internen 8Mhz oszillator laufen zu lassen, benötige allerdings die UART. Nun ist ja der RC Oszillator nicht der stabilste... :-) Ich benötige allerdings nur 2400 oder maximal 4800 Baud. Meint ihr das er
@ Basti (Gast) >ich habe vor einen Mega8 mit dem internen 8Mhz oszillator laufen zu >lassen, benötige allerdings die UART. Kein Platz merh für einen kleinen Quarz? Glaub ich kaum. >Meint ihr das er dafür stabil genug ist?? Wenn du ihn kalibrierst
-
Thread
UART mit atmega32
Der interne RC-Oszillator ist prinzipiell für die UART zu ungenau. Da brauchts entweder einen Quarz oder Keramikschwinger. Sonst ist es reiner Zufall, wenns klappt. Peter
den Standard-Takt gegeben, ohne Veränderung der Fuses). Auf Seminaren empfehlen sie wohl den internen RC-Oszillator auch als (mittlerweile) tauglich für RS-232-Anwendungen. Vorteil des RC-Oszillators ist, dass er schnell anschwingt, sodass man die Startzeit kurz halten kann, wenn man den Prozessor
-
Thread
Software UART mit FIFO
Noch eine Ergänzung: Einen Soft-Uart zu implementieren ohne angeschlossenen Quarz kann in die Hose gehen. Der interne Oszillator ist nicht sehr genau und insb. auch temperaturabhängig. Bei zu großen Abweichungen der realen Taktfrequenz
einen Pin mit dieser Funktion kippen lasse. Könnte das schon ein Hinweis auf den sehr ungenauen internen Oszillator sein?
-
Thread
UART funktioniert nicht
morgen erst neues sagen, da ich morgen erst wieder auf der Arbeit bin, jedoch weiß ich, dass ein interner RC-Oszillator von 1MHz eingestellt ist. Danke für eure Antworten Florian
Mit dem internen RC-Oszillator hast Du nie die Sicherheit, dass es trotz funktionierenden Programm zu vernüftigen Ergebnissen kommt. Kann gehen oder auch nicht. Wenn Du aber noch andere Fehler vermutest, z.B. Hardware
-
Thread
UART falsche Zeichen
geschaut und überprüft, ob die Fuses richtig gesetzt sind. Es gibt IMO eine Fuse, die angibt, ob die interne oder externe Taktquelle verwendet werden soll. Ich habe gelesen, daß die Interne Taktquelle nicht für UART geeignet ist, weil zu ungenau (temperaturabhängig, usw.). Apropos Fuses, vllt. ist bei Dir
Baudrate erreicht. Der Prozessor arbeitet nicht mit dem Quarz, sondern läuft immer noch auf dem internen Oszillator.
-
Thread
STM32 CDC auf unterschiedlichen Rechnern
Takt nicht 48 MHz sein?! Wozu ein Baudratenquarz wenn man USB >> nutzt? > > Weil ich auch viel Uart und RS485 im System verwende. Aber auch mit 48 > Mhz über den internen Quarz habe ich das selbe Fehlerbild. Es gibt keinen internen Quarz. Es gibt zwei interne Oszillatoren (32k und 8M), die aber
Frank K. schrieb im Beitrag #7598502: > Es gibt keinen internen Quarz. Es gibt zwei interne Oszillatoren (32k > und 8M), die aber nicht quarzstabilisiert und damit für USB oft nicht > genau genug sind. Das wird es sein. Tausch mal den externen Quarz
-
Thread
Zahlenrätsel: Wer knackt den Code?
#1818956: > ankommen, oder? Die übertragenen Daten sind aber immer zuverlässig > gleich... Der interne Oszillator hat halt zuverlässig 7,9 MHz statt 8 MHz. http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Wichtiger Hinweis 2 :-)
uart mit internem rc geht ja wohl gar nicht... quraz ran problem gelöst...
-
Thread
Strom sparen: µController eigenen Quarz geben oder über RTC tackten?
Ich dachte immr mit internem R/C oder externen Resonator könnte man UART vergessen. Peter Dannegger schrieb im Beitrag #2267117: > Der RTC dient auch zum Kalibrieren der Baudrate für die UART. Wie meinst du das?
auch zum Kalibrieren der Baudrate für die UART. > Per Interrupt? Bei jedem Int ein Bit? Die bekannte genaue RTC-Zeit mit dem ungenauen internen Takt nachmessen und daraus den Fehler des internen Taktes ableiten.
-
Thread
UART Kommunikationsproblem
RichieRich schrieb: > Jetzt habe ich den internen Oszillator auf 6 MHz umgestellt mit der Das glaube ich nicht. Man kann den internen RC beim ATmega32 nämlich nur auf 1,2,4 oder 8 MHz einstellen.
schrieb: > Die Zeitbasis ist 250 us. Also ca. 850 µs für 9 Bit = ca 10600 Baud. Du wirst den internen Oszillator kalibrieren müssen, sonst wird das nichts.
-
Thread
Mehrere Attiny's mit 1 Atmega kommunizieren lassen
A. H. schrieb im Beitrag #5992153: > Auch Quarze sind unnötig, die internen Ozillatoren sind genau genug für > die Kommunikation. Für UART Kommunikation sind Oszillatoren mit mehr als 4% Abweichung ungeeignet. Ein Blick ins Datenblatt könnte helfen. Die meisten mir bekannten
zumindest mit Keramikresonatoren ausstattest, kann es > funktionieren. Es geht auch mit dem internen RC-Oszillator problemlos, wenn man mit Bitsynchronisation arbeitet, zumal die 8-Pinner eh keine HW-UART haben. Siehe mein Link oben.
-
Thread
wahrscheinlich einfaches USART Problem
Hallo kleiner tipp.. such mal nach Peter Flury der hat eine sehr gute Uart Libary lass dich nicht verwirren durch die Quarzprobleme.. ich habe UART mit dem internem 8MHz Oszilator ohne Probleme am laufen gehabt.. wobei du beim empfanngen nur aufpassen must (besonders
Entschuldige den Unsinn mit Assembler, ich meinte natürlich C. Ich habe noch keinen selbstgestrickten UART verwendet da ich die Lib von Fleury nehme, die funktioniert bestens. Mit dem internen Oszillator hatte ich allerdings immer Probleme. @Peter Die Berechnungen stehen im Datenblatt beim USART.
-
Thread
ATxmega UART ohne Quarz
verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt, dass eine UART-Schaltung die im Winter noch funktionierte, im Sommer den Dienst verweigert. " Die xmega haben einen intern kalibrierten 2MHz bzw. 32MHz Oszillator! Siehe Datenblatt Xmega: "A DFLL can be enabled
-
Thread
AVR mit internen RC Osc. betreiben
Hallo, Micha schrieb im Beitrag #5711429: > Also es handelt sich um den internen. Internen RC-Oszillator, es gibt keinen internen Quarz nur als Anmerkung. Micha schrieb im Beitrag #5711429: > das ganze solle eine UART haben, vorbei es hier nicht auf die > Geschwindigkeit
Bei einem etwas neueren zum Mega16 pinkompatiblen AVR ist der interne Oszillator deutlich genauer.
-
Thread
ATMEGA168 vs ATMEGA328 RC Oscillator
auch, inkl. Migration Note: Hier gibt es Unterschiede in den Quartzpin - Kapazitäten; sollte beim internen RC - Osci nicht relevant sein.
sind die Ergebnisse der Frequenzmessung stark fehlerbehaftet. Als Gegenbeweis, dass der RC-Oszillator es besser kann, verstellt man dessen Kalibrierung manuell. Damit kann man ihn auf <1% Fehler abgleichen und der UART läuft stabil und fehlerfrei. Ich hatte mal ein Projekt, wo nur ein 32k Uhrenquarz
-
Thread
Hex-Werte in Textdatei schreiben, wie
@J.-u. G. Leider behebt es meinen Fehler nicht. Denkst du, dass ich die UART geschrottet habe?
JTAGice3 schrieb im Beitrag #2792473: > Hier das Programm. Läuft über den internen Quarz. Es gibt keinen "internen Quarz"! Das ist ein ungenauer RC-Oszillator.
-
Thread
USART mit ATMega16
www.mikrocontroller.net/tutorial/io-basics.htm <--snip--> Beim ATmega8 ist standardmäßig der interne 1 MHz-Oszillator aktiviert; weil dieser für viele Anwendungen (z.B. UART) aber nicht genau genug ist, soll der Mikrocontroller seinen Takt aus dem angeschlossenen 4 MHz-Quarzoszillator beziehen. Dazu
führen, daß der Controller nicht mehr über ISP programmierbar ist. Übrigens noch am Rande: der interne Oszillator ist eigentlich genau genug, um kleinere Baudraten (9600) zu realisieren. Hab selbst ein Gerät mit nem Mega16 bei internem 8 MHz-Oszillator laufen und selbst 38400 Baud sind bisher möglich
-
Thread
ATmega328p @ 8Mhz Standalone UART Baudrate einstellen?
> Brauche die Taktpins, also > externer Takt ist keine Alternative Dann lässt du das mit dem UART besser sein. Mit dem internen Takt gibt das nur ständigen Ärger. Georg
Brauche die Taktpins, also > externer Takt ist keine Alternative) > Ich nehme an, mit 8Mhz (der interne Takt soll ja auch relativ ungenau > sein) schafft der einfach nicht die Standard-Baudrate von 115200. klaro 1. wegen der ungenauen internen 8MHz 2. weil bei 8MHz der Fehler rechnerisch zu
-
Thread
Hochgeschwindigkeit-Oszillator in VHDL
jetzt vielleicht etwas laienhaft sein... Ist es eigentlich möglich einen Hochgeschwindigkeit-Oszillator in VHDL ohne die Verwendung von internen oder externen Oszillatoren zu machen? Also mit der maximalen Schaltgeschwindigkeit (Umschaltung/Erkennung der Logikelemente auf/von High oder Low) was der
Beitrag #6521306: > Ich kenne Leute, die noch einen Trimmprozess fahren, nur damit sowas wie > UART funktioniert. Wenn ich in einem FPGA so einen Oszillator nähme und einen UART drauf fahren müsste, dann würde ich dafür sorgen, dass ein UART-Frame mit einem definierten Sync-Wort beginnt, damit ich
-
Thread
ATMEGA644 defekt?
Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Das Programm nicht aber mein Blinky. Allerdings ist auch die Srromaufnahmexdes Boards gesunken was heisst das der
Marco G. schrieb im Beitrag #4869519: > Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. > Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Statische Überspannungen, Produktionsfehler, ...
-
Thread
ATmega168 UART Problem
ich auf das Bit geprüft, das 9 Datenbits konfiguriert, es ist nicht gesetzt. Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU ist 8MHz. Ich benutze weiters die UART Library von Peter Fleury (http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html)
Armin B. schrieb im Beitrag #3090124: > Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU > ist 8MHz. Du weißt, dass der interne Oszillator nicht sehr genau ist? Eventuell musst Du die Baudrateneinstellung noch etwas trimmen (oder den Oszillator
-
Thread
Mit 1MHz µC Takt und 19200Baud UART, geht das?
Mein Mega8 ist mit internem takt ausgestattet und der beträgt 1 MHz, im Datenblatt finde ich die Angabe leider nicht, ob ich noch in dem Toleranzbereich liege, oder ob ich mit 1MHz gar keine 19200 für die Uart realisieren kann
Wenn man schon den internen Oszillator verwenden will, dann geht natürlich auch 19200 bei 1MHz, so gut oder schlecht das mit dem internen überhaupt geht. Denn 7-8% Abweichung kann man über OSCCAL ausgleichen - sind dann halt
-
Thread
Mikrocontroller - die Qual der Wahl, oder doch die Wahl der Qual?
> Die Xmega haben auch ihre Tücken bei der Taktkonfiguration: Wenn man bei > einem Xmega die UART mit internem R/C Oszillator verwenden will, muss > man diesen ungenauen Oszillator mit einem weiteren kalibrierten > Oszillator synchronisieren. Genauso falsch. Gerade XMegas arbeiten intern
Ich schrieb: >> Wenn man bei >> einem Xmega die UART mit internem R/C Oszillator verwenden will, muss >> man diesen ungenauen Oszillator mit einem weiteren kalibrierten >> Oszillator synchronisieren. dirk schrieb im Beitrag #5776287: > Genauso falsch
-
Thread
Baudratenquarz
Midi, whatever). Siehe [[Baudragtenquarz]] MfG Falk P S Man KANN RS232 SICHER mit dem internen RC-Oszillator betreiben, wenn man a) den Oszillator kalibriert (per OSCCAL und Cal. Byte) b) den Oszillator kalibriert (per 32K Uhrenquarz und Timer) MfG Falk
auch Taktquellenwechsel on the fly und außerdem einen Fractional Baud Rate Divider bei jeder der 8 UARTs die zum Beispiel der ATxmega128A1 hat. Da reicht auf jeden Fall die Interne Taktquelle+PLL bzw. DFLL. Bei den normalen Megas sollte man aufpassen, dass auch bei kalibriertem Oszillator man die Temperatur
-
Thread
UART mit R/C Oszillator
Es geht um Atmega und Attiny, kein konketer Typ. Soweit mir bekannt ist, kann man den UART nicht gut mit R/C Oszillator nutzen, weil dessen Taktfrequenz nicht genau eingehalten wird und von der Temperatur abhängt. Ich hatte mal ein Modem, das hat die Übertragungsrate der seriellen Schnittstelle
unbedingt monoton steigend. Und wenn man wirklich genaue Zeiten messen will, ist man mit einem RC-Oszillator immer noch fehl am Platze, glaube ich. Denn die sendende UART, die man als Zeitbasis für die Kalibrierung nimmt, läuft ja auch nicht unbedingt supergenau...
-
Thread
STM32F0 Bootloader-Problem (UART, Neuling braucht Hilfe)
Nun ja, ob der Chip-interne RC-Oszillator genau genug ist kannst du ja im Datenblatt nachlesen und daraus schliessen ob die Baudrate genau genug erkannt wird. Die Geizigkeit einen Quarz und zwei Kondensatoren wegzulassen
Fehler weg, aber der HSI ist, nun ja, es gibt deutlich bessere. Die note(1) im Datenblatt ist auch ernst gemeint; STM gibt ja sowieso nur typische Werte an. Das betrifft aber nicht den internen Bootloader
-
Thread
Netzwerkkarte mit RTL8019
wissens intern nur 1MHz. Die 8 steht für den Speicher, nämlich 8kB. Soweit ich gehört habe ist der interne Oszillator auch sehr instabil und das UART läuft damit nur auf 2400 BAUD o.ä. (müsste im Source angepasst werden). Du solltest also auf jeden Fall einen externen Oszillator anschließen, mit 8 oder
entschuldige die Fehlangabe... hatte übersehen dass man den internen Takt verändern kann, dennoch steht die 8 für den internen Flash Speicher. Wieauchimmer, noch ein unerwünschter Tipp von einem Atmega32 Benutzer: Die Funktion des UART (nämlich die Baudrate) hängt
-
Thread
Atmega8/88 mit 8Mhz betreiben.Kondensator`?
marixstorm schrieb: > Die 19K2 macht der 88er bei Zimmertemperatur auch problemlos mit dem > internen Oszillator. > > Den Atmega8 würde ich ohnehin da liegen lassen, wo er ist. > > mfg. ich bin hier in der Luft zerrissen worden als ich den internen Oszillator zusammen mit der UART nutzen
Tobi88 schrieb im Beitrag #3277141: > ich bin hier in der Luft zerrissen worden als ich den internen > Oszillator zusammen mit der UART nutzen wollte Von irgendwelchen Knalltüten, die noch nicht gemerkt haben, daß die Atmega8/16/32... nicht mehr State-of-the-Art sind. Bei denen soll der interne
-
Thread
attiny85 1Mhz Arduino virtuell Serial Protokoll beenden
Auch von 2400-9600 getestet alles egal. Das stimmt was nicht. Ich habe auf einem ATmega169 mit internem Oszillator stabile Übertragung 19600 bps hinbekommen. Beim Starten lief eine Kalibrierroutine, die den internen Oszillator mittels OSCCAL und einem externen Uhrenquarz (32,768 kHz) auf Wunschfrequenz
Tom schrieb im Beitrag #5744160: > Ich habe auf einem ATmega169 mit internem Oszillator stabile Übertragung > 19600 bps hinbekommen. > Beim Starten lief eine Kalibrierroutine, die den internen Oszillator > mittels OSCCAL und einem externen Uhrenquarz (32,768 kHz) auf
-
Thread
Uart Fehler bei Attiny2313
läuft schon etwas besser ohne den while-Teil (vielleicht Einbildung). Aber es gibt immer noch viele Fehler. Vielleicht liegt es an der UART-Konfiguration? Tim
überträgt alles > richtig. Interessant auch: die 115.2kBaud gehen realtiv Fehlerfrei mit > 8Mhz internem Quarz, aber nicht genau genug -> ca. 5% Fehler) uart mit internem rc oszillator... nein das geht mal garnicht..nur glückssache wenn das läuft....besorg dir einen richtigen quartz dann läufts auch
-
Thread
µC Auswahl Atmel Atmega - UART und Batteriebetrieb
Du erschreckt feststellen daß es nicht ratsam wäre sich für rs232 ohne weitere Maßnahmen auf den internen Oszillator zu verlassen, Ärger wäre vorprogrammiert. Abhilfe schafft das Kalibrierbyte OSCCAL, damit kann man den internen Oszillator halbwegs (genau genug) hinziehen, musst halt jedes Exemplar
einsparen wollen und dann Klimmzüge machen die > im Endeffekt erheblich teurer werden. Den internen Oszillator zu verwenden hat auch Vorteile: weniger Verbrauch und schelleres Anschwingen, was gerade bei Batterieanwendungen interessant ist. Der interne Oszillator ist gut für UART-Anwendungen geeignet
-
Thread
Qualität bei Microchip's dsPIC33
PLL's ganz leicht verstellt. Microchip First-Level-Support: Hat 2 PICs zusammengehängt, beide mit internem RC-Oszillator (!) und hat gemeint, dass es ja eh geht. Ja eh - zufällig. Ich hab's dann aufgegeben, wollt' nicht unhöflich werden. Grüsse, Gernot
in wievielen Automotive-Produkten mit PICs dieses Problem übersehen wurde. Und weil ich nur den internen RC-Oszillator verwendet habe (PCB-Size), habe ich die LIN-Baud-Sync-Funktion der UART verwendet. Die hat natürlich auch einen Bug und ich hab einen zusätzlichen Flanken-Interrupt einbauen müssen.
-
Thread
Suche Arduino kompatiblen Bootloader für ATmega8 mit 8Mhz intern
Der interne RC-Oszillator ist nicht ausreichend frequenzstabil dafür.
Krypto-Bootloader der sich selbst den Takt sucht: https://jtxp.org/tech/onewayloader.htm Der interne RC-Oszillator ist IMHO deutlich besser als sein Ruf. Serielle Protokolle können die Schwankungen üblicherweise locker verpacken. Man muss allerdings die UART-Register passend zur realen Frequenz
-
Thread
Problem mit UART
Betreibst Du den Mega8 mit internem Oszillator? Wenn ja, vergiss es. Der ist zu ungenau für UART...
von 9600 ist der Fehler mit dem internen RC-Oszillator akademisch klein, weil das Signal länger dauert und die Synchronisation innerhalb der 9 Bits (Startbit + 8 Datenbits) nicht mehr so arg kritisch, weil die Bits immer
-
Thread
UART + Quarz
Meine Erfahrungen sind, daß der Tiny2313 keinen internen Quarz besitzt. Ein rel. proz. Fehler wird auch durch Frequenzteilung nicht kleiner. Ein keram. Resonator wäre eine Alternative zum Quarz. Rechnet sich aber auch erst in Stückzahlen.
Ich lasse alle meine ATmegas mit dem internen 8MHz laufen und arbeite mit 38400 Baud. Meine PICs laufen mit intern 1MHz und die UART schaft fehlerfrei 9600 Baud. Keine Ahnung, wie sich das ändert, wenn ich die Schaltung in Sibirien oder Afrika
-
Thread
Quarz vs Resonator
Baudraten (2400 baud) hat man eigentlich eine recht große Toleranz. Ich habe mal vor kurzem eine Software-UART auf einem Tiny15 realisiert (wegen IR-Übertragung mit einem TSOP als Empfänger nur 1200 baud). Diese versagte auch dann nicht als ich dem Tiny15 mit einer Lampe etwas einheizte (interner RC-Oszillator
2400 baud) hat man eigentlich eine recht große > Toleranz. Ich habe mal vor kurzem eine Software-UART auf einem Tiny15 > realisiert (wegen IR-Übertragung mit einem TSOP als Empfänger nur 1200 > baud). Diese versagte auch dann nicht als ich dem Tiny15 mit einer Lampe > etwas einheizte (interner RC-Oszillator
-
Thread
wie Schwingquarz an dsPIC30F4013
Wer erzählt immer noch den Mist, daß die internen Oszillatoren so sehr ungenau sind ? Bei Microchip gibt es auch Abhandlungen darüber, daß man CAN-Kommunikation mit denen machen kann ohne einen signifikanten Fehler zu erzeugen, und die lahme UART-Kommunikation
lahme UART-Kommunikation schafft der immer ! > > Warum also immer diese mistigen Quarze anschließen und auch noch über > die benötigten Kondensatoren so viele Threads aufmachen ? > > Der interne Oszillator
-
Thread
Bluetooth sendet kryptische Zeichen
besten ein Baudratenquarz, führt kein Weg vorbei. Moderne µC haben gerne mal Laser-getrimmte RC Oszillatoren, die für UART grade so ausreichen.
Jim M. schrieb im Beitrag #5963047: > Moderne µC haben gerne mal Laser-getrimmte RC Oszillatoren, die für UART > grade so ausreichen. Was willst du mit dem unqualifierten Blabla jetzt aussagen?
-
Thread
Kommunikationsprobleme mit UART
Man kann den internen RC-Oszillator kalibrieren, das ist dann einigermassen genau genug für UART, wenn die Temperatur nicht zuviel schwankt (sagen wir +/-20K). Das Register OSCAL ist dein Freund. MFG Falk
aufweist. Garantie richtig gibt es selten, aber in diesem Fall kann man wohl davon ausgehen, dass die UART eines PC keinen allzugroßen Fehler haben wird. Also wird man wohl jedes der unbekannten Geräte mit einem PC verbinden und nachsehen, ob sich dort bei einem der beiden (oder bei beiden) Fehler in