-
Thread
STM32F0 Discovery und UART1
Zur Abweichung vom Quarz (oder dem internen Oszillator) kommt noch die Abweichung bei der Bautraten-Generierung dazu. Nähres sollte man dann im Manual nachlesen können. Eventuell lohnt es sich auszurechnen, wie genau der Baudratengenerator
[UART_RX[uart].wr_ptr]=wert; UART_RX[uart].wr_ptr++; } if(wert==RX_END_CHR) { // wenn Endekennung empfangen UART_RX[uart].rx_buffer[UART_RX[uart].wr_ptr]=wert;
-
Thread
SMD Quarzoszillator 5V? Welchen verwendet ihr? Stromverbrauch?
Sieht es mit einem Quarz und der > Kondensatorbeschaltung besser aus? Der Stromverbraucht vom internen Oszillator hängt natürlich vom µC ab was einen Quarz oder Keramikresonator betrifft). Man kann aber meistens davon ausgehen, dass der interne Quarz üblicherweise um Größenordnungen sparsamer ist
Frequenz, umso mehr Strom - Umso höher die Spannung, umso mehr Strom - Stromverbrauch: Uhrenquarz < interner RC < Quarz < Quarzoszillator Ich nehm gehrne den internen RC für den Systemtakt, für genaue Zeitbasis den Uhrenquarz. Geht natürlich nicht imme (z.B. nicht für eine UART). Sonst eigentlich immer
-
Thread
Grundlagen UART: TX & RX Fehler
Hallo! Ich versuche gerade die TX & RX-Fehler einer UART-Kommunikation zu verstehen. Das mit dem RX verstehe ich ja noch, dass wenn der Empfangstakt nicht 100% stimmt es zu Fehlinterpretationen des empfangenen Datenstroms kommt. Warum in einigen
Icke schrieb: > Warum in einigen Datenblättern auch ein > TX-Fehler angegeben ist verstehe ich jedoch nicht. Wenn bei einer Takterzeugung für eine UART beispielsweise 1,3% Fehler drinstehen, dann heisst das nicht, dass 1,3% aller Bits oder Bytes fehlerhaft sind,
-
Thread
ATTiny85 - Software UART Probleme
wählbarer Wert, sondern ein Konstante, die der echten CPU-Taktfrequenz entsprechen soll/muß. Mit internem RC-Oszillator und (ab Werk gesetzter) DIV8-Fuse, läuft der Tiny85 mit knapp unter 1MHz. Das ist der richtige Wert für F_CPU.
Carl D. schrieb im Beitrag #4741732: > Mit internem RC-Oszillator und (ab Werk gesetzter) DIV8-Fuse, läuft der > Tiny85 mit knapp unter 1MHz. Das ist der richtige Wert für F_CPU. Stimmt, im Datenblatt steht: "The device is shipped with CKSEL
-
Thread
AVR32 AT32UC3C0512C Bootloader Frequenz
Ja laut Datenblatt macht die CPU bis zu 66 Mhz, und bis 33 Mhz ohne wait states für das interne flash. Handbuch auszug "• Up to 49 DMIPS Running at 33 MHz from Flash (0 Wait-State)" Ausserdem benutze ich 4 Usarts, wenn ich eine andere Frequenz benutze läuft der Usart ohne Fehler .
da ist noch einiges dazwischen... Hast Du wirklich Übertragungsfehler oder ist das nur der Fehler, der auf dem Papier steht. Normalerweise können UARTS mit einigen Prozent an Abweichung von der nominellen Frequenz durchaus umgehen. Da dürfte noch was anderes im Argen sein... Ich hab' bei
-
Thread
Baudrate geringfügig ändern
wird. Deine Anwendung fordert 11.1% Fehler.
du schreibst doch dass du UART selbst implementiert hast, dann kannst du doch auch irgendwelche timer/schleifen anders einstellen sodass der gewünschte Fehler entstehT?
-
Thread
USART Routine von ATMEL
>Den ATmega8 hast du auch umgestellt vom 1-MHz-RC-Oszillator auf >externen Takt, ja? ? Hab den internen Takt der STK 500 mit 3,86....
Matthias wrote: >>Den ATmega8 hast du auch umgestellt vom 1-MHz-RC-Oszillator auf >>externen Takt, ja? > ? Hab den internen Takt der STK 500 mit 3,86.... Woher weiß das aber dein ATmega8? Den interessiert das einfach gar nicht, was an seinem XTAL1 passiert, solange
-
Thread
STM32 USART1 IT Bytes verlust
4 und 5 lassen sich durch niedrige Baudrate ausschließen. Der erste Weg wäre für mich, die Uart-Infos auszuwerten. Die sagen, ob der Empfangspuffer überlief oder Parity/Framing falsch war. Der zweite Weg wäre, bei immer gleichen Testdaten schauen, ob es immer gleiche Fehler sind.
heißt deren 'PLL') gelieferte Takt für den USB zu sehr jittert, weswegen der Hersteller rät, den internen RC-Oszillator zu verwenden, da dieser weniger jittert als der aus dem Quarzoszillator per FLL gewonnene Takt. Da der RC-Oszillator aber insgesamt nicht frequenzstabil genug ist, muß er zuvor anhand
-
Thread
Drehzahlmesser ansteuern
Matthias S. schrieb im Beitrag #5196716: > Kann also sein, das der MC mit seinem internen RC Oszillator > läuft und ein wenig daneben liegt... Ist sicher so, die Xtal-Pins sind andersweitig verwendet. Die internen Oszillatoren bei den STC Controllern sind aber ziemlich genau.
hinz schrieb im Beitrag #5196873: > Die internen > Oszillatoren bei den STC Controllern sind aber ziemlich genau. Das heißt, die 10% Abweichung ist super stabil? ;-)
-
Thread
USART Frage zu Bibliotheken
Moeglicherweise hast du keinen Quarz sondern den internen RC Oszillator verwendet. Der waere dann zu ungenau. und macht solche Fehler, von Bitverschieben. Zweitens war der Mega8 die falsche Wahl. Der hat nichts, der kann nichts. Ich wuerde eher etwas in
werde ihn mir anschauen. Der Tipp das 1Mhz nicht gut sein soll bzw. generell irgendetwas mit dem internen Oszi nicht stimmt und das die Fehler verursacht ist genau richtig gewesen. Ich habe die Fuse-Bits so angepaßt das der interne Takt bei 8Mhz läuft und siehe da es geht nun auch mit der Lib. Auch
-
Thread
UART mit ATmega16
Hallo, ich würde gerne eine verbindung zwischen dem ATmega und meinem PC aufbauen, sollte ja mit UART gehen, aber am PC kommen keine daten an. Ich hab gelesen man brauch einen Quartz damit UART funktioniert, allerdings hab ich keinen. Wie kann ich eine UART verbindung zum FTDI chip und folglich dann
, welcher Unterschied zwischen 'absolutem Fehler' und 'relativem Fehler' besteht und in welche Kategorie eine Prozentangabe fällt. Dass es ohne Quarz auch geht, ist unbestritten. Unbestritten ist aber auch, dass gerade Oszillatoren in den älteren
-
Thread
Abschlussprojekt
> aber was meinst du mit dem Quarz? Mit welcher Taktfrequenz wird der Prozessor betrieben. Interner RC-Oszillator, Quarz, Oszillator, eventuelle DIV8-Vorteiler gesetzt? >> Wie sagtst du denn deinen Mitstreitern was sie steuern sollen, einigt >> euch auf die Schnittstelle (Variable oder Funktionsaufruf
um den Controller zu programmieren. > Mit welcher Taktfrequenz wird der Prozessor betrieben. Interner > RC-Oszillator, Quarz, Oszillator, eventuelle DIV8-Vorteiler gesetzt? Auf dem Board ist ein 16MHz Quarz bzw externer Quarz also. > Wenn ich Dir sagen, ich habe ein Modellauto und Du sollst
-
Thread
AVR-Tutorial: Equipment wird nicht erkannt
einen pullup und evtl einen c. wenn der µc noch nicht geflashed wurde sollte er eigentlich den internen oszillator benutzen (datenblatt checken), ansonsten könnte es noch sein das du einen externen oszillator verwendest der einen (pullup?) am derzeit unbenutzten pin benötigt (enable). dann kann es
Der Controller ist noch "jungfräulich"? Dann dürfte da ja der interner Oszillator laufen. Schmeiss einfach mal alles ausser der ISP und der Versorgungsgeschichte runter und probier es noch mal.
-
Thread
Probleme mit Variablen oder Timings
1; unsigned fUp:1; } flags; der punkt ist: auf dem mega16L im STK500 gehts jetzt (mit internem RC oszi). auf meinem ATmega8 hat sich nichts verändert, sowohl nicht mit externer clock als auch nicht mit internem oszillator. ich werd mal versuchen die uart implementation direkt von winavr
@ Martin Krellmann (mkrelli) >auf dem mega16L im STK500 gehts jetzt (mit internem RC oszi). Und UART? Naja. ABer das diskutiere ich nicht mehr. >auf meinem ATmega8 hat sich nichts verändert, sowohl nicht mit externer >clock als auch nicht mit internem oszillator. >Ich
-
Thread
Basic für 80C31
der ist im 8031 nicht vorhanden. Auch die Autobaud-Funktion arbeitet mit dem Timer2. Weiterhin fehlen Dir 128 Bytes interner RAM, der 8031 hat nur 128, Basic braucht aber 256!
Sockel und den Molex, damit man den MC stromlos machen kann, bevor man > ihn rausnimmt. Der Oszillator ist für den Fall, das ich aus Versehen mal > den internen RC Oszillator verfused habe (gilt nicht für die AT89, weil > die immer externen Quarz haben) und am Molex stehen eben die bekannten
-
Thread
kann ich testen, ob meine Schaltung tut
jemand kommentieren, der die SW kennt. Mir kommt sie widersprüchlich vor. Entweder ich nutze den internen RC-Oszillator mit 8MHz _oder_ einen externen RC-Oszillator _oder_ einen externen Quarz. Aber Du könntest in der Zwischenzeit mal den Pegel an den RS232 Leitungen TX des uC kontrollieren. Sollte
Aus meiner Sicht wäre das Thema damit nicht erledigt. Wenn nämlich Dein uC wirklich mit dem internen RC-Oszillator betrieben wird, dann ist es (im wesentlichen) Zufall, dass der uC gerade am PC Deiner Tochter und an dem USB-RS232-Converter funktioniert. Der Punkt ist, dass der RC-Oszillator sehr
-
Thread
RS232 mit MSP430FG4618
DCO-Takt für die CPU. Wenn du einen hochfrequenten Quarz an den ACLK dran baust, musst du den Oszillator erst ma auf HF-Modus umschalten. Das geht per Programmcode. Mit JTAG hat das nix zu tun. Bei den alten MSPs war´s zumindest so, dass der X1 Oszillator standardmäßig für einen Uhrenquarz ist. Ist
MSP auf TX (Ausgang) vom PC legst. Bei RX demzufolge genauso. Desweiteren musst du den XT1-Oszillator auf HF-Quarz einstellen, wie das bei den neuen MSPs geht, weiß ich nicht, schau mal in den User Guide. Du solltest auch die zu deinem Quarz passenden Last-Kapazitäten einschalten, bzw wenn die internen
-
Thread
MAX3232 "sendet" endlos ein 70-100kHz Signal ohne Einkommende Daten
Das Problem habe ich am MAX3232 auch schon gehabt. Da spricht der interne Oszillator auf die Eingänge über. Begünstigt wird das durch Flussmittelreste zwischen den Pads. Mach die Platine mal mit Leiterplattenreiniger sauber (notfalls Isopropanol oder Spiritus)
Da kann es bei offenen Ein-/Ausgängen passieren, daß die entweder oszillieren oder Störungen vom internen Oszillator (Ladungspumpe) aufnehmen. Es sollte nichts offen sein. Schließ mal die Ein- und Ausgänge der beiden D's mit Widerständen ab. Im realen Betrieb ist ja auch alles angeschlossen. Vielleicht
-
Thread
UART: Statt 'T' ein 'g' ???!!!
machst du das ganze mit c oder in asm ? externer qartz oder interner oszillator ? hast du mal andere sachen gesendet und die richtig empfangen ? von hier aus mit den wenigen Fakten die du mitgeteilt hast lässt sich schwer sagen woran das liegt. Das ist in etwa
Wenn du mit internem Oszillator arbeitest, sollte klar sein woran das liegt oder? Wahrscheinlich noch nichtmal das Calibration Byte gesetzt oder? Setz das Kalibrierungs-Byte, nehm ne niedrigere Baud-Rate oder nen externen
-
Thread
LED Tisch mit Berührungs-/Gegenstandserkennung
zur Synchronisation, so braucht es auch keine Adressierung der Pixel, und auch keinen 2. (Software-)UART. Wenn ihr UART verwenden wollt, solltet ihr unbedingt eien Quarz vorsehen, daß der interne Oszillator dafür zu ungenau ist, ist kein Gerücht. Da beim UART nur ein mal, an der vorderen Flanke des Startbits
mal geschrieben: Für UART ist ein Quarz/Keramikresonator zwingend erforderlich, der interne RC-Oszillator ist zu ungenau, UART hat da, da nur 1x Pro Byte synchronisiert wird, zu wenig Spielraum. Man könnte naturlich auch SPI-Schnittstellen
-
Thread
ATMega 8 mit 1,8432Hz Quarz für RS232
Hallo, ich habe eine Schaltung aufgebaut und anfänglich mit der internen Freq von 1 MHz probiert. Auf RS232 war zwar mit dem Oszi was zu sehen aber per minicom kam nicht. Habe gelesen dass die interne Freq recht stark schwanken kann, Temperatur & Co., damit RS232 Problem
Das ist Quatsch, das ist keine Konfiguration für einen Quarz, sondern für einen externen RC-Oszillator. [/code] Dann habe ich mit fuse l 66 und h d9 den typischen Fehler gemacht. Da wäre wohl -U lfuse:w:0xde:m -U hfuse:w:0xd9:m besser? Sind 1,8432MHz schon high freq oder medium? "...Wenn
-
Thread
ATMega128 und UART1 Problem
Du musst den ATmega128 mit der Fuse auf externen Takt stellen, sonst läufst du auf dem internen Oszillator. Steht übrigens auch in der avr-libc-FAQ. ;-)
? Gruß, Magnetus P.S.: Ich such mal noch ein wenig weiter nach Fehlern... ;)
-
Thread
uart Kommunikation
// Reale Baudrate #define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler. #if ((BAUD_ERROR<990) || (BAUD_ERROR>1010)) #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! #endif /* Main - a simple test
Hallo! Der interne RC-Oszillator könnte etwas daneben liegen, der PC ist da manchmal toleranter.
-
Thread
Timer genaue Zeit und entprellen
>internen vom STK500 8Mhz Der interne "Quarz" ist ein Oszillator, der mit 3,686 MHz läuft. Aus dem STK-500-Userguide: "The frequency of the software generated clock can be set from 0 to 3.68Mhz. The default
> ../uhr.c:130: warning: passing arg 1 of `uart_puts' makes pointer from > integer without a cast uart_puts erwartet einen Zeiger (auf den Anfang eines Arrays aus char). Stattdessen übergibst du ihm einen unsigned char. Das paßt überhaupt nicht
-
Thread
BLDC Controller mit STM32F103C8T6 Geschwindigkeitsbegrenzer in der .hex
Dr. Sommer schrieb im Beitrag #5990371: > Es gibt keine internen Quarze. Ohne gute Taktquelle dürfte so ein Gerät > nicht funktionieren. Doch. Zumindest bei ST hat ein Cortex-M4 einen internen Oszillator von 16MHz, HSI genannt, mit dem er auch startet. Einen
Nop schrieb im Beitrag #5990379: > Doch. Zumindest bei ST hat ein Cortex-M4 einen internen Oszillator von > 16MHz, HSI genannt, mit dem er auch startet Das ist aber kein "interner Quarz", sondern ein oller RC-Oszillator mit 3% Abweichung oder so. Und sowas haben praktisch alle Cortexe
-
Thread
Messdatenaufnahme mit ATTINY 45/85
begin r:=(eing div e); val:='0'+r; // spart 2 Byte Soft_UART_Write(val); eing:=eing - r*e; e:=e div 10; end; Soft_UART_Write(';'); end; als anhang der quellcode
UART (egal, ob HW oder SW) und interner Oszillator ist eine wackelige Angelegenheit. Funktioniert nur zuverlässig, mit konstanter Betriebsspannung, Temperatur und Oszillator-Kalibrierung. Würde, wenn wie
-
Thread
Testplatine für ATmega 2560 - Kondensatoren an jedem VCC/GND Paar ?
nehmen. Das meinte Stefan F. mit seiner Bemerkung. Aber bei 16MHz und 115200bps hast Du 2.1% Fehler, und das passt noch. Also kein Grund zur Sorge. Im richtigen Leben mit aktuellen Controllern gibts das Problem eh nicht mehr - die dort eingesetzten UARTs sind deutlich flexibler. Die AVR-Peripherie
Uhrenquarze. 2) Man kann Mikrocontroller bei Nicht-Gebraucht so schlafen legen, dass der Haupt-Oszillator abgeschaltet wird. Mit den zweit-Oszillator kann die Uhr (der Timer) in dieser Zeit weiter laufen. 3) Oszillatoren mit niedriger Frequenz brauchen weniger Energie, als Oszillatoren mit hoher Frequenz
-
Thread
Atmega8A UART sendet nur Müll
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) //Fehler in Promille, 1000=kein Fehler #if ((BAUD_ERROR<990) || (BAUD_ERROR>1010)) #error Systematischer Fehler der Baudrate ist groesser 1% und damit zu hoch! #endif #endif /* UART_H_ */ [/c]
Lars schrieb im Beitrag #5713275: > while (1) > { > uart_puts("Hallo"); Mach hier mal eine Pause rein, so ein Dauerfeuer verhindert eine Synchronisation auf einen Anfang, vor allem, wenn man Fehler finden will. _delay_ms(1000);
-
Thread
UART sendet nur Nullzeichen
Hallo, Ich habe mal wieder ein Problem... wahrscheinlich sogar ein sehr simples, aber ich kann den Fehler einfach nicht finden. Und zwar will ich über den UART Daten senden. Dazu habe ich folgende Funktionen aus dem Tutorial übernommen: [c] void uart_putc(unsigned char c) { while (!(UCSRA &
Zeit programmiert und auch damals die Fuses gesetzt. Ich hatte sie falsch gesetzt. Es wurde der interne Oszillator verwendet (1MHz), und jetzt läuft er mit echten 16MHz und ich bekomme lauter 'U's in HTerm. Anders: Ich könnte mir echt in den Ar*** beißen für so einen doofen Fehler... Ich danke
-
Thread
UART kann Daten nicht einlesen
...Codefetzen... Das ist kein vollständiges Programm. Mindestens main() und die Includes fehlen. Seitens der UART fehlt die Einstellung der Baudrate. > uint8_t uart_getc(void) Du liest hier bis zu fünfmal UDR direkt aus, und nur vor dem ersten Mal wartest du ob überhaupt ein Zeichen vorhanden
Baudraten debuggst. Keniff wrote: > also ubrr value wird über F_CPU berechnet. also über den internen quarz. > die frequenz steht bei 8MHz. Es gibt keinen internen Quarz beim ATmega16. Da ist nur ein Oszillator. Der ist für 9600 Baud im allgemeinen zu ungenau. Ein ständiges Thema beim Thema UART
-
Thread
Baudrate Mega128L 4Mhz intern geht 8Mhz intern nicht
Der interne Taktgeber (R/C, kein Quarz!)ist per Fabrik auf 10% genau. Für ein UART darf die Fehlerrate nur maximal 2% betragen. Man kann den internen Taktgeber auf 1% genau kalibrieren, diese Genauigkeit ist
alternativer keramischer Resonator wäre kaum billiger. Es ist somit doch völlig unsinnig, mit dem internen RC-Oszillator seine Zeit zu verplempern, sobald man den UART verwenden möchte. Auch irgendwelche sogenannten Baudratenquarze einzusetzen, ist doch Schnee von gestern. Ein Blick in die Baudratentabelle
-
Thread
STM32F103: bei UART1 remapped funktioniert der UART1 Interrupt nicht
auf der Platine zu finden. Laut diesem Post, sollte der Prozessor dann aber automatisch den internen Oszillator nehmen? https://www.mikrocontroller.net/topic/424084#4958849 Gruß hochsitzcola
schrieb im Beitrag #5616007: > Laut diesem Post, sollte der Prozessor dann aber automatisch den > internen Oszillator nehmen? Die Hardware enthält keinen Automatismus. Das müsste man ausdrücklich in Software implementieren.
-
Thread
Arduino Bibliotheken funktionieren nicht beim AVR128DB-Prozessor
Maxim B. schrieb im Beitrag #7637163: > Obwohl interne RC-Takterzeugung besser wurde, bleibt die Genauigkeit > schlechter als bei Quarz Aber ist inzwischen gut genug für's meiste. Insbesondere für die UARTs. > Wenn ein Gerät nicht nur im Zimmer
DB64 könnten wir aber damit einen seriellen Port wirklich gewinnen. Zwar ist dann USART-2 nur als UART nutzbar, d.h. nicht als z.B. zusätzliche SPI-Master.
-
Thread
Feedback zu meiner Schaltung
schrieb im Beitrag #7797553: > Was ist der genaue Grund? Wegen dem Bootloader oder wirklich für die > UART Schnittstelle? Beide!? Es sind doch beides UARTs. > Ich brauche keine Hohen datenrate, also die internen > 8 MHz (oder gar 1 MHz) reichen locker aus. Unwichtig. Es kommt auf die Präzision
programmiert, dafür muss C10=0 Ohm sein, es besteht aber falls nötig die Möglichkeit mittels bootloader UART1 mitzubenutzen, dann wird C10 =100 nF ) - Hinzugefügt: 4 MHz Quarz mit jeweils 22 pF falls es Probleme mit dem Internen Oszillator geben sollte. Das sind so die wesentlichen Änderungen. Dann
-
Thread
RFM12 - Funkmodul
welcher controller wäre dafür eurer meinung verwendbar, aus der atmel reihe!? eigenschaften. - 1 uart - 1 spi schnittstelle ( getrennt nutzbar) - möglich ein 8pin gehäuse!? - interner oszillator!? - baudrate: 19,2kbaud (oder einstellbar über ein paar switches - dann allerdings mehr pins nötig)
doch eher umständlich da der nur 1 Universal Serial Interface hat. Der Atmega hat ein spi und ein uart was die sache doch vereinfacht. Interner RC Taktgeber und uart verträt sich sowiso nicht. gruss Sven
-
Thread
Software-UART (AVR304) empfängt nur Müll
MHz. Du kannst im Prinzip in die gleichen Probleme mit Baudratenerror kommen wie bei einer Hardware-UART, d.h. z.B. ungenauer, temperaturabhängiger interner RC-Oszillator... Da ich die Initialisierung des Timers und die Taktrate des µC nicht sehe, kann ich das aber nur raten. Zum Ausrechnen sehe
bei den folgenden 8 einzelnen Bits. Bei 9600 Baud dauert 1 Bit ca. 104 µs, d.h. du kannst einen Fehler von +- 6,5 µs verschmerzen, selbst wenn er sich über die 10 Bits aufsummiert. Das sind wuchtige +- 6,25 % Toleranz bzw. +- 4,8%, wenn man auf alle 10 Bits rechnet! Bei einer Hardware-UART sagt man
-
Thread
JTAG ICE keine Verbindung zum Target
JTAG-Clones mit einem 7.38MHz Quarz getaktet. Vielleicht ist die Fuse des Mega16 auf dem JTAG auf "interner Oszillator" gestellt und es wird vielleicht trotzdem erkannt, wenn auch mit der falschen Baudrate. Aber das ist unwahrscheinlich.
JTAG-Clones mit einem 7.38MHz Quarz getaktet. > Vielleicht ist die Fuse des Mega16 auf dem JTAG auf "interner > Oszillator" gestellt ... Dadurch würde lediglich die UART-Kommunikation ausfallen. Das JTAG-Target wird aus dem JTAG-Interface getaktet, das stört überhaupt nicht, wenn das langsamer erfolgt
-
Thread
Uart und Hyperterminal geht nicht
) == 0 ) { uart_puts( "wie geht\n" ); uart_puts( "es ihnen\n" ); } } [/C]
> Es ist ein ATMEGA 32 mit internem Quarz Es gibt keinen ATMEGA mit internem Quarz. Nur einen internen RC-Oszillator und der ist wenn man ihn nicht mittels Oscillator Calibration Register kalibriert für eine Übertragung über die
-
Thread
ATMega32 Uart - Anzeige falscher Zeichen
resultiert wiederum fast immer aus einem falschen Takt. "Falsch" entweder im Sinne von "zu ungenau" (interner Oszillator?) oder von "andere Taktquelle als erwartet" (Fuses?).
. Sicher, dass ihr den Chip auf diese Baudrate konfiguriert habt? Warum ich frage: Klar, der interne Oszillator ist nicht so genau. Aber so daneben ist er auch wieder nicht, dass aus 1 gesendetem Byte 3 Bytes auf der Empfangsseite werden.
-
Thread
ATMega644 UART
Hallo zusammen, ich benutze einen ATMega644 und will daten vom ADC über den UART Senden. Leider kommt da nichts an. Mit einem ATMega32 funktioniert es ohne Probleme d.h. dass mein Terminal Programm richtig geschrieben ist und der Fehler am uC liegt. Die Register hab ich auch angepasst
Nach dem http://www.engbedded.com/fusecalc/ läuft der Atmega644 mit dem internen RC Oszillator und ohne die CKDIV8 Fuse. Damit solltest du den Wert für die Baudrate mit 8 MHz berechnen. Gruß JackFrost
-
Thread
ATMega328P vs ATMega328PB stürzt ab
müssen! Ja, 20MHz kann er! Aber nur mit einem extern zugeführten Takt! Nicht mit Quarz und internem Oszillator!
> Ja, 20MHz kann er! > Aber nur mit einem extern zugeführten Takt! > > Nicht mit Quarz und internem Oszillator! Achso. Intern ist klar - das will ich ja auch gar nicht. Okay, er kann also keine 20 Mhz mit Quarz, sondern nur mit Takt. Das ist schlecht. Was kann er denn mit Quarz, 16 Mhz? Gehen
-
Thread
UART- seltsamer Empfang
vertan, oder der µC-Takt stimmt nicht mit dem, was du zur Berechnung genommen hast. Kommt gern beim interne Oszillator vor... Ich denke das wird der Fehler sein...
kein Parity, kein Handshake. Baudrate gleich der Baudrate im µC im µC: entsprechende Baudrate, interner Oszi bei 1MHz, Programm aus dem UART Tutorial (Clock auf 1000000 geändert, schleife zum ausgeben der Zeichen zugefügt) Abder auch das unveränderte Tutorial Prog liefert nicht test! zurück Hat
-
Thread
Display Nokia 6110 Gesperrt
an den ATmega8L drankriege (beim DIP) da ja dort der RTC Quarz angeschlossen ist musste ich den internen RC Oszillator nehmen. Den kalibriere ich mit Hilfe des RTC Quarz auf 8064000Hz, also ganz ganz leicht overtuned. Allerdings eben weit besser geeignet für den UART Baudrate Divider. Ich hatte am Anfang
von Hause aus bei 5V auf 8Mhz justiert. Der Unterschied bei 3.1 Volt war gewaltig, aus Sicht des UART, statt OSCCAL 0xA0 wird jetzt 0xB0 benutzt. Nunmehr arbeitet der UART aber absolut in seiner 2% Grenzen perfekt. D.h. ich habe auf PC Seite eine Software die mit krummen Baudraten arbeiten kann und
-
Thread
Probleme beim Debuggen mit SW4STM32 und und F7Disco
> Wenn ein leeres Projekt mit minimalem Blink-Code auf einem ST-Board > nicht läuft, ist der Fehler wohl eher in der Hardware zu suchen. Davon gehe ich aus. Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob die Problemursache beim Oszillator liegt. > Oder willst du
Stefanus F. schrieb im Beitrag #5618595: > Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob > die Problemursache beim Oszillator liegt. Sollte dann aber nicht eigentlich nichts funktionieren, wenn der Fehler da läge? Ich bin immer noch
-
Thread
LED Zuleitungen reduzieren.
aber problemlos machbar. Als Kommunikationsprotokoll lässt sich alles nehmen. Ich empfehle einen UART mit niedriger Baudrate, wenn man das schon machen will. Dank niedriger Baudrate kommt man auch problemlos mit den internen RC-Oszillatoren aus. 1-Wire ist kompliziert und super langsam und hier soll
angewiesen ist, kannst du auf den Quarz problemlos verzichten. Ab Werk läuft der Controller eh mit internem RC-Oszillator; um den Quarz zu benutzen, müsstest du Fuses umprogrammieren. Solltest du später mal sowas wie RS-422 machen wollen, kann das ein Thema sein, aber für derartige Kommunikation hast
-
Thread
Brauche Hilfe bei ATMega8-16
habe ich eine schnelle Blinkfrequenz. Oder immer noch zu wenig! Ich habe auch noch einen 16Mhz Oszillator da!
ok habe nun den 16Mhz Oszillator angeschlossen, was muss ich jetzt tun, damit der uC wieder funtkioniert???
-
Thread
kann mal jemand über die schaltung sehen?
Michael Schröder schrieb im Beitrag #1856734: > Die Leitungen für uart hab ich nur für testzwecke mal rausgeführt, ist > der interne Tacktgeber auch für niedrige Baudraten (9600) noch zu > ungenau? Wenn der RC-Oszillator des uC statt 4MHz nur 3,6MHz ausgibt, dann ist
daneben liegt, gibt das auch bei 9600 die 10% Abweichung. Dann sind es sogar bei 300 wieder 10% Fehler. Klar soweit? Du könntest den Oszillator manuell auf die nötige Frequenz trimmen, dann funktioniert das für den gerade abgeglichenen uC...
-
Thread
AVR-Bootloader mit Verschlüsselung
internem RC Oszillator + PLL laufen, sind dann 16MHz. Den ATMega128 mit externem Quarz bei 15.97MHz. @Peter, ich habe noch mal in das ATmega168 Datenblatt geschaut und ich meine das ich keinen Fehler
Ja, bei 1-Wire und UseUartInvert=0 ist der interne Pullp aktiv. Bei 1-Wire mit UseUartInvert=1 ist er nicht drinne. Das hat tatsächlich Gründe in der Codegröße und dem Timing. Du kannst versuchen ihn am Anfang des Bootloaders
-
Thread
sicheres RS232-Protokoll für PC (Delphi) & AVR
Haste denn schonmal überprüft ob die Baudrate zum Quarztakt passt oder ist sogar noch der interne RC Oszillator am laufen?
einem Quartz bestückt, nur mit Quartz kann eine stabile RS232 Funktion gewährleistet sein, die internen Oszillatoren der AVR's haben da meist nicht genügend Stabilität. 2. Die Taktfrequenz des Quarzes sollte entsprechen gewählt werden, damit die Teiler im AVR auch auf die Baudrate entsprechend "sauber
-
Thread
ATTiny 2313 - externer Oszillator nötig ?
Richtig! Interner calibrierter Oszillator 4 MHZ oder 8 MHZ ... siehe Datenblatt auf www.atmel.com Ich bin feiern tschöö! Grüße Cpt
schnelle Frage. Ich möchte ein Nokia 3310 Display mit einem Attiny2313 ansteuern. Genügt dazu der interne Oszi oder brauche ich da einen bestimmten externen Oszillator? Habe bisher noch nicht mit dem SPI gearbeitet, daher hab ich keine Ahnung wie das abläuft. Muss da wie beim USART eine feste Taktfrequenz