-
Thread
UART arbeitet bei Codeänderung nicht mehr, ATmega16
Der interne Oszillator ist zu ungenau. Ohne Kalibrierung ist er ungeeignet zum Takten einer UART. Die Kalibrierung sollte der Controller regelmäßig selbst gegen eine Taktreferenz vornehmen. Die Alternative ist
Peter Diener schrieb im Beitrag #2166330: > Der interne Oszillator ist zu ungenau. Ohne Kalibrierung ist er > ungeeignet zum Takten einer UART. Die Kalibrierung sollte der Controller > regelmäßig selbst gegen eine Taktreferenz vornehmen. Die Alternative
-
Thread
LCD Display Off - On - Befehl
F_CPU passen, sonst stimmen die Zeiten nicht. Steht aber irgendwie alles im Tutorial... Einen internen Quarz gibt es nicht, nur einen internen Oszillator.
hängt da aber nicht am Clockeingang, sondern an einem Interrupt. Der AVR selbst wird mit dem internen Oszillator getaktet. Dementsprechend werden die Fuses auf den internen Oszillator eingestellt.
-
Thread
AVR Board von Pollin
Der interne RC-Oszillator ist halt nicht so genau. Ich glaube mich dunkel an bis zu 10 Prozent Fehler zu erinnern. Kann mich aber auch täuschen. Gruß Gerd
: Eine Baudrate mit (zu) hohem Fehler heißt nicht, dass wenigstens noch irgendein Datenmüll ankommen MUSS! Es kann sein, dass das Stopframe bedingt durch die Hohe Fehlerrate nicht mehr erkannt wird. Dann wird das komplette UART-Datenpaket
-
Thread
UART Test SDK500 --- Problem
dannach konnte Zeichen Zeichen Übertragen, welche anschließend Empfangen wurden. Verwende den internen Oszillator des Boards. Welche Settings muss ich bezüglich der Taktrate machen? Danke für die Antworten =)
Sepp Horst schrieb im Beitrag #2425484: > Verwende den internen Oszillator des Boards. Welche Settings muss ich > bezüglich der Taktrate machen? Du musst die richtige Fuse-Kombination wählen: Der S*T*K-Oszillator gilt als externer Oszillator, nicht als RS-Dingsbums
-
Thread
RS232 macht mich kirre
Was gibst Du dem fuer Tips? UART und interner Oszi ist mal ueberhaupt keine gute Idee (zu ungenau). Matthias: Schau mal ins Datenblatt unter UART, da sind Tabellen, welche Baudraten mit welchem Quarz welchen Fehler erzeugen.
> Ist übrigens Quatsch von Linuxgeek. Der interne Oszillator ist auch nicht ungenauer als 3%. Ja. wenn man ihn kalibriert- kann man im DB nachlesen. Der Tipp, eine UART mit internem Oszlllator zu betreiben, schreit geradezu nach Wiedereinführung
-
Thread
Verständnis Baudraten berechnung
meinem code oder am Aufbau liegt! Wenn dann alles klappt wird selber programmiert :) wenn ich den UART im griff hab kommt ein UART bootloader, dann ein can bootloader ;) > 3. Im vorliegenden Fall, mit 8% Fehler, wird der Code wohl i.A. > funktionieren, es ist bloss nicht so gut wie er sein könnte
Marc S. schrieb im Beitrag #4419234: > Im Moment läuft er noch mit dem internen 8MHz > Also baud=8000000/... W.A. schrieb im Beitrag #4419321: > Bei der Angabe 8000000 für die Taktfrequenz entspringen fünf Nullen der > reinen Phantasie. Beim /internen/ Oszillator darf
-
Thread
ATMEGA32A UART Problem
Forum bemühen, um eine Klärung meines Problems zu bekommen. Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator. Leider bekomme ich in Minicom kein Zeichen. Obwohl im regelmässigen Abstand auf der TXD Leitung ein kurzzeitiges Signal erscheint. Ich habe leider keinen Oszi, um nähere Hardwareuntersuchungen
Hi >Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator. Schlecht. Der interne Oszillator ist für serielle Kommunikation nicht sonderlich geeignet. Nimm einen (Baudraten-) Quarz. >usart_transmit: ... >reti Unterprogramme
-
Thread
RS232 an UART
Läuft dein AVR mit internem Oszillator ? Evtl. ist dann der Fehler zu groß.
geschaut ? Z. B. beim ATmega16 Seite 162, Tabelle 68 ? Alles größer 4800 Baud @ 1MHz produziert Fehler > +- 7%. Das kann nicht funktionieren !! Für eine fehlerfreie RS232-Übertragung muß der Fehler deutlich unter 1% liegen. Wenn du allerdings den Oszillator auf 8MHz stellst, sind 38k4 Baud problemlos
-
Thread
Taktquelle ändern
MCs zu verändern, daß dieser bspw. zunächst durch einen Quarz getaktet wird und dann durch den internen Oszillator z.B. durch einen Interrupt?! Hoffe die Frage ist nicht allzu blöd...
-40 und 125°C Der AT90CAN hält diese Temperaturen aus...ein Quarz leider nicht. Deshalb muss der interne Oszillator herhalten. Um aber die Messdaten nach den Messungen via UART zum PC zu schicken brauche ich (soweit ich das hier in dem Forum gelesen hab) einen möglichst genauen Takt und den kriegt man
-
Thread
Dringendes Problem mit UART+Baudrate.
Klemm man den Quarz ab, dann sollte gar nichts ankommen. Wenn doch was ankommt dann ist noch der interne RC-Oszillator mit 8 MHz aktiv. MfG Falk
gar nichts aus. Und die Auswahl der Taktquelle geschieht eben über die Fuses. Wenn die Fuses auf "interner RC-Oszillator" stehen, ist es dem µC völlig egal, ob da extern ein Quarz dranhängt oder nicht.
-
Thread
EEPROM Daten lesen Problem
des EEPROM liegt. Habe mal das EEPROM an nur einer Stelle ausgelesen (dort wo der Fehler war). Der Fehler war immer noch da. Also wird es wohl nicht am EEPROM lesen und Uart liegen. Folglich muss es wohl mit dem Schreiben zusammenliegen oder auch am Strobe-Signal. Habe die wichtigen
Welchen Oszillator benutzt du? Internen RC-Oszillator oder Quarz-Oszillator? Der interne RC-Oszillator ist sehr ungenau (stark spannungs- und temperaturabhängig) -> Unkorrekte Baudrate beim UART -> fehlerhafte
-
Thread
Wofür braucht man 14.7456 Mhz Quarz?
. Je weniger Bits zum Rahmen gehören, desto schneller ist "man fertig", ehe die Taktunterschiede Fehler prvozieren. ...
ich in solchen Fällen immer, wenn jemand aus einem Ingenieurbüro seine Meinung vertritt, dass der interne RC-Oszillator für solche Sachen genau genug sei...
-
Thread
RS485-USB-Baudratenproblem
Die AVRs kommen von Haus aus mit einem Vorteiler zur Welt, beispielsweise interner Oszillator 8MHz, Takt aber nur 2MHz oder 1MHz. Baudrate berechnet auf 8MHz ist dementsprechend falsch. Siehe Fuses. 9600bd sind ab 2MHz oder einem Vielfachen davon kein Problem (clk/13).
A. K. schrieb: > Die AVRs kommen von Haus aus mit einem Vorteiler zur Welt, > beispielsweise interner Oszillator 8MHz, Takt aber nur 2MHz oder 1MHz. > Baudrate berechnet auf 8MHz ist dementsprechend falsch. Siehe Fuses. > > 9600bd sind ab 2MHz oder einem Vielfachen davon kein Problem (clk/13).
-
Thread
usart anfänger probleme
ich habe nur den internen RC-Oszillator und einen externen 8mhz quarz. kann ich also damit vergessen UART zu benutzen?
> ich habe nur den internen RC-Oszillator und einen externen 8mhz > quarz. > kann ich also damit vergessen UART zu benutzen? Es wird sich mit Sicherheit wieder jemand finden, der behauptet, dass es bei ihm ohne Baudratenquarz
-
Thread
Externer Quarz notwendig?
Beitrag #5191593: > Brauchen die inzwischen immer noch einen externen Quarz, oder sind die > internen Oszillatoren präzise genug geworden? Der interne Oszillator ist ein R-C Oszillator und mit 3% bei 25°C angegeben. Da ändert sich auch in Zukunft nichts, wenn die Genauigkeit nicht reicht, dann
Für serielle UART Kommunikation brauchst du mindestens einen Keramik-Resonator. Der interne R/C Oszillator eignet sich nicht zuverlässig. Für USB brauchst du einen Quarz.
-
Thread
ATmega328PB nach Berührung Flash kaputt
Der Umstieg auf den internen Oszillator ist bei diesem Produkt leider nicht möglich, da ich die 16MHz brauche. BrownOut Detection ist an (1.8 oder 2.7V, bin gerade nicht sicher) Der Inhalt des Flashes ist zerstört und lässt
Poste mal den Schaltplan und die Layoutfiles. Ich vermute du hast einen PortPin an Masse und interne PullUps an.
-
Thread
AVR - Taktfrequenz für Seriell ohne Handshake
bei den neuen AVRs (tiny0/1/2 und neuer) den UART mit internem RC-Oszillator zu nutzen, der ja auch ein paar Prozent Abweichung im Temperaturbereich haben kann.
> Zumal es ja allgemein akzeptierte Praxis ist, bei den neuen AVRs > (tiny0/1/2 und neuer) den UART mit internem RC-Oszillator zu nutzen, der > ja auch ein paar Prozent Abweichung im Temperaturbereich haben kann. Aber eben deutlich weniger als die Classic-Teile. Außerdem kann man mit dem dort
-
Thread
UART mit STK500 und internem Quarz
Problem. Du empfängst gar nichts. Wenn die Taktfrequenz etwas zuviel daneben liegt (wie es beim internen Oszillator schon sein kann), dann empfängst du was. Nur sind die Zeichen falsch. Aber kommen wird was. > Frage dazu: Wieso funktioniert die Übertragung nicht? Habe das Kabel > natürlich auch
ersteinmal danke für die Antwort. Ich schaue hier nochmal im Forum weiter nach Problemen, die mit UART aufgetreten sind. Den Taktfrequenztest habe ich nicht gemacht, da ich ersteinmal mit dem internen Oszilator Zeichen empfangen möchte, auch wenn es ungenau ist. Mit C-Code meinte ich den von mir
-
Thread
Problem mit serieller Datenübertragung und ATtiny13
Übertragungsfehler, bei der Ausgabe von Text, deswegen > 1000. Aha. Lass mich raten. Kein Quarz, interner Oszillator? (Geh deinen Übertragungsfehlern auf den Grund. Bei 9600 darf es keine Fehler geben.)
Der interne RC-Oszillator des Tiny13 geht nach der Blankenheimer Sonne... Für'n Quarz wird es mit den Pins eng. ...
-
Thread
serielle Schnittstelle ATMega8 | TeraTerm | falsche Zeichenübertragung
Controller auch wirklich mit 1MHz? Hast du einen Quarz > dran? > > Sascha Er lief mit den internen 1Mhz, hier lag wohl auch der Fehler... nun mit 8Mhz externem Quarz funktioniert die Kommunikation. holger schrieb im Beitrag #4782907: >>Höchstwahrscheinlich sendet dein uC mit 19200B. > >
Markus E. schrieb im Beitrag #4782912: > Er lief mit den internen 1Mhz, hier lag wohl auch der Fehler... nun mit > 8Mhz externem Quarz funktioniert die Kommunikation. Schön dass du ein Feedback auf unsere Lösungsvorschläge bringst. Muss mal gesagt werden da
-
Thread
R8751H Vintage Clock Basteltagebuch (War: [8051] XTAL1 und XTAL2)
dass ich erstmal nur einen AT89C51-RC benutze. Warum nicht den AT89LP51RD2-20PU? Der hat einen internen Bootloader über die UART. http://ww1.microchip.com/downloads/en/devicedoc/atmel-3714-microcontroller-8051-at89lp51rd2-ed2-id2-datasheet.pdf
nicht unter 3,5MHz betrieben werden, da intern DRAM. Mit EPROM würde ich nichts mehr machen, interner Flash über UART ist viel bequemer.
-
Thread
AVR Prozessortakt halbieren
µC dann automatisch auf seinen internen Oszillator um? Wenn nicht, könnte mir bitte jemand helfen auf den internen Oszillator umzuschalten?
Soweit mir bekannt haben die Atmels nur einen Teiler 1:1 oder 1:8 zwischen internem Oszillator und der sonstigen Interna. Wenn der interne Oszillator 8 MHz hat, kommen nur 8 oder 1 MHz infrage. Wenn ich den TO richtig verstanden habe, soll der µP mit 4 MHz laufen. Zumindest mit
-
Thread
Übertragung von Daten aus EEPROM über UART:Müll
Hallo zusammen, ich habe wieder mal ein komisches Problem: Mein ATMEGA8 auf STK500 (mit 1MHz internem Oszillator betrieben) soll über den UART Daten nach HTERM (PC, XP Home) schicken. Bei einem Programm aus dem Tutorial klappt das genau dann, wenn ich den CLOCK-Wert im Programm auf 4000000/
Die internen Zeitgeber sind zu ungenau. Du kannst versuchen, den OSCCAL-Wert für den internen Oszillator bei 1Mhz oder 8Mhz anzupassen. Empfehlenswert wäre aber auf jeden Fall ein Baudratenquarz, wenn Du auch
-
Thread
G-Code-Interpreter und µStep-Controller mit ATmega644
Quarz zu GND benötigt. Dieses nennt sich dann "ext. Crystal Osc." in den Fuses. Wenn du einen Oszillator verwendest dann musst du folgendes tun: Oszillator V+ -> 5V Oszillator Takt -> XTAL1 Oszillator GND -> GND Die Fuses dem entsprechend ändern. Müsste "ext.Clock" oder "ext. CLK" heißen. Dann
Hallo Robert, Hast du nun den Fehler finden können? Gruß Steffen
-
Thread
µC nicht mehr ansprechbar
kann den µC immer noch nicht ansprechen. Warscheinlich weil der immer noch auf ein Signal vom internen Oszillator wartet? Wie schon geschrieben habe ich nur "SUT_CKSEL" auf "EXTCLK_6CK_64MS" gestellt. Wie kann ich den Atmega noch retten um ihn wieder ansprechen zu können?
>Wenn der Controller mit internem Oszillator läuft hat der >externe Quarz keinen Einfluss auf die Takterzeugung. Ja richtig! Darum >habe ich bei SUT_CKSEL die Option >EXTHIFXTALRES_16KCK_64MS ausgewählt Dies Option stellt den
-
Thread
Interner Oszillator genutzt statt Quarzoszillator ?
Hallo, Ich bin gerade dabei, mit UART und der seriellen Schnittstelle rumzuspielen am Atmega8. Ich habe aber das Problem, dass der AVR als Taktsignal den internen 1MHz Oszillator nimmt, statt dem externen Quartz. Die Fuses habe ich
Das glaube ich nicht, dass der Mega einen Teil aus dem externen Quarz und einen Teil aus dem internen Oszillator speist. Wie bist du denn darauf gekommen / wie hast du das gemessen?
-
Thread
UART liefert Mist...
Deinen Code näher angeschaut zu haben Folgende Dinge: Läuft der uC mit externem Quarz oder mit internem RC-Oszillator? Für Komunikation über die serielle solltest du eine Quarz verwenden. Der interne RC-Oszillator ist dafür zu ungenau. Was das (1<<URSEL)|(3<<UCSZ0) angeht: also in C ist das << ein
haste vergessen: .equ UBRRVAL = ????????????? Das Problem ist der Takt. Ich verwende auch den Internen Oszillator und kommt halt auf die Baudrate an, wie gut der ist. Bei 1MHz ist halt maximal 4k8 möglich und bei 8Mhz kannste noch 38k4 nehmen. Aber nur Vermutungen... gib uns Takt, Baudrate
-
Thread
Welcher Takt; 7,3728 MHz vs 8MHz
Pete K. schrieb im Beitrag #5129171: > Ich nehme immer den internen 8Mhz Taktgeber. Hatte noch nie > Probleme > damit. Bei 9600 Baud geht der ja auch problemlos mit dem internen Oszillator, dieser schwankt nämlich zwischen 7,4 und 8,4 MHz, je nach Temperatur
Bereich bei +/- 0.2%. Mit 8MHz Quarz sind demnach 2400, 4800, 9600, 19200 und 38400 ok. Der interne Oszillator taugt lediglich für Morsezeichen.
-
Thread
Einfachste USART ansteuerung funktioniert nicht.
Dann benutzt du also den RC-Oszillator!?! Wahrscheinlich reicht dessen Genauigkeit nicht für den UART. Auf deinen Platinenfotos sind doch so schöne Quarze und du verwendest sie nicht!
Thomas R. schrieb im Beitrag #2331731: > Dann benutzt du also den RC-Oszillator!?! > Wahrscheinlich reicht dessen Genauigkeit nicht für den UART. > Auf deinen Platinenfotos sind doch so schöne Quarze und du verwendest > sie nicht! Na ja, dass ist ne andere Sache - hab
-
Thread
FPGA synthetisierung
@ Vhdler (Gast) >Hat der clpd einen internen Clock? wenn ja wie schnell? Nein. UNd für DMX brauchst du sowieso einen Qaurz oder Keramikresonator. Siehe http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART#Senden >72 FlipFlops
takt liegt dabei bei < >83ns (worst case)....also KAUM verzögerung Spielt beim UART keine Rolle. >Seh eigentlich keinen Fehler und sollte funktionieren ?!? Mehr oder weniger. Nur weil du keine Fehler siehst, heisst das ncoh lange nicht, dass keine da sind. ;-) >Das ganze würde
-
Thread
wie mega32 auf externen oszillator schalten?
ich habe die asm datein hier von dem uart tutorial genommen. also 9600 baud. noch eine frage: wenn jetzt schon etwas beim terminal ankommt, kann man dann einen hardware fehler ausschließen? also dass ich die max232 schaltung richtig aufgebaut
External RC Oscillator = Wiederstand + Kondensator (sehr ungenau) Calibrated Internal RC Oscillator = Interner Takt External Clock = Externer Takt / Oszillator Steht aber auch im Datenblatt sogar mit Anschlußbild etc.
-
Thread
Problem atmega128
internen RC-Oszillator !!! Peter
Hi, UART und interner Oszillator geht schon mit dem AVR (Mega8/16). Allerdings sollte man das Calibration Byte setzen. Ich weiß nicht ob der Mega128 das auch braucht. Register heißt OSCCAL, zum Auslesen kann
-
Thread
UART Prob bei verschiedenen Taktfrequenz
Hey! Ich hab im Bascom AVR folgende Zeilen programmiert: $regfile = "m8535.dat" $crystal = 4000000 $baud = 1200 Do Print "Hello World!" Loop Allerdings hat es nicht richtig funktioniert. Daher habe ich die Taktfrequenz auf 1 Mhz geändert. Ergebnis: Alles lief Fehlerfrei! Ich benötige die Funktion aber bei 4Mhz. Kann mir jemand sagen warum es bei 4Mhz nicht funktioniert? Im Anhang habe ich ein Bildschirmmitschnitt von dem was das Terminalprogramm ausgespuckt hat. Danke schonmal!
-
Thread
ATMEL verändert einige Dinge im ATMega
im Beitrag #4438597: > Ich dachte auch, diese Variante wäre recht präzise (mir geht es nur um > UART). Da du ja im Bastelkeller arbeitest: Du kannst für den UART auch den internen RC-Oszilator probieren, ggf. kalibrieren. Hat bei mir bisher immer hingehauen und benutze ich immer für eigene Basteleien
Probleme mit einem M0 überhaupt > nicht Wann braucht man schon 20 Mhz... Das meiste ist auch mit 8 internen MHz locker bedient. Da nimmt man einfach die für UART hinreichend taktstabilen PB Typen, spart sich Quarz samit Kondis und gut ist.
-
Thread
Probleme mit UART bei Atmega 32
Guten Tag zusammen, ich habe einen Atmega32 (1MHz interner Oszillator) über die Spare-RS232 des STK500 an meinen PC angeschlossen und lasse vom Controller eine Zahl (z.B. 1) an den PC senden. Die RS232 am Computer steuere ich mit HTERM. Im Anhang dazu zwei
Dein interner Oszillator will wohl nicht so richtig (ist einfach sehr fehlerbehaftet). Tweake den Baudratenteiler mal vorsichtig um 1..2 hoch oder runter vom idealen Wert und geh noch weiter runter in der Baudrate
-
Thread
UART mit interner Taktung um ab und zu mal 2-3byte zu senden
Hallo Leute, ich möchte mit einem Mega8 und der UART ab und zu mal (vielleicht alle 3-4 minuten) mal ein Schaltsignal bestehend aus höchstens 2-3 byte senden. Dafür möchte ich aber nicht direkt einen Baudratenqaurz einsetzen sondern den internen Takt
aber nicht direkt einen Baudratenqaurz einsetzen Warum? Zu teuer? >sondern den internen Takt verwenden. Ist dies irgendwie sicher möglich. Jain. Man kann einen 32kHz Uhrenquarz verwenden, damit kann man den internen RC-Oszillator laufend nachregeln. Geht prima. Oder man empfängt von
-
Thread
MSP430: UART Verständnis/Problem
nicht zu hoch aus. http://mspgcc.sourceforge.net/baudrate.html Die Frage ist - ebenso wie beim internen RC-Oszillator vom AVR - wie stabil die Taktquelle läuft. Der Taktquellenfehler geht in den Baudratenfehler ein und das wird beim obigen Codegenerator nicht berücksichtigt; dort wird dieser Fehler
zusätzlich zum Absolutfehler wo n liegt. Letztlich kann man auch den temperaturabhängigen DCO Fehler (also den Absolutfehler oben) anhand von Bild 4-6 im User's Guide abschätzen. Zwischen -40°C und +90°C wandert f(DCO) von fast +25% mehr bis -25% (bei internem R im RC-Oszillator, externer R sieht
-
Thread
XMega mit 24Mhz
Das kommt auf die Baudrate an. Bei 115200 wirst du mit internem Oszillator sicher Probleme bekommen. Mit 9600 sollte es allerdings klappen. Gruß Skriptkiddy
Mit dem internen Oszillator habe ich als ich die ersten Muster bekommen habe problemlos daten mit 115200baud übertragen können bei verwendung der internen Oszillatoren.
-
Thread
Atmega1284p 128KHz ungenau
Die internen RC-Oszillatoren kann man für alle zeitkritischen Dinge vergessen. Die sind ungenau und driften mit diversen Einflüssen wie der Temperatur. Ich hab damit mal RS-232 probiert, kannste knicken. Sehr
das Datenblatt geprüft zu haben.... Üblicherweise, ist der WDT zu ungenau für eine Uhr. Der interne RC Oszillator (für den µC Takt) ebenso. Macht sogar u.U. mit der UART Probleme. Also macht es Sinn, den ATMega mit einem Uhrenquarz zu versehen, wenn man denn halbwegs genau mit der Zeit sein möchte
-
Thread
UART an Attiny2313
Ok hab's hingebracht. Hab mal den internen Oszillator auf 8MHz gelegt, und voila es funktioniert! Danke!
Beitrag #3431962: > eine falsche Baudrate eingestellt. silch12 schrieb im Beitrag #3431949: > internen Oszillator Oder das.
-
Thread
Problem mit I2C Slave-Software
Slave zeigt auf UART "-1" (ok) Master sendet 1. Byte - Slave zeigt auf UART "-2" (ok) Master sendet 2. Byte - Slave zeigt auf UART "-2" (ok) Master sollte STOP sende - Beim Slave passiert irgend wie nix - alles steht
interne Taktquelle (8Mhz) verwende? Gruß Bernd
-
Thread
Atmega8, UART@19,2 kHz
hast du ubbrh gesetzt? mit einem externen quarz probiert? manchmal ist der interne oszillator zu ungenau für u(s)art...
dort ein falscher wert drin steht, dann geht's nicht (auch nach einem reset den wert setzen) der interne rc-oszillator hat auch einen fehler und der kommt noch dazu (auch wenn der kallibriert werden kann). AFAIK: synchron und asynchron bezieht sich auf den bus. du hast an dem uart noch eine takt-leitung
-
Thread
AVR UART externe Quarze - Taktfrequenz - Pollin Board
Fehler vom Ozillator fehlt. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
schneller ;-) Edit End ich konnte bisher nicht feststellen, das externe Taktquellen stören wenn interner Takt genutzt wird. Allerdings habe ich im Kopf, das Atmel davor warnt die interne Taktquelle im Zusammenhang mit UART zu verwenden weil diese dafür nicht genau genug sind. Ich müsste mein Pollin
-
Thread
Erste Schritte RS232 mit ATMega, wer kann helfen?
Avr uart geht nur mit externem Oszillator, da der interne rc zu ungenau ist.
> Der Takt steht auf 3686400Hz (interner Oszillator) Beim m88 läuft der interne Ossi mit nominell 8MHz.
-
Thread
STM32 läuft mit Debugger schneller als er soll
muss man rechnen IMHO. Kommt ja eh komplett mit Quellen. Zufällig ist der Takt sicher nicht, der interne Oszillator der F3 ist immer 8MHz, mal 8 ergibt immmer 64MHz, und das vertragen die MCUs der F3 Baureihe auch.
rµ schrieb im Beitrag #5869484: > Zufällig ist der Takt sicher nicht, der interne Oszillator der F3 ist > immer 8MHz, mal 8 ergibt immmer 64MHz Für mein Programm ist der Takt zufällig. Vielleicht wird der Faktor morgen, oder für einen STM32F105, von 8 auf 4 geändert. Und was
-
Thread
Eisenbahnsteuerung mit Atmega16
Code entweder mit C oder Bascom. Nach einigen Versuchen habe ich bemerkt, dass die ausgabe über UART (+ MAX232) nicht so gut funktioniert. Manchmal kommen total unsinnige Zeichen im Terminal an(ich verwende Hterm, nicht Hyperterminal). Ich glaube, der interne Oszillator ist schuld, da er zu ungenau
wie du es eben lieber machst. > Nach einigen Versuchen habe ich bemerkt, dass die ausgabe über UART (+ > MAX232) nicht so gut funktioniert. Manchmal kommen total unsinnige > Zeichen im Terminal an(ich verwende Hterm, nicht Hyperterminal). Ich > glaube, der interne Oszillator ist schuld, da er zu
-
Thread
C# Serialport-Falsche Werte
ganz klar, denn anders als im klassischen C hibt es meines Wissens keine -1 als Fehlerrückgabe. Bei fehlern wird eine Exception geworfen. Wie wird der AVR betrieben? mit dem internen Oszillator, mit einem Quarz?
klar, denn anders als im klassischen C hibt es meines > Wissens keine -1 als Fehlerrückgabe. Bei fehlern wird eine Exception > geworfen. > > Wie wird der AVR betrieben? mit dem internen Oszillator, mit einem > Quarz? ja, mit interen RC-Osci. an uc liegt es nicht ich kann die Daten durch printf
-
Thread
Seriellübertragung (uart) mit instabilem Takt
erneut probiert. Fazit: Geht irgendwie, aber ist anscheinend nicht fein genug. - Atmega8 mit internem 2 Mhz Takt, Baudrate auf 9600 und dann per OSCCAL-Register den internen Oszillator nachjustiert, bis die Kommunikation klappte. Fazit: Geht besser, aber irgendwann gibt es Aussetzer oder der Rondostat
Andreas schrieb im Beitrag #3525350: > - Atmega8 mit internem 2 Mhz Takt, Baudrate auf 9600 und dann per > OSCCAL-Register den internen Oszillator nachjustiert, bis die > Kommunikation klappte. > Fazit: Geht besser, aber irgendwann gibt es Aussetzer oder
-
Thread
UART teilweise nicht komplett übertragen
Hi Leute, ich benutze einen UART, das Daten senden an den PC geht auch super, aber es kommt nach dem Resetten des µC sehr leicht zu massivsten Fehlern. Ich habe die Funktionen: [code] void uart_init(void) { // Baudrate
reinsetze Wo setzt Du das denn rein? Ulf schrieb im Beitrag #2228066: > mega644p, der mit dem internen Quarz von 8Mhz Einen *internen* Quartz gibt es bei AVRs nicht! Vermutlich meinst Du den internen RC-Oszillator. Der ist allerdings für die Benutzung der UART eher ungeeingnet, da viel zu ungenau
-
Thread
[S] Low-Pin Count MC mit USB-HID
CAN-FD, der sich aber in einem gewissen Package nicht nutzen lässt, nur weil die Pins für den Quarz fehlen. Der interne Oszillator ist für CAN zu schlecht, es würde nur bei bestimmten Betriebsbedingungen zufällig funktionieren. Also selbst bei den „Etablierten“ gibt es unsinnige Varianten. Nicht falsch
Harald A. schrieb im Beitrag #8014319: > Der interne Oszillator ist für CAN zu schlecht, Hat der keine andere Möglichkeit? Externen Oszillator? LSE Quarz und MSI mit PLL vom LSE stabilisieren? MSI/HSI per Software über einen Timer kalibrieren?