-
Thread
attiny USI Slave Implementierung
DS2482-100 1-Wire Master, ATTiny45 (in EEPROM Version) als DCF77 Controller ATTiny45 -> 1MHz interner Takt aus 8MHz RC-Oszillator Der Tiny funktioniert als DCF77 Slave anstandslos, synchronisiert ohne Probleme und die Daten stimmen. Die Uhr und auch der 1Wire Bus funktionieren mit den Treibern
einen externen Quarz mit 16 Mhz anschliesse. Mal schaun, was passiert. Gerüchteweise soll ja der interne weniger stabil sein - und doppelte Taktfrquenz hilft vielleicht. Ansonsten werde ich (sollte kein systematischer Fehler vorliegen) wohl auf asynchrone Kommunikation umsteigen. Danke im voraus
-
Thread
Mega8 ISP nach Fusebits nicht mehr ISP-Programmierbar
keinen eigenen Takt des Kontrollers, daher geht es. external Osc. wohl einer der häufigsten Fehler, mit dem man sich aus dem Kontroller aussperrt. Der Kontroller erwartet hier einen von extern angelegten Takt, sein eigener Oszillator ist stillgelegt, daher geht ISP natürlich nicht, wenn nur
Zusatzinformation, die garnicht nötig war. Hoffentlich ist auch die richtige dabei. Dass bei internem Oszillator ISP nicht läuft, lässt darauf schließen, dass SPIEN falsch steht. Geht das Testprogramm mit internem Oszillator ?
-
Thread
Welche 32-Bit uC-Familie ist empfehlenswert?
intern. Ich habe gerade das Datenblatt von einem PIC32MX offen und die haben zwar einen LPCR Oszillator mit 31,25kHz eingebaut und haben einen Secondary Oszillator Anschluss für 32,768kHz, dem Block Diagramm nach kann man die aber nicht durch die PLL schicken. Dafür ist noch ein 8MHz Oszillator eingebaut
Core-Takt zu erzeugen. So im Gegensatz zum Beispiel zu einem ATSAMC21 bei dem man auch einen 32KHz Oszillator für die PLL benutzen kann. Nicht das ich das ernsthaft in Erwägung ziehe, meine Controller aus einem 32kHz Oszillator zu betreiben. > Dazu kommt die relativ hohe Stromaufnahme, > besonders
-
Thread
ATmega8A UART Problem
aber dann findet man sehr schnell heraus, daß es bereits bei 9600 Baud schwierig wird, mit dem internen Oszillator (und den verfügbaren Teilern) die notwendige Genauigkeit zu erreichen - so jedenfalls meine Erinnerung. Gehört zu den vielen, gern diskutierten Themen ... Siehe auch hier: http://www.mikrocontroller.net
Hitzewelle im Sommer kommt dann die Überraschung: Ihre Schaltung funktioniert nicht mehr, weil der interne Oszillator halt nicht besonders stabil ist. Du hast also genau die richtige Wahl getroffen - Glückwunsch zu Deinem Erfolg. Ich kann mich noch gut erinnern, als bei mir erstmals Zeichen vom AVR
-
Thread
DS1820 an PIC16F630 - Softwareprobleme, ich verzweifle!
Hallo Henrik, ja die richtige Baudrate ist eingestellt: 9600, 8, N, 1 Als Quarz nehme ich den internen 4MHz Oszillator, der ja hinreichend genau sein dürfte (+- 1%). Für Hilfen wäre ich sehr dankbar. Gruß Jan
Carsten Steiner wrote: > Hallo, > ich hatte schon das Problem, dass der interne Quarz (3,9 MHz) nicht > genau genug war MCs mit internem Quarz gibt es nicht. Die haben nur nen RC-Oszillator drin und der ist eben nicht mit einem Quarz vergleichbar. Peter
-
Thread
FPGA auf Microcontroller synchronisieren
Du brauchst die 4MHz µC im FPGA, vergiss den 30-40MHz Oszillator am FPGA erst einmal für dein Problem...
hinweg nicht mehr als +/-200ps auf. Ich war Gedanklich beim Delay und nicht mein Jitter (Mein Fehler)
-
Thread
Blutzucker-Messgerät Hardware OLED Display
ich hätte auch eine frage: hat der ATMEGA einen externen Quarz oder OSzillator, oder wird der interne benutzt. danke pcs
Eichhorn schrieb: > ich hätte auch eine frage: > > hat der ATMEGA einen externen Quarz oder OSzillator, oder wird der > interne benutzt. > > danke pcs intern
-
Thread
Compiler error: undeclared (first use in this function)
define BRATE 34 // 115200 Bd (BREGH=1) # define U_ENABLE 0x8008 // enable UART, BREGH=1, 1 stop, no parity # define U_TX 0x0400 //----------------------------------------------------------------------------- // Initialization of UART 2 module //----------------------
Oszillator passen, der in Hardware realisiert ist, also z.B. Quarz. Hast Du denn ein Schema? Die Default-Frequenz (für den internen RC-Osziollator?) entnimmst Du am besten dem Datenblatt.
-
Thread
osccal
Ein exakter Wert ist nicht möglich, da der interne Oszillator von der Spannung und der Temperatur abgängig ist. Nimm also besser einen Quarz wenn du den UART verwendest.
Fürs anfängliche Debugging stehen die Chancen nicht schlecht, mit OSCCAL einen UART-tauglichen Takt hinzubekommen - man muss nur dran denken dass Fehler dann auch daher stammen können. Für Produktionseinsatz hingegen ist davon dringend abzuraten. Wie: Per Programmer den richtigen
-
Thread
Welcher Timer ist für die Dauer eines Ticks im SysTick verantwortlich?
ja wohl eher nicht alle STM32 per Default auf den maximalen Takt konfiguriert sein, so aus einem internen Oszillator? Es werden aber auch nicht alle STM32 per Default mit 16MHz laufen? Oder sind die Default-Werte individuell für jeden Typ? Pro Familie wird das wohl eher auch nicht gelten, innerhalb
Du willst ne allgemeine Aussage? OK: Im allgemeinen wird (sofern vorhanden) zu allererst ein interner RC-Oszillator als Taktquelle benutzt. Sofern vorhanden, wird die PLL und der dazu gehörige schnelle VCO am Anfang _nicht_ benutzt. Gleiches gilt für einen externen Quarz oder sonstwie von außen zugeführtes
-
Thread
Bluetooth AVR ISP Programmer
daher empfehle ich den ATmega328P. Der Bluecontroller läuft intern mit 3,3V und 8 MHz Takt (interner Oszillator, kein Quartz). Er hat bereits Levelshifter eingebaut und kann so auch 5V Targets programmieren. Man kann natürlich auch jeden anderen Bluetooth Chip nehmen, es wurden ja bereits einige
zurück? Ich habe bisher immer eine RS232 Schnittstelle 115200 Baud sind kein Problem, sofern der interne Oszillator entsprechend auf die serielle Baudrate kalibriert wurde (und nicht auf 8 Mhz). Mit einen Quarz bzw. ohne Kalibrierung wird dies nicht stabil laufen, da die tatsächliche Baudrate dann 111111
-
Thread
STM32 - Erster Artikel
Meine Intension des Debug-Steckers war folgende: - Debuggen mit OpenOCD/JTAG - Debug-Ausgaben über UART auf Hyperterminal Ich habe mir einen eigenen Bootloader geschrieben, der kommt ohne das Interne Boot-ROM aus. Ich habe den in die ersten 8KB Flash programmiert. Das PC-Programm senden über den UART
MHz oder 72 MHz bei Nutzung von USB betrieben werden. (Stichwort Teiler :1 oder :1,5) Mit dem internen RC Oszillator kann maximal 48 MHz (für USB) erreicht werden. Um die CPU mit 72 MHz betreiben zu können wird ein externer Quarz verwendet werden. (z.B. 12MHz oder 8MHz)
-
Thread
AT89LP51ED2 flashen
Braucht es für das erstmalige FLIP flashen einen externen Quarz? Oder nutzt der Bootloader den internen 8 MHz Oszillator? Ab Wert ist laut Datenblatt die Fuse für externen 12 MHz Quarz gesetzt und die kann nicht mit FLIP auf den internen 8 MHz Oszillator geändert werden. Es ist also ein Programmer
klar zu sein, daß es ein ISP-Programmer ist. Damit kann man dann auch die Fuses setzen und den internen Oszillator für den Betrieb auswählen. Jetzt darfst Du aussuchen, was Dir lieber ist. Gruß Klaus (der soundsovielte)
-
Thread
ATmega8: UART Übertragung fehleranfällig
F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" .endif ; Stackpointer
receive_loop ; zurück zum Hauptprogramm [/avrasm] Ich verwende nicht den internen RC-Oszillator sondern einen externen Quarz. Dieser müsste eigentlich die geforderte Genauigkeit liefern.
-
Thread
FTDI FT232RL Übertragungsfehler
Danach ist erstmal alles wieder ok. Getestet habe ich bis jetzt mit einem ATTINY45 und Software UART und einem ATMEGA88 mit Hardware UART. Die Baudrate ist auf 9600 8N1 eingestellt. Vielleicht hat ja jemand eine Idee dazu. Danke und Gruß Phil
Zu was soll er denn sonst synchron sein? Denkst du, die bauen aus langer Weile noch ein paar Oszillatoren in den FTDI? Kaum. Der ausgegebene Takt ist direkt vom 48 MHz Oszillator abgeleitet, und damit ist die Übertragung zwischen AVR ud FDTI wasserdicht, selbst wen der Takt weglaufen würde. MFG
-
Thread
zwei µC über UART verbinden in Bascom
> Aber wer den Kopfkommentar der Listings liest, kann sich bestimmt > ein Bild machen. Die interne Taktfrequenz taugt nicht für stabilen UART-Betrieb. Mehr sollte ich ja nicht lesen ;-)
es nur Speicher weg. Es sind auch keine Erkenntnisse, die erhaltenswert sein würden. Außer, das interne Oszillatoren keine stabile Baudrate generieren, das ist aber schon ein alter Hut, gibt es nichts Erhaltenswertes. Vielleicht liegt es aber auch im Trend der Zeit. Bastler schrieb im Beitrag
-
Thread
AVR aus dem Powerdown Wecken, externe Alternative zu einer RTC?
Beitrag #2763075: > Dann solltest du einen Atmega48(p)a nehmen. Dann muss ich als Taktquelle den internen RC Oszilator verwenden. Wenn ich die Daten dann per UART an meinen Rechner übertragen möchte muss ich den RC-Oszilator dann mit Hilfe des 38kHz Quarzes kalibrieren. Bei der Alternative "Watchdog
Stefan schrieb im Beitrag #2763106: > Dann muss ich als Taktquelle den internen RC Oszilator verwenden. > Wenn ich die Daten dann per UART an meinen Rechner übertragen möchte > muss ich den RC-Oszilator dann mit Hilfe des 38kHz Quarzes kalibrieren. Das wäre sinnvoll, aber
-
Thread
ATmega644PA empfängt auf USART1 nur 0-Bytes nach 2 Min
Hardware ein Byte tatsächlich (merh oder weniger) empfangen hat. Prüfst du auch die Fehlerflags des UART? > oder muss ich den Fehler in der Software suchen? Wenn auf der Hardware die Signale tatsächlich am Pin ankommen, dann würde ich sagen: Ja, such den Fehler in der Software.
Was fuer einen Oszillator verwendest du, den internen RC, der mit der Temperatur weglaeuft ? Ja, ich hab vom Quarz gelesen, aber wurde der auch konfiguriert ? Ich wuerd einfach periodisch ein paar Bytes raussenden, und diesen
-
Thread
stk500 led6 led7 an den PortC, PortB leuchtet nicht
Sehr richtig, ein "Profi" erkennt seine Fehler und lernt daraus. Kopf hoch und weitermachen.
TOSC2) PB7 also wie jetzt? gibts die ausgänge nun oder nicht? laut schaltbild ist ja der interne oszillator mit diesen pins verbunden, und offenbar werden auch externe schwingkreise hier angeschlossen. aber warum sind die dann mit PortB beschriftet, wenn sie eigentlich für die oszillatoren da
-
Thread
Platinenkritik Hausbus/CAN Eingang
Ok, eine Transient-Voltage-Supressing Diode auf CANH/CANL ist sicher kein Fehler, beispielsweise NUP2105L.
Ich hätte noch ein paar Punkte über die du dir Gedanken machen solltest: - Oszillator Ich weiss nicht wie genau der interne beim STM32 ist. Rechne mal den Fehler aus der dadurch entsteht. Beim CAN Bus kann es schon mal passieren dass eine Nachricht aus 120 Bit bestehen. Kannst du
-
Thread
Taktgenauigkeit v. Quarz
Auch richtig gefused oder benutzt das Ding den internen RC-Oszillator?^^
Zahnpasta und > Bleistiftminen. Kommt auf die Anwendung an! Wir haben viele IO-Boards die nur über UART (per RS422) kommunizieren. Und hier sind 500ppm völlig ok. Die internen RC-Oszillatoren der STM32 sind nämlich oft genau einen Zaken zu ungenau für sowas *1). Da käme eine billige Taktquelle mit 1000ppm
-
Thread
PCA9557 Source Strom per Pin
I²C-Kommunikation mit dem PCA, solange alle Pins als Inputs (High-Z) konfiguriert sind – ich kann die internen Register (Output Port, Config) lesen und schreiben. Der Fehler (UART-Glitch und später auch I²C-Fehler wie ARBLOST) tritt erst auf, wenn ich versuche, einen Pin auf Output zu schalten. Meine Vermutung
in den Dateblättern / Google zu finden sind, erklärt das für mich nicht das totale abschmieren des UART. Es scheint mehr so, als würde der interne Oszillator des Tiny aus dem Takt kommen - allerdings habe ich gerade kein Oszi zur Hand und kann das nicht bestätigen. Ich hatte schon Probleme mit der 20MHz
-
Thread
Atmel Cortex-M3 (AT91SAM3S) mit GNU – nichts geht!
aber das sollte bei jemand, der eine dipolmarbeit schreibt, ja kein thema sein. btw: so einen fehler mit jtag-ice zu finden hätte ca. 1h gedauert. gruss gerhard
dort eher bescheiden. Zumindest dem nach zu urteilen, was ich gesehen habe. > btw: so einen fehler mit jtag-ice zu finden hätte ca. 1h gedauert. JTAG ist unterwegs. > > gruss > gerhard
-
Thread
[Atmega8 + STK500] UART-Probleme
// 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 /* UART-Init Bsp. ATmega16
2MHz; Start-up time: 6 CK > + 64ms" eingestellt. Vermutlich willst du eher /nicht/ mit dem internen RC-Oszillator arbeiten, wenn du eine exakte Frequenz haben möchtest. Der Generator auf dem STK500 ist aus Sicht des AVRs übrigens ein "external clock", wenngleich die meisten Einstellungen für
-
Thread
Keine RS232 Kommunikation bei CPU-Taktraten über 4 MHz
> Bei höheren Taktfrequenzen funktioniert aber nicht einmal 2400 Baud. In der Regel kann jeder uart bis maximale Quarzfrequenz/16, /32 oder /64. Bei glatten Quarzen passen die baudratn oft nicht. Der Fehler sollte <1% sein, über 3 geht nix mehr. Es gibt uart-Quartze, mit vielfachen von 115200
. Keine Fehler oder Aussetzer mehr.
-
Thread
Komisches Verhalten beim Programmieren
Alle AVR Mikrocontroller werden standardmäßig von einem internen R/C Oszillator getaktet. Erst durch Umstellen der Fuses mit einem Programmieradapter wird er ggf. auf eine externe Taktquelle umkonfiguriert. > Detected Micro does not match the Selected Micro
benötigt man dafür mittlerweile keinen Quarz mehr? Mittlerweile? Naja... Klar, für USB, CAN, UART, usw ist oft ein recht exakter Takt erforderlich. Dann Quarz. Aber sonst, laufen so ziemlich alle AVR auch gerne mit internem Takt Tipp: Das jeweilige Datenblatt mal studieren
-
Thread
AVR/Atmega8 an STK500 - UART/USART
Programm. Weiß nicht,ob ich alles richtig gemacht habe. Vielleicht sieht ja jemand von euch den Fehler.
Dementsprechend für [code]USART_Transmitt(0x00); [/code] > "128" > Jetzt weiß ich nicht wo mein Fehler liegt. Das bedeutet, dass das Stopp-Bit zu früh kommt. Das dürfte jetzt das schon von Karl Heinz angesprochene "interner RC-Oszillator"-Problem sein.
-
Thread
WordClock mit WS2812
heruntergeregelt werden!) > obwohl FB Code sendet. Ich habe mal in den Source geschaut und kann da keinen Fehler entdecken. Kannst Du mal einen UART-Log erstellen? Dabei mal die Farb-Tasten in der Kombination + und - drücken. Danke, Frank
Burkhard D. schrieb im Beitrag #4727006: > Ja, der Fehler ist bei mir wie in der Fehlerbeschreibung vorhanden. > (Bei angeschlossenem DS1820 ist der zuvor gespeicherte Korrekturwert > nach Reset nicht mehr vorhanden). Hm... Kannst Du ein UART-Protokoll
-
Thread
ATTiny13 nach einmal Flashen nicht mehr beschreibbar
Zum Programm, es enthält Fehler. Hier ist eine korrigierte Version [c]avr.clock = 1000000 avr.device = attiny13 avr.stack = 8 #if 0 ' unbenutzt SoftUart.PinRXD = PortB.1 SoftUart.PinTXD = PortB.2 SoftUart.Baud = 1200
Übrigens hat der interne RC-Oszillator des ATTiny 13 eine Grundfrequenz von 9,6MHz und nicht 8MHz. Da die CLKDIV8 Fuse im Grundzustand gesetzt ist, bleibt ein Systemtakt von 1,2MHz.
-
Thread
Stk500 externere Takt, Fuse bits aber interner Takt
Hi Leute, nachdem ich schon den zweiten Vormittag an der Inbetriebnahme des UART mit Hilfe des STK500 und eines Atmega8515 herum gebastelt habe, habe ich es jetzt endlich geschafft! Hatte die Fuse bits auf internen Takt gestellt. -U lfuse:w:0xc4:m -U hfuse:w:0xd9:m Doch leider
Der Atmega8515 hat sicher seinen internen Takt erzeugt, wenn du ihn richtig gefused hast. Das Problem war wohl eher, daß der interne Oszillator nicht genau genug ist, um davon die Baudrate für den UART abzuleiten. Deswegen kommt dann nur
-
Thread
Interrupt führt zum Absturz
nicht angeben? Doch. Aber wenn du einen Mega1284 im Auslieferzustand anwendest, wird er mit dem internen 8MHz Oszillator und gesetzter CKDIV8 Fuse betrieben - resultierend in 1Mhz CPU Takt.
Project-Options wenn du eine IDE benutzt. Und du willst, dass solltest du das vergessen, das in einem Fehler mündet.
-
Thread
DMX Baudrate - Einstellungen und Datenpakete "debuggen"?
folgendes initialisiert: [c] void init_Timer(void) { //OSCCON MPU Frequenz SCS1 = 1; //1x internem Oszillator OSCCONbits.IRCF = 0b1111; //Bit 3-6 16Mhz //OPTION_REG Timer 0 0b0x0x0111 OPTION_REGbits.PS = 0b000; //Prescaler = 0b000=1:2, 0b001 = 1:4, 0b010 = 1:8, 0b011 = 1:16,...,0b111
Pegelanpassung an Schnittstelle nicht vergessen (MAX2323 etc). Vielleicht!!! funkteoniert das sogar mit dem internen Oszillator. Bevor so etwas "primitives" nicht läuft, brauchst du keine DMX-Routine testen.....
-
Thread
UART Übertragungsgeschwindigkeit einstellen
Sieh dir hier mal das Makro UBRR_VAL an http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#UART_initialisieren PS: Der heäufigste Fehler, wenn eine UART nicht funktioniert ist es, wenn dein µC nicht auf der Taktfrequenz läuft, die du angibst. D.h. zb. du gibst zwar 8Mhz im Programm an und
Allerdings hast du vergessen, die Fuses umzustellen und daher arbeitet der µC immer noch auf dem internen RC-Oszillator auf ca. 1Mhz
-
Thread
(UART) AVR sendet wirre Zeichen zurück an BTM222
F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" .endif
Gaaaaaaanz komisch... liegt irgendwie am quartz Oszillator. Hab aus spaß mal den internen RC benutzt und dann ging es. Auf dem Oscillator steht 3.6864 MHz. Hab ich in dem Programm irgendetwas falsch gemacht ? oben bei F-CPU ? Ich hab die fuses beim ATMEGA
-
Thread
Atmega 162 - UART/Interrupt geht nicht
Hi :) Ich versuche mit dem Atmega 162 einen String über UART zu empfangen. Zurzeit löst aber nichtmal der Interrupt aus.Sitze schon seit 3Tagen dran und finde den Fehler einfach nicht.Hab im Forum leider nichts gefunden,was mir helfen würde und das UART Tutorial
Angefangen damit, ob der Prozessor überhaupt mit dem erwarteten Takt läuft (ist vielleicht noch der interne RC-Oszillator aktiv?). Dann die Hardware checken, Verkabelung, Pegelwandler, etc (kommen überhaupt irgendwelche Signale beim µC an?).
-
Thread
Geschwindigkeit UART ATMEGA128P
Habe gesehen das es hier viele helle Köpfe hat :-) Daher einige Kontrollfragen zum Thema UART. Angenommen ich habe 75 ATMEGA128P. Der Erste ist via UART mit dem Zweiten verbunden, diese über die 2te UART mit dem Dritten, usw... Wenn ich die UART nun auf 115kBaut einstelle (damit ich diese
zwischen 2 Rechnern schon stabil 35m gehabt, bei 57600 gab es dann gehäuft Übertragungsfehler. Zum internen Oszillator wurde schon alles gesagt. Quarze ran, Baudratenquarz, z.B. 14,7456MHz. Gruß aus Berlin Michael
-
Thread
UART - senden geht, empfangen nicht :-( Mit Latein am Ende
(__TIME__); uart_putc('\n'); uart_putc('\r'); //Warte auf Taste uart_puttext("Taste1");uart_putc('\n'); uart_putc('\r'); while (!(UCSRA & (1<<RXC))) { ;} uart_puttext("Taste2");uart_putc('\n'); uart_putc('\r'); while (!(UCSRA & (1<<RXC))) { ;} while(1) { // Blinken toggle_LED(); } return 0; } [/c] Den einzigen Hinweis auf einen Fehler ist der Signallevel
-
Thread
MSP430 Software laden
Der MSP hat doch einen internen DCO, der läuft auch ohne externe Quarze.
ohne Quarz. Ohne jegliches Zutun (ausser natuerlich den Watchdog stoppen), läuft der MSP mit dem internen DCO(ca. 800 kHz) los. Poste mal bitte Dein Programm.
-
Thread
"Übersprechen" v. Pins beim AVR?
noch nicht. Mag ja sein, das beim AVR bei 1 MHz aynchron Feierabend ist, vielleicht tiltet auch der UART dahinter herum; ich weiß es nicht. Viele Grüsse
Anfängerfehler würd ich sagen. Eher eine faule Ausrede. Der ATMega644 hat einen 128kHz Watchdog-Oszillator und der Watchdog kann mit maximal f/2 ausgelöst werden. Der ATMega32 hat zwar einen 1Mhz Oszillator. Aber die höchste Frequenz wäre f/16k. MfG Spess
-
Thread
UART Probleme mit AT90CAN128
der Controller läuft aber schon mit externem Quarz und nicht mir dem standardmäßigem RC-Oszillator oder? (Fuses!)
ISP-Programmieren - Bist du sicher, dass der AVR mit 4Mhz läuft? (Woher kommen die: STK-500, Quarz, internerRC-Oszillator...) - Benutzt du die richtige Serielle schnittstelle? hth. Jörg kannst du mal das aktulle Programm posten ? (möglichst in [c ] [/c ]-Tags(ohne Leerzeichen ;) ))
-
Thread
soc-lm32 tut nicht so richtig
uart_wait_tx; // send length uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h04 ); #(tck*
uart_wait_tx; // send length uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h00 ); uart_wait_tx; uart_send( 'h04 ); #(tck
-
Thread
Das Mysterium CKOPT
Danke für diesen Fred und diesen Tipp! Habe erst Fehler in meinem Code gesucht (modifizerte UART-Buffer-Routinen von Peter Danegger), da es immer wieder zu spontanen Resets gekommen ist. Ein Hinweis noch den ich hier nicht so klar gefunden habe - findet
schreibt, ist das in die CKSEL Fuses gewandert -> in AVR-Studio musste ich statt "Ext. Crystal Oszillator" -> "Full Swing Cristal Oscillator" auswählen. Seitdem läuft UART stabil und selbst bei 115200 ist das AVR-Software-Loopback fehlerfrei. Danke!, Martin.
-
Thread
Atmega MAX232 Kommunikationsfehler
Atmega zu Excel funktioniert. Leider nicht umgekehrt. Ich habe mit dem AVR Terminal den Empfang in das Uart-Register simuliert und keine Übertragung hinbekommen. Zu Testen nehme ich die UART-Beispiele aus dem Microcontroller-Lehrbuch von R.Walter. Deshalb gehe ich davon aus, dass der Fehler in der Hardware
Wie wird der Takt von 8MHz erzeugt? - Externer Quarz, - externer Quarzoszillator oder - interner RC-Oszillator? ...
-
Thread
löst das STK500 meine Probleme ?
Hallo, ja, da habe ich etwas vergessen, ich habe natürlich den Atmega8 und den Max232. der Fehler ist, dass im Hyperterminal nicht ankommt. Ich werde versuchen mein Schaltung zu skizzieren: die UART- (Max)-Beschaltung habe ich genau aus dem Tutorial übernommen und die Datenleitung mit Pin 2 und
Hallo, zu dem Fehler, es kommt garnichts an im Hyperterminal Gruß Pfeiffy
-
Thread
Kommunikation mit 2 Megas
diversen Beiträgen gelesen macht immer wieder Probleme wenn Signale nicht korrekt empfangen werden, UART habe ich bisher nur mit dem PC betrieben, aber nicht wenn ich 2 AVR's jeweils mit internem Oszillator betrieben habe(Synchronisation?) und bei TWI habe ich keine Erfahrung. Grüße Tom
Hier ist noch das Logfile der UART Kommunikation
-
Thread
Unterschiedliche Baudrate
Fuse-Bits) oder hast du nur einen 16MHz-Quarz drangehängt und der uC läuft trotzdem noch mit dem internen R/C-Oszillator oder teilt die 16MHz herunter? MfG, Arno
CKDIV - das ist kein mega-Feature, findet man mehr bei den Tiny's. Der vergessene interne Oszillator statt Quarz klingt schon plausibler. Baudratenquarz? Ist oft nur was für Angsthasen, oder solche, die nicht rechnen können. ;-) Mit 16 MHz lässt sich jede Standardbaudrate <
-
Thread
Geeigneter Controller der AVR-Familie gesucht
kenne mich mit der Materie eben noch nicht so aus. Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt.
libre95 schrieb im Beitrag #6706552: > Falk B. schrieb: >> Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt. > > An 8MHz hatte > .......ich auch schon gedacht. /o\ Vielen Dank!
-
Thread
[Suche] Interessierte(n) an Projekt (ARM/FPGA)
Blue-Tooth CAN UART RS485 IrDA
@Markus Müller : der STM32F2xx hat keinen internen Displaycontroller.
-
Thread
Fusebits - tiny2313 mit 4 MHz Quarz
nicht brauchst, brauchst Du vermutlich auch keinen Quarz. Zeitunkritische Dinge gehen auch mit dem internen RC-Oszillator. Also lass die Finger von den Fuses bis Du etwas mehr Wissen hast. Du wärst nicht der erste, der sich ausgesperrt hat, bevor das erste Programm im AVR lief. > 3.) der FuseCalculator
http://de.wikipedia.org/wiki/UART
-
Thread
Mega128 und Hardware-UART (Bascom)
ist denn jetzt der riesen Unterschied zum Mega128? Was ich probiert habe, ist, dass ich den internen Oszillator auf 1,2,..8 MHz gestellt habe (per fuse bits). Dann habe ich per toggle einen port geschaltet und kam mit externem 16Mhz Quarz auf maixmal 1,1Mhz am port (per toggle). Kommt mir langsam
Ok, jetzt geht auch der UART wunderbar, ich bedanke mich nochmal recht herzlich für die Hilfe!