-
Thread
Keine GPS Datenanzeige auf GLCD Display (Navilock 552ettl)
Atmega16. Momentan noch mit 8Mhz internen Takt.
>Dann stimmt die Baudrate nicht. Oder es kommt gar kein >GPS Signal am ATMega an. Mit dem internen RC-Oszillator ist die korrekte Baudrate eher Glückssache. MfG Spess
-
Thread
Kennt jemand den mini-VNA Tiny 1-3000 MHz?
messen ... allerdings merkt man, dass jenseits von 1,5GHz das "Rauschen" zunimmt. Wenn Dietmar die internen "Bandumschaltungen" bei 1GHz und 1,5GHz kalibriertechnisch noch ausblenden kann, bin ich ganz zufrieden mit dem Teil. Auffällig ist die starke Erwärmung im Betrieb. 52°C scheinen da keine Seltenheit
mittlerweile 19% mehr kostet als vor 3 monaten. Was mich interessiert, sind die angesprochennen "fehler" immer noch drin? http://www.knietzsch.com/amateur_radio/ham_VNA.htm#miniVNA_Tiny
-
Thread
Projektidee RGB Pixel mit Touch
nacheinander sind das dann schon ganze 35 Sekunden! Also kurz gesagt keine gute Idee jedenfalls mit UART. Wenn dann müsste das Serial durchgetaktet werden wie es die Treiber auch machen oder Parallel an alle gleichzeitig. Denke Einlesen Touch über UART und Pixel einen extra Bus z.B. Uart Parallel an
Taktabweichungen bzw. unscharfen Flanken klar. Der Trend bei den Prozessoren geht ja dahin, daß die internen Oszillatoren ab Werk auf <=2% abgeglichen sind, damit man damit ohne Quarz UART/RS232 nutzen kann. Steht jedenfalls so in den Datenblättern. Ich habe aber auch noch kein konkretes Beispiel gesehen
-
Thread
Datenaustausch von µC und PC
8Mhz Quarzoszillator Fällt mir gerade noch auf: Ist es wirklich ein Quarzoszillator? Oder der interne 8MHz Oszillator? Der interne ist für UART nicht zu gebrauchen. Gruß Jobst
Das war tatsächlich der Fehler! Hab jetzt mal geändert zu while(UART_RxHead == UART_RxTail){} Und jetzt klappt es. Auch der strcmp funktioniert jetzt. Danke! Da stand ich echt bisschen auf dem Schlauch :D Aber warum
-
Thread
Schon mal jemand das CY8CKIT-049 4200 in der Hand gehabt?
ich bin von Tag zu Tag begeisterter. Ich habe einige kleine Projekte realisiert. (LCD-Ansteuerung, UART Kommunikation, KeyPad u.a,) Das größte Projekt ist bisher eine Anzeige von Digitalen Messschiebern. Da komme ich dank der internen Analog- und Digitalcomponenten nahezu ohne externe Bauteile aus (
starten... das macht man 2h mit und bestellt sich dann das pioneer kit ;-) (oder man benutzt den 2. uart - dann fehlen aber schon wieder ressourcen...) ...alex
-
Thread
Energieverbrauch ATtiny261 :-)
man einen Uhrenquarz (für die RTC) ran hängen und einen externen z.B. 16MHz Quarz oder z.B. den internen 2MHz oder 32MHz RC-Oszillator nutzen. Im normalen Betrieb weckt der RTC den Chip jede Sekunde oder jede Minute auf, die Zeit wird um eine Sekunde oder Minute erhöht und er geht wieder schlafen. Ich muss oft nur Rechenoperationen durchführen, dazu wird der 32MHz/2 = 16MHz Oszillator aktiviert, wenn ich dann Daten über UART verschicken muss, dann aktiviere ich den extenen 12MHz Quarz. Da der interne RC-Oszillator nicht genau genug ist, aber dafür sehr schnell anschwingt (im
-
Thread
attiny2313, USART mit interner Clock, Fehler sobald Timer aktiviert
Beitrag #3681352: > Ist die Lösung in diesem Fall einen externen Quarz zu verwenden oder > liegt der Fehler woanders? Mit dem internen Oszillator kriegst du weder eine fehlerfreie Datenübertragung noch eine genaue Sekunde hin. Also was soll der ganze Aufwand? Natürlich brauchst du einen Quarz. mfg.
wunder mich nur, dass die Übertragung im einen Fall so perfekt funktioniert trotz Verwendung des internen Oszillators. Daher dachte ich, ich hätte im anderen Fall einen Fehler gemacht und es läge eventuell nicht daran, dass ein externer Quarz fehlt. Ändert sich die Frequenz des internen Oszillators
-
Thread
ATtiny 2313 0,1MHz Quarz
u.A.: die internen Teilerfaktoren sind begrenzt an Anzahl, an Teilbarkeit. -- Ähm, wieso willst denn einen µC als Uhr verwenden, wenn es doch ganz günstig Echtzeit-Uhren mit allem Pi-Pa-Po (Kalender) gibt?
kOhm) als ein MHz-Quarz (20 Ohm bis 80 Ohm). Dafür haben die Kontroller meistens einen extra Oszillator mit extra Anschlusspins. mit den fuses für tieffrequent könnte es vielleicht noch klappen.
-
Thread
Attiny2313 - DMX-Receiver - eingestellte Startadresse != reale Startadresse
noch die restlichen Informationen die eventuell interessant sein könnten: - externer 16MHz-Oszillator: laut Datenblatt bei 250k ein Fehler von 0,0% - Fuse CKDIV8: deaktiviert - Fuse SUT_CKSEL: EXTCLK_14CK_65MS Edit: Wird wenn ein Frame Error erkannt wurde ein Interrupt ausgelöst? Im
@ Matt B. (mattb) >- externer 16MHz-Oszillator: laut Datenblatt bei 250k ein Fehler von >0,0% Aber nur, wenn dein RC-Oszillator 0,0% Fehler hat. Die 0,0% beziehen sich auf dein systemtisch Fehler durch Frequenzteilung. Bei einem ganzzahligen
-
Thread
ATtiny2313 mit BTM222
COM-Schnittstelle auch. Parity- und Stopbit sollten auch richtig eingestellt sein. Ich verwende beim tiny den internen Oszillator auf 4MHz und den achter Divisor ausgeschaltet. Das BTM ist noch im Auslieferungszustand, das heißt die Baudrate und alles ist noch auf Default. Hoffe das reicht an Informationen.
Baudrate und > alles ist noch auf Default. Nämlich welcher? > Ich verwende beim tiny den internen Oszillator auf 4MHz und den achter Divisor ausgeschaltet. Dafür hast dir aber reichlich Mühe gegeben, deinen Code möglichst so zu gestalten, dass man möglichst nur nicht auf einen Blick erfassen
-
Thread
Verständnisfrage FU - was ist immer gleichzeitig an?
Fuses auf Ext.High Frequency Crystal mit langer Reset Zeit, die Software läuft aber auch mit den internen RC Oszillator. Ich habe den Eindruck, das du in den Ports irgendwo eine falsche Deklaration eingesetzt hast: [c] //! Bit pattern of PWM pins placed on PORTB. #define PWM_PATTERN_PORTB ((1
warm. Es haben schon einige Leute nachgebaut, aber heisse IR waren da nicht bei. Finde also deinen Fehler.
-
Thread
atmega8 mit rs232 zu Putty
Pascal B. schrieb im Beitrag #3648227: > Die Frage am Rande ist allerdings ob es mit dem internen generell nicht > geht? Es funktioniert auch mit dem internen. Verschiedene Geschwindigkeiten ausprobieren. 4800baud geht fast immer. Der interne Oszillator läßt sich auch mit dem OCCCAL Register
anderes tut man ja nicht, bei der Einstellung der Baudrate) Dadurch kann der abweichende RC-Oszillator bei unterschiedlichen Baudraten mit ihren unterschiedlichen Fehlerraten bei Nennfrequenz den Fehler ausgleichen, bei anderen vergrößern. Hab da vorher nicht auf den Punkt geantwortet :( >> Bei
-
Thread
ATmega UART spinnt
passt schon so. Wenn du den Haken bei CKDIV8 weg machst, hast du 8MHz. Trotzdem macht USART mit internem RC-Oszillator keinen Spass. MfG spess
einstellen ? Dann müsstest Du nicht nur etwas einstellen sondern auch einen 4MHz Quarz oder Oszillator an den uC anschliessen. Die einzigen beiden Frequenzen, die Du ohne weitere Hardware erreichst, also mit dem internen RC-Oszillator sind 1MHz und 8MHz.
-
Thread
Messkette: Wo ist der Fehler?
ich installiert, d.h. die USB-UART-Brücke wird vom PC anerkannt. Der C-Code ist definitiv korrekt. Ich weiß echt nicht worin jetzt noch das Problem besteht. Könnte es sein, dass ich beim flashen einen Fehler gemacht habe, oder ich
verehrte Forummitglieder, ich bin dem Rat nachgegangen eine String in den C-Code direkt über die UART des AT90USB1287 und über die USB-UART-Brücke an Tera Term zu verschicken. Das Lämpchen der RX der USB-UART-Brücke flimmert unentwegt. Doch trotzdem wird mir der String bei Tera Term nicht angezeigt.
-
Thread
Wer verwendet RFM69?
13dBm-transceiver-module-pin-to-pin-compatible-to-RFM12B-433-868-915mhz-can-be-selected/2010762457.html Ich verwende ATMega8 mit internem RC-Oszillator 1 MHz. Was verwendest Du als Antenne? Ich schaffe nicht mehr als ca 4 Meter. Änderungen der Sendeleistung bringen nicht viel. (die 20db habe ich allerdings noch nicht probiert) Mein
Christian W. schrieb im Beitrag #3915755: > Ich verwende ATMega8 mit internem RC-Oszillator 1 MHz. Kann gut sein, dass es beim ATmega8 noch nicht möglich ist, Pins per Schreibzugriff aufs PINx-Register zu togglen. Das würde erklären, warum mein Code bei dir nicht läuft.
-
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
DDS AD9854 China- Modul
Stromaufnahme max. 650 mA. Bei welcher Takt und Ausgangsfrequenz hast du die 650mA gemessen. Sind alle internen Optionen eingeschaltet ?
Rechteck-Signale mal Si570 oder Si504 vor http://www.ov-selbstbau.de/wiki/index.php?title=Flexibler_Quarz-Oszillator_auf_Basis_Si504
-
Thread
PIC24 Uart Problem
ich ans Terminal über [c]U1TXREG[/c] schicke es kommt nur was falsches raus. Wo mache ich einen Fehler? Systemtakt 8 Mhz Vielleicht habe ich auch was bei Uart falsch verstanden und lasse mich da gerne belehren. [c] #include <stdio.h> #include <stdlib.h> #include <p24FJ128GB108.h> _
willst. Du kannst auch mal das Senden was du empfängst: http://www.engscope.com/pic24-tutorial/9-1-uart-setup/ sodass du vielleicht leichter einen Fehler entdecken kasst. Ansonsten müssten die BRG=25 nun stimmen.
-
Thread
Z180-Stamp Modul
Beitrag #4146603: > Welche nutzt du bzw. hast du? Ich hatte Joe einen Zwischenstand mit geändertem UART-Treiber geschickt, um diesen ominösen PIP-Fehler einzugrenzen. > Wie? Als einzige Neuerung ist dort die Baudrateneinstellung drin. Leider aber auch ein schwer zu findender Fehler, der sich beim
in der Ausgabe würde ich auf grenzwertiges > Taktsignal tippen, obwohl dafür wieder sehr wenige Fehler drin sind. > > Die Bus Timeouts könnten auch von einem unzuverlässigen Clock verursacht > sein. Würde dem Z180 der Takt ganz fehlen, müßte der Fehler schon viel > früher kommen. Ich habe
-
Thread
Ideen für FPGA-Projekte?
CPUs oder ganzer SoCs geeignet. Dafür hatte ich es hier auch nicht empfohlen. Wenn man bei jedem Fehler im Synthesetool oder Silicon hinschmeißen würde, dürfte man gar nichts mehr machen. Gut, ihr hattet mehr Fehler. In welchem Jahr war das?
sind. Eher, ob es kleinere Varianten gibt, die Fehlerfrei sind, während die größeren Varianten Fehler hätten.
-
Thread
Quick&dirty - schnelle Problemlösungen selbst gebaut Bilder
> Wochen.) Kannst Du Dich nicht auf den USB-Takt des Host aufsynchronisieren und darüber den internen Oszillator nachstimmen? So machen wir das bei LIN-Slaves. Damit reicht der interne Oszillator auch über den vollen Temperaturbereich.
#4454823: > Kannst Du Dich nicht auf den USB-Takt des Host aufsynchronisieren und > darüber den internen Oszillator nachstimmen? Läuft doch ohne Quarz. Zudem habe ich "wenig" Ahnung davon. Ich habe nur das Projekt von github genommen und auf den ATTiny45 gebracht. Als I2C-Master habe ich noch ein
-
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
2 atmega einen als porterweiterung
sehr langsam Dann würde ich im Normalfall eine höhere Baudrate empfehlen, das sollte man mit dem internen Oszillator aber nicht machen. Du könntest eine Synchrone Datenübertragung wie SPI verwenden.
Doch bei mir irgendwie bei manchen, aber dann hab ich da wohl einen sehr banalen fehler drin.
-
Thread
ATxmega UART ohne Quarz
verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt, dass eine UART-Schaltung die im Winter noch funktionierte, im Sommer den Dienst verweigert. " Die xmega haben einen intern kalibrierten 2MHz bzw. 32MHz Oszillator! Siehe Datenblatt Xmega: "A DFLL can be enabled
-
Thread
Raspberry Pi ATmega328p pu per SPI
werd ich es dann wohl auch machen, da ich keinen Quarz hier hab kann ich sowieso höchstens die internen 8 Mhz nutzen und bei 3v3 dann die 4Mhz. Hoffe das der interne Oszillator genau genug läuft :)
Olovskos Bla schrieb im Beitrag #3550428: > Hoffe das der interne Oszillator genau genug läuft :) Für SPI ist der genaue Takt nicht ganz so entscheidend, wie für eine UART-Kommunikation. Außerdem läßt sich der interne Takt mit OSCCAL auch etwas verbiegen...
-
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
TCP/IP Stack Micrchip/ WLAN-Modul
also #define STACK_USE_UART ??
Funktion WF_AssertionFailed(UINT8 moduleNumber, UINT16 lineNumber) gibt mir gibt mir folgenden Fehler zurück: if (TickGet() - startTickCount >= maxAllowedTicks) { WF_ASSERT(FALSE); } Welche Configuration Bits nutzt Ihr? Interner Oscillator mit PLL? 80MHz Oscillator
-
Thread
Anzeige mit ATmega8 FT232RL und LCD
ist oder ein weiter Temperaturbereich notwendig ist, dann kannst du anstelle des Quarzes auch den internen 8MHz RC-Oszillator nehmen. Als Anlage ein Auszug aus meiner Schaltung. Die Brücken (BRx sind dem einseitigen Layout geschuldet - einfach wegdenken)
vorsehen? Einer zuviel schadet nicht - einer zuwenig kann fiesen Ärger bereiten (sporadische Fehler).
-
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-Interface mit Attiny2313
Hi >Leider empfange ich am PC nur Müll. >#define FCPU 8000000L Interner RC-Oszillator? MfG Spess
Danke für die Antworten. Also: 1. Die Kommunikation via UART-Interface habe ich schon einmal hinbekommen, auch ohne externes Quarz. Es soll ja auch nur ein Testaufbau sein. Leider habe ich das Programm von damals verlegt :-( 2.Ja, ich verwende den internen RC-Oszillator
-
Thread
Midi Signal mit Atmega8 erzeugen
! Denn so vermeidest du 'stochern im Nebel'. Du gibst (zumindest denkst du das) etwas über die UART aus und die Gegenstelle reagiert einfach nicht. UNd dann ist die Frage gross: Wo liegt der Fehler? Teil des Problems besteht darin, dass dir die Gegenstelle nicht mitteilt, warum sie nichts tut. Bei
' 1 MHz > $Baud = 31250 ' MIDI-Baudrate (31,25kBit) sieht verdächtig nach internem RC-Oszillator aus, und wird deshalb praktisch nicht zuverlässig oder gar nicht funktionieren!
-
Thread
C-Code für Zähler mit INT, Ausgabe per UART streikt
Ich habe eine Variable "n" erstellt, mit der ich die Impulse zählen will. Das ganze soll dann per UART an den PC geschickt werden. MAX232 mit Kondis ist vorhanden, echte RS232 ebenfalls. Als Oszillator nutze ich den internen, aber für erste Test sollte es reichen. UART ist initialisiert wie hier
BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate #define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler. #if ((BAUD_ERROR<900) || (BAUD_ERROR>1100)) #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! #endif int n=0; void uart_init
-
Thread
Zeigt her eure Kunstwerke (2014) Gesperrt Bilder
klappe ich nicht mal mein Notebook auf, noch drücke ich irgendetwas an der Anlage. Es ist ein Fehler der Kollegen, sich mit Notlösungen zufrieden zu geben.
ich glaube da stürtzt der DSPIC ab, aber fängt sich gleich wieder----> ist wohl ein Fehler in der Empfängerroutine....ist ja noch beta und so....
-
Thread
UART mit R/C Oszillator
Es geht um Atmega und Attiny, kein konketer Typ. Soweit mir bekannt ist, kann man den UART nicht gut mit R/C Oszillator nutzen, weil dessen Taktfrequenz nicht genau eingehalten wird und von der Temperatur abhängt. Ich hatte mal ein Modem, das hat die Übertragungsrate der seriellen Schnittstelle
unbedingt monoton steigend. Und wenn man wirklich genaue Zeiten messen will, ist man mit einem RC-Oszillator immer noch fehl am Platze, glaube ich. Denn die sendende UART, die man als Zeitbasis für die Kalibrierung nimmt, läuft ja auch nicht unbedingt supergenau...
-
Thread
Na wunderbar - Fusebits: Ausgesperrt aber mit den richtigen Eingaben?
Extosc ist doch ein oszillator und kein quarz... versuche es mal mit externem Takt
Sean Goff schrieb im Beitrag #3486581: > Extosc ist doch ein oszillator und kein quarz... versuche es mal mit > externem Takt Glaub ich nicht, sonst wär der Schmus mit 258CK,64MS Unsinn. Eher: EXTOSC = interner Oszillator mit externem Quarz. Was du meinst heisst
-
Thread
LPC800 existiert (fast) nicht in diesem Forum
Fuses (fast) immer gesetzt werden Nö, so häufig nun auch nicht. Am besten läuft er ohnehin vom internen RC-Oszillator, und das ist die Voreinstellung. (Vor allem wacht er dann schnell auf.) Aber hier geht's um LPC800, nicht um AVRs …
Wenn das daneben geht ist der uC aber nicht "verfused", der Bootloader startet immer noch mit dem internen Oszillator :-)
-
Thread
was spricht eigentlich gegen die xmega? Gesperrt
auch für beides! Das TSSOP-20 ist praktisch genauso groß wie ein SO-8, ich spare aber ISP-Pins (das UART ist sowieso rausgeführt). Faszinierend, ein ARM braucht weniger Platz als ein ATtiny! Auf der anderen Platine ist flashen per UART auch ein Bonus, weil das UART sowieso mit einem PC verbunden ist
paar andere 8 PWM 3 SPI 8 UART 2 I²C 50 MHz, 3 bis 5 Volt
-
Thread
Datensatz aus UART "gewinnen"
Ich kann eigentlich kein Fehler im code sehen. (bis auf das C Dateien auch die Endung .c haben sollten). Hast du einen Quarz oder nutzt du den internen Oszilator?
Hast du mal ausgerechnet wie groß der Fehler der UART bei 115kBaud ist? Denn ich habe die Geschwindigkeit mit keinem ATMEGA stabil zum laufen bekommen!
-
Thread
STM32 für Einsteiger - der Artikel zum Krieg (µC Wahl)
. So z.B. wird die UART-Ausgabe immer in einen Zwischenbuffer geschrieben und ein anderer Task sendet die Daten wenn der UART wieder frei ist. Somit "hängt" die CPU nie an einer Programmposition. > Ach so, wie groß ist
holger schrieb im Beitrag #3501769: > Also immer vorsichtig wenn jemand mit acht UARTS wirbt. > Sechs davon kann man sowieso nicht nutzen. Aber man bezahlt sie. Beim Xmega kann man sie nutzen wenn man denn wirklich acht UARTs braucht- und dafür Einschränkungen bei anderen Funktionen
-
Thread
LCD Ansteuerung mit ATtiny 2313
irgendwo aus Netz. Nein. Schauen wir mal deine Fuses an. Da steht "Int RC Osc. 8Mhz". D.H. interner Oszillator ist deine eingestellte Taktquelle, mit 8MHz. Dann steht etwas oberhalb noch "Divide clock by 8 enabled". Dein Takt aus dem internen Oszillator wird also noch durch 8 geteilt. Dein Controller
am Anfang angehängt habe aus dem Internet kopiert und bei Bascom nur eingefügt, ich glaub das war Fehler Nr.:1 Fehler Nr. 2 : Ich habe beim Programmieren nie vorher manuell erased sondern immer gleich auf write dann bekomme ich zwar eine Meldung "writen to flash" aber es passiert einfach nix.
-
Thread
Welche max. Datenübertragungsrate bei internen Taktgeber?
. 2 AVRs möglich sind wenn keine genaue externe > Taktquelle zum Einsatz kommt sondern nur der interne Taktgenerator. > > Hat schon jemand Erfahrungen hierbei gesammelt? Der interne Oszillator wird bei 25°C und 3V kalibriert. Unter diesen Bedingungen sind 4800 oder 9600 mit gesetztem U2X-Bit
Ich habe mit RC-Oszillator + UART nur schlechte Erfahrung gemacht. Sowohl mit Atmegas als auch mit Xmegas. Die Frequenz hängt zu sehr von der Temperatur ab.
-
Thread
VUSB - Device wird nicht erkannt.
dann noch läuft. Für V-USB ohne eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet (interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein. Muss man probieren.
läuft. Für V-USB ohne > eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet > (interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein. > Muss man probieren. @ Birgit Pie (bpie) Vielleicht könntest du den ATTiny45 mal mit einem 12MHz Quarz bestücken und probieren ob
-
Thread
Atmega48PA RS232 Problem
oben. >Ich werde morgen versuchen den Schritten zu folgen Bei 1MHz bekommst du bei 9600Bd einen Fehler von 7%. Mit Double Speed kommst du auf (theoretische) 0,2%. Allerdings mit verminderter Störsicherheit. Wenn dein 1MHz-Takt vom internen RC-Oszillator kommt, wird das ganze eh zum Vabanquespiel.
>Ich werde morgen versuchen den Schritten zu folgen > > Bei 1MHz bekommst du bei 9600Bd einen Fehler von 7%. Mit Double Speed > kommst du auf (theoretische) 0,2%. Allerdings mit verminderter > Störsicherheit. > > Wenn dein 1MHz-Takt vom internen RC-Oszillator kommt, wird das ganze eh > zum
-
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
USART@19200 Baud Atmega328P an BTM-222
1stop bit UCSR0C = (3<<UCSZ00); } [/c] Ich habe hier im Forum schon das Tutorial über den UART durchgelesen und das Datenblatt des Atmega328P gewälzt (die USART-Funktionen sind größtenteils daraus übernommen). Ebenso hab ich hier im Forum nach dem Fehler gesucht und anhand des Forum-Beitrags http://www.mikrocontroller.net/topic/160419 die Fuses bzw. "SUT_CKSEL" vom internen Taktgeber auf "Ext. Crystal Osc. 8.0-..." gesetzt, so dass der Atmega nun auch den externen Oszillator verwendet. Allerdings hat dies keinen Erfolg gebracht. Ich kann im Schaltungsaufbau nirgends
-
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
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
WS2812B mit 3.3V ansteuern
codiert als 1 1 0) die Kommunikation betreibe - bleibt das Problem mit den 3.3V. Einfache Logikgatter fehlen mir zur Pegelwandlung, deshalb die Idee mit dem direkten ansteuern. Sobald ich Fortschritte gemacht habe, werde ich mich mal an der Wiki wenn möglich austoben, und für die Launchpads von TI kleine
verlängertem 1 Puls ist das Flackern weg und sie laufen sogar bei 3.3 V stabil. Offenbar hängt der interne Oszillator von der Betriebsspannung ab.