-
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
String auf LCD anzeigen und über UART USB Bridge senden. Problem!
Hallo Zusammen, ich habe im Anhang meine Source Datei. Atmega8 USB UART Bridge UM232R (com n) AVR Studio Ich hab folgendes Problem. Ich habe ein String den ich gerne auf einem LCD ausgeben würde und der danach über UART (USB Bridge) in einer Schleife an z.b. Hyperteminal
Hi Hast du einen Quarz, oder benutzt du den internen Oszillator? MfG Spess
-
Thread
Hardware-Interrupt R8C/13
Schnittstellenparameter auf beiden Seiten? Also z.B 8N1? Hast du einen Quarz am Prozessor oder verwendest gar den internen RC-Oszillator? Olaf
die Schnittstellenparameter stimmen auf alle Fälle, mit fehlerhaften Parametern bekomme ich nur fehler, schon ausprobiert. Bei den µC verwende ich den externen 20MHz-Quarz der mit auf der µC-Platine verbaut ist. [c] void UART0_Rx_int (void) { //Daten am Empfang (RX) abholen // while (!
-
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
GPX-/GPS-Logger
Falls man den internen Oszillator verwendet um den Quarz zu sparen , sollte man sich einen 32kHz quarz goennen, und den internen Oszillator auf den synchronisieren. Sonst wird das mit der Baudrate nie was. Advanced waere
und GGA vertauscht. Hat anscheinedn ein wenig Einfluss. Habe nun außerdem die Debug-Ausgabe über UART direkt in parse_RMC/GGA eingebaut und dann bringt er immer die richtige Uhrzeit. So einfach geht das mit den 2MHz nicht, da sich der interne Oszillator nicht auf 2 stellen lässt.
-
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
Neuer Controller, altes Programm: Fahler im Zeitkonitnuum
mitteilen, dass nun ein 4MHz Quarz dranhängt bzw., da ich hörte, dass Atmel mit eingeschaltetem internen Oszillator geliefert wird, welches Programm brauche ich oder nach was muss ich suchen, um die Fuses zu setzen, die dem Chip sagen, dass er nun auf den externen hören soll. Eine hab ich noch: angenommen
mitteilen, dass nun ein 4MHz Quarz dranhängt bzw., da ich > hörte, dass Atmel mit eingeschaltetem internen Oszillator geliefert > wird, welches Programm brauche ich oder nach was muss ich suchen, um die > Fuses zu setzen, die dem Chip sagen, dass er nun auf den externen hören > soll. Wie bereits
-
Thread
ATMega128 tot?
Test mit oder ohne Quarz gemacht? Die Beschreibung lässt mich vermuten, dass das Modul nicht mit internen Takt läuft. cu Georg
Testschaltung mit. Du solltest alle VCC/AVCC des AVR mit ner 5V-Quelle verbinden. Auch darf an der UART0 des ATmega128 kein MAX232 o.ä. hängen. Peter
-
Thread
ATxMega Entwicklungsboard 2
Lage und b) völlig unnötige Durchkontaktierungen (sind auch Induktivitäten) und der Rückstrom zum Oszillator-Pin müsste eh' wieder nach oben. Nö, das passt schon so wie's jetzt ist.
genommen, die erste Version von OpenMCP läuft auch schon. Es gehen z.Zt.: - Netzwerk - MMC - UART (USB/RS232) - LED CA Dirk
-
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
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
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
AVR @16MHz im Außeneinsatz -> Quarz oder Quarzoszilator?
gebaut ist. >Gibt es bei Temperaturschwankungen eventuell Probleme mit der >Taktfrequenz bzw. dem UART? Nur wenn man den internen RC-Oszillator nutzt. Man kann aber auch einen 12 MHz Takt vom FT232 ausgeben lassen und als Takt für den AVR nutzen, der ist dann auf jeden Fall genau genug. MFG Falk
#1787182: >>Gibt es bei Temperaturschwankungen eventuell Probleme mit der >>Taktfrequenz bzw. dem UART? > Nur wenn man den internen RC-Oszillator nutzt. Man kann aber auch einen > 12 MHz Takt vom FT232 ausgeben lassen und als Takt für den AVR nutzen, > der ist dann auf jeden Fall genau genug. Tilo
-
Thread
problem mit 8051er
InitPort ;Initialisierung Ports, Crossbar lcall InitOsz ;Initialisierung interner Oszillator lcall InitSerialPort ;Initialisierung Serial Port mov vorname,#'v' mov nachname,#'n' ;mov dptr,#StartMessage ljmp Main ; ---------------
InitPort ;Initialisierung Ports, Crossbar lcall InitOsz ;Initialisierung interner Oszillator lcall InitSerialPort ;Initialisierung Serial Port mov vorname,#'v' mov nachname,#'n' ;mov dptr,#StartMessage ljmp Main StartMessage: ;db
-
Thread
ATmega16 durch ATmega644 getauscht - UART geht nicht mehr
hatte vorher einen ATmega16 verwendet, habe ihn nun durch einen ATmega644PV 10PU ausgetauscht. Die UART Programmierung habe ich wie folgt angepasst, da der ATmega16 nur einen, der ATmega644 2 UARTs besitzt: [c] void init_USART(void) { // USART Einstellungen: 115200 Baud, U2X=1, Quarz: 14,7456 MHz
Wie stehen die restlichen Fuse-Bits? Die vom Mega16 können beim Mega644 nicht passen. Der beliebte Fehler "ClkDiv8-Fuse" wurde bereits gefunden :-) Stehen die CLKSEL-Fuses auf "externer Quarz"? Ansonsten ist der interne Takt aktiv (8 MHz RC-Oszillator).
-
Thread
Ist ein ATMEGA32-16PU geeignet für Jonglage?
Hallo, der Interne Oszillator kann es sehr wahrscheinlich nicht ausreichend Synchronhalten. Mit einen Quarz sollte es aber Problemlos sein. Du könntest dir aber überlegen alle per Infrarot zu Synchronisieren. Gruß
meines Wissens sind Quarze stoßempfindlich und gehen dann auch mal kaputt. Da würde ich eher den internen Oszillator nehmen und wenn der (nach Kalibrierung) zu ungenau ist synchronisieren (per USB, weil Funk braucht auch nen Quarz).
-
Thread
Projekt für den NXP 8051 "Mischanlage" in Planung
wie der RTC anzusteuern ist: Einmal beim Start initialisieren [c] // RTC konfigurieren bei internem RC Oszillator mit 7,3728 MHz RTCCON = 0x60; [/c] Dann in einer Funktion z.B.: [c] // Anzahl "sekunden" warten void sleep(unsigned char sekunden) { unsigned char zaehler; for (zaehler
Geschwindigkeit und Quelle, mit welcher der RTC getaktet wird. In Verbindung mit RCCLK=1 und FOSC[2:0]=011 (interner RC Oszillator) ergibt sich, dass der RTC vom RC Oszillator den Takt bekommt (7,3728 MHz). Dieser wird nun durch den 7Bit Vorteiler des RTC geschickt, wodurch der neue Takt 57600 Hz beträgt. Bei einem
-
Thread
Suche Mitwirkende für Universal-FPGA board
dann 0,05% Pegelfehler. Bei einer hohen Aussteuerung des Signales sind dann z.B. 0,02% absoluter Fehler des Signals. Je nachdem wie sich das durch den AA-filter durchsetzt sind es auf den durchschnittlichen Pegel bei Klassik von 20% also ein Fehler von 0,1% -> 40dB SFDN. Da brauchen wir keine 16 Bit
benutzt GHDL statt ISIM oder Modelsim? Genau. Es geht sogar sehr gut. Ich finde in GHDL meine Fehler viel schneller. Steuerung über Makefile skript. Leider geht keine Mix Verilog und VHDL da GHDL nur VHDL kann.
-
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
USART nur mit Delay möglich?
Habe gerade keinen 16 MHz Takt zur Hand, nur den internen RC-Oszillator mit 8 MHz, sodass sich 9600 Bd stattdessen ergeben. Damit funktioniert dein Test mit und ohne delay problemlos. Habe auch mal spaßeshalber das Zeichen in jedem Durchlauf hochgezählt
http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
-
Thread
Atmega644 UART - Komische Ausgabe
dass du einen 3,686 Mhz Takt hast. Ob der von einem angeschlossenen Quarz oder einem externen oszillator kommt, weiß ich nicht. Ich kenne ja deinen Aufbau nicht. Das ist jedenfalls das entscheidende, was man mit den Fuses auswählt: * Externer oszillator oder * Externes Quartz oder * Interner RC-Oszillator
Also vielleicht um ein Wort was ich vorhabe: ich will nur ein Int übergeben über das Uart... ich habe keine Ahnung, ob der Interne Clock ausreichend ist. Ich dachte bisher dass mein interner Clock 3,686 MHz ... wiso der jetzt nur 1 MHz ist, versteh ich nicht.
-
Thread
ATMega8: UBRR in BASCOM
Fusebits vom Controller eingestellt? Externer Quarz aktiviert? (CKSEL3..0 = 1111) Sonst läuft der interne Oszillator mit 1MHz ...
Samuel C. schrieb im Beitrag #1725798: > Dann hast du wohl deinen internen Quarz auf 4MHz gestellt. Es gibt keinen _internen Quarz_ . Sollte der interne RC-Oszillator auf 4 MHz gesetzt worden sein, dann sollte man auch bedenken, dass dann der Oszillator des Mega8 bei
-
Thread
Software-UART: Problem beim Empfangen
nicht? Ich hab jetzt so oft über den Quellcode geblinzelt, dass ich den nicht mehr sehen kann incl. Fehler. Könnte jmd.eventuell mal ein Auge draufwerfen? MfG BruceCompanys [c] #include "uart.h" static volatile uint16_t outframe; static volatile uint16_t inframe; static volatile
Benutze den internen RC-Oszillator, der reicht mir bisher von der Genauigkeit.
-
Thread
Laserplotter
geschrieben? Kannst Du da einen Verify machen, bei den Fuse-Bits? Im ATtiny15 Compatibility Mode läuft der interne RC Oszillator nicht mit 8 MHz, sondern mit 6,4 MHz. Und die PLL macht dann nur x4 (-> 25,6 MHz). Mit freundlichen Grüßen - Martin
diese 2 Bereiche beim OSCCAL-Register bin ich auch schon mal gestolpert, als es darum ging, den internen Takt eines ATmega328 automatisch, anhand des, mit einem Uhrenquarz getakteten, Timer2, so abzugleichen, daß störungsfreier UART-Betrieb möglich ist. Das wurde dadurch unnötig kompliziert, geht aber
-
Thread
UART sendet nicht das was er soll (kein offset problem)
. Lern erstmal ein paar Grundlagen. > > http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART > > MFG > Falk Danke erst mal, -ich habe nur einen Internen Takt zu verfügung. -die verbindung und die Übertragung funktioniert Prinzipiell -zeichen könne ohne fehler übertragen
_delay_ms( 1 ); } [/C] wenns dann geht, dann hast du ziemlich sicher ein Problem mit dem internen Oszillator. Du kannst auch mal probieren, auf 2 Stoppbits zu erhöhen. > Ps: Hilfsbedürftige ins Lächerliche zu ziehen ist nicht die feine Art Wenn jemand den internen Oszillator zur UART
-
Thread
ATtiny2313 als i2c Slave lässt sich nicht auslesen (mit Lego NXT als Master)
Hallo, ich versuche momentan mit einem ATtiny einen "Übersetzer" zwischen einem UART und einem i2c-Bus zu realisieren. Sprich: Daten, die auf dem i2c-Bus zum ATtiny geschrieben werden, werden von diesem direkt über den UART rausgeschrieben. Andersherum werden Daten, die über den UART
Werte folgen anderen Mustern oder sind nicht wirlich reproduzierbar. der tiny läuft mit 8MHz (interner Oszillator) Der NXT wurde mit NXC programmiert und der wesentliche Code-Ausschnitt ist eigentlich nur [c] until(LowspeedCheckStatus(I2C_PORT) == 0); byte send[1]; send[0] = (NODE_ADDR << 1) |
-
Thread
CP/M auf ATmega88
wie von Leo vorgeschlagen, bei 20 MHz uC Takt und dann noch mit 1 bzw. 2 Waitstates bei 8 MHz uC internen Takt. Aber es hilft alles nichts, diese beiden IC's sind definitiv defekt! Vielleicht solltest Du Deinen DRAM's auch mal nur 8 MHz uC internen Takt gönnen, dann sollte aber wirklich nichts fehlen
> aber bei 4800 Baud funktioniert unsere Soft-UART (RX) nicht mehr. :( Geht jetzt ab 2400 Baud. Noch langsamer ist zusätzliche Arbeit, die ich mir jetzt spare. Der Fehler mit Wordstar ist auch mit 2400 noch da. Wordstar schreibt erst das Directory
-
Thread
Anpassung Atmel MAC Zigbit Module -- Nur Reset & Int?
. Die Fuse legt ja nur erst einmal den CPU-Takt fest, der wird auch bei den Atmel-Boards vom internen RC-Oszillator genommen. Der MAC (und auch die Schichten darunter) brauchen aber einen Timerkanal, und der bekommt bei den Atmel-Boards 1 MHz vom CLKM des Transceivers eingespeist (in den Eingang
aber nicht /so/ schwer sein, das umzustellen, da der Atmel-MAC die Taktquelle des Timers auf internen RC-Oszillator umschaltet, wenn der Transceiver schlafen gelegt wird. Im Prinzip musst du den Timer so betreiben, dass er immer in diesem Modus läuft.) > Ja könnte sein! Irgendwie sind mir hier
-
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
MiniLA Version MockUp
@Stephan S.: Kommt der Fehler bei mprog oder xc3sprog ode bei beiden Programmen?
Die ftd2xx.dll Version spielt keine Rolle, bei mir verhalten sich alle ohne Fehler gleich.
-
Thread
Wer benutzt den FC 7008 von ELV?
mir schon eine Mail geschickt? ;-) Was macht man mit 15 Zählern? Haben die alle den gleichen Fehler? Wundern würde mich das nicht. Gruß Old-Papa
hier bei 5Vss schluss, das war mein Grund zu damaliger Zeit den 7008 anzuschaffen. Was aber den internen 25Mhz Ofen angeht, wenn man am hinteren Eingang einen Externen oszillator anschliesst kann regelrecht auf den internen verzichten, ist also kein Muss hier im Gerät etwas einzubauen. Wer aber die
-
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
USB-Steuerung mit ATMega8
Henry Knoll schrieb: > So ich hab die Schaltung nochmal überarbeitet. Ich würde mit internem Quarz arbeiten, wenn man nicht gerade sehr schnelle UART machts geht das ohne Probleme die ISP Leitungen fehlen noch am ATMega, genauso anschließen wie am Stecker
auch verstanden sein. Die genannte Abweichung stellt sich bei *genau* 8MHz von einem stabilen Oszillator ein. Mit dem internen 8-MHz-RC-Oszillator hast Du aber weder genau 8 MHz noch einen besonders stabilen Oszillator. Es geht trotzdem meistens, mehr lässt sich aber nicht sagen. Und was mit 0,2%
-
Thread
Problem Atmel Evaluationsboard 2.0.1
Die Angabe $CRYSTAL dient in Bascom nur zur internen Berechnung von taktfrequenzabhängigen Parametern wie Warteschleifen-Startwerte, Baudtatenteiler für UART usw. Sie hat nichts mit Fuses usw. zu tun. ...
der Erstprogrammierung spielt der Quarz keine Rolle, ein fabrikneuer AVR arbeitet anfangs mit dem internen RC-Oszillator.
-
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
Text über Uart und FT232 an PC
verbinden, und prüfen ob die vom Terminalprogramm gesendete Zeichen auch richtig ankommen. Treten keine Fehler auf, so kann man den FTDI als funktionsfähig abstempeln. 2)Wozu schaltest du UART double speed ein? UCSR1A = (1 << U2X ); Hab’s noch nie gebraucht, also zuerst mal abschalten. UCSR1A = (0 <
//38 kBaud bei 8 Mhz U2X = 1 Diese Zeile deutet darauf hin, dass du als Clocksource den Internen RC- Oszillator verwendest. Ist keine so gute Idee. Für Testzwecke sollte man die Baudrate sehr klein wählen(bsp. =<600Baud/s), somit dürfte es vielleicht noch klappen. Für höhere Baudraten sollte
-
Thread
Prozessor 100% voll, Problem?
es zu teuer, ein "fertiges" Produkt auf dem Markt zu kaufen. Welche Features brauche ich: - interner Oszillator 8Mhz (andere Taktfrequenz würde die ganzen Zeitroutinen im Programm ändern), externer Quarz nicht nötig (so genau muss es nicht sein) - 2 Timer, mind. einer 16-bit mit Input Capture, Compare
Siegfried schrieb: > Welche Features brauche ich: > - interner Oszillator 8Mhz Haben nahezu alle. Der in den neueren AVRs ist allerdings etwas stabiler als der frühere. > - 2 Timer, mind. einer 16-bit mit Input Capture, Compare Match, einer > 8-bit mit
-
Thread
USB IR Remote Receiver (V-USB + IRMP)
MHz, 16 MHz or 20 MHz crystal or from a 12.8 MHz or 16.5 MHz internal RC oscillator." Da der interne Oszillator vom ATTiny85 nur max. 8MHz liefert, ist der Quarz zwingend erforderlich. Gruß, Frank
> in etwa den 10kHz Abfragerate entspricht. "In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder? Gruß, Frank
-
Thread
Probleme mit Rs232 Empfang
noch: Du bist ein ganz kleines bischen neben der eingestellten Frequenz. Das kann zb auftreten bei internem RC-Oszillator. Der schwingt normalerweise auf zb 8 Mhz, hat die aber nicht ganz genau. Ist nun die UART im PC etwas toleranter auf die Abweichung dann kann sie zwar noch empfangen, aber das was vomPC
Waitkey() 'Waitkey waits untill a char is received from the UART Print Akey Loop
-
Thread
mega8 Dip UART != mega8 tqfp UART ?
größer 2% sein. Vergleich das mal mit den Genauigkeitsangaben zum internen Oszillator im Atmel Datenbatt.
nicht > größer 2% sein. Vergleich das mal mit den Genauigkeitsangaben zum > internen Oszillator im Atmel Datenbatt. Ok angenommen mein Quarz schwingt bei 7mhz und nicht bei 8 wie im Programm angegeben. Aber warum funktioniert dann mit Bascom der Uart einwandfrei? Achso in dem Bascom
-
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
Giess-o-mat mit AVR Version 2
bis das Kabel da ist und werde es direkt an den AVR Anschließen. Vielleicht hab ich ja auch einen Fehler auf meiner Platine und kann ihn nur nicht direkt erkennen. Daher dieser Schritt um vielleicht den Fehler auf der USB-Seite auszuschließen. Oder hab ich hier auch einen Gedankenfehler?
Blöde Frage: Hat der ATTiny keine interne Spannungsreferenz? Gegebenenfalls auf anderen µC umsteigen, um eine interne Spannung nutzen zu können?
-
Thread
avrdude-ATTiny13-ohne Programmer
nur dass dessen Unterstützung in Version 4.4.0 dazugekommen ist. Ich vermute also mal, dass der Fehler eher woanders liegt. Hierzuworkstation funktioniert avrdude mit dem t13 einwandfrei. Dazu fällt mir noch ein: Klingel mal dein Board durch, welche Anschlüsse wohin gehen, und gleiche das mit der
Franzis-Lehrbuch steht auf Seite 22: "....blablabla... Das Lernpaket arbeitet mit dem 9,6MHz-Oszillator und dem Teiler, sodass der Prozessortakt 1,2 MHz beträgt...". Das ist schön vom Lernprogramm, unter Windows funktioniert ja auch alles wunderbar (Init, RC-Oszi-Kalibrierung etc.). Die Frage ist
-
Thread
Erster Test mit UART was mache ich falsch
Wie wird Dein Takt erzeugt? Quarz oder interner Oszillator?
Hallo, >> Wie wird Dein Takt erzeugt? Quarz oder interner Oszillator? > Soll eigentlich Intern sein. In deinem Code steht: > $crystal = 16000000 Der Takt wurde also mit 16 MHz angegeben. Daraus berechnet BASCOM die Einstellungen für die UART-Baudrate
-
Thread
Zum x-ten Mal: Quarzprobleme am AVR
der jeweiligen Anwendung abhängig. Und wenn Du nicht auf einen Quarz angewiesen bist, also den UART niocht benötigst, brauchst Du nicht mal den Quarz und kannst den internen RC-Oszillator verwenden. Frank
schau bitte noch mal genau die Fuses an. Zum einen kann es durchaus sein, dass der Chip Doch auf interne Clock steht, zum Anderen gibt es AVRs, die eine Fuse für ClkDiv8 haben, dann würde die Schltung nut mit 1MHz laufen. Es blinkt also deutlich langsamer. Und dann kann man über das OscCal Byte die interne
-
Thread
Projekt: DDS basierter Funktionsgenerator mit AD5930
hingegen. Auch deutlich > größere Werte als 25+25µs funktionieren wieder. Es ist unklar ob der > Fehler in der Software liegt, oder der DDS die Probleme macht. Ich habe Analog Devices diesen Bug bereits gemeldet. Es bleibt abzuwarten ob sie diesen Fehler nachvollziehen können und was seitens Analog
bereits gemeldet. Was hat AD dazu gesagt? Ich habe mit dem 9912 gerarbeitet und der hatte auch Fehler in Massen.
-
Thread
genaues Delay in gcc
mal) zu einem genaueren Ergebnis führt als >z.B. _delay_ms(250) Läuft der Prozessor mit dem internem Oszillaotor, oder an einem Quarz? Oliver
nimm dann einen Timer. Denn dort ist die Abweichung dann nur noch durch den Quarz bestimmt, und der Fehler liegt irgendwo bei +/-100ppm und weniger. Oder hast du den internen RC-Oszillator verwendet (siehe [[AVR Fuses]]). Dann ist klar, warum deine Zeiten ungenau sind. MFG Falk