-
Thread
FPGA Modul mit vielen IO
EP4CE75 ein Klax. Du hast nicht gelesen was der Threadersteller will oder? Der will die vielen UARTs nicht im FPGA, sondern er will die Leitungen der vielen UARTs nur mit dem FPGA verbinden. Quasi ein großer Crosspoint-Switch 128x130. Digital. Und die Leistungen werden für viele UARTs verwendet.
ankommen, aber nicht an der Korrektheit der Daten. Und dann hoffe ich, dass das Protokoll das da über UART gesprochen wird auch Fehler erkennen und vielleicht sogar korrigieren kann.
-
Thread
Atmega 8 + dallas 18s20 + Neuling (never ending story)
Hallo zusammen, könnte es eventuell am 8 Mhz Oszillator gelegen haben? Wenn ich nun den internen RC nutze funktioniert die ROM Abfrage ohne delay. Jetzt prüfe ich umgehend, was passiert, wenn ich Uart wieder dazu schalte.
Hallo Perlbastel, ein Fehler scheint hier zu liegen: Chris schrieb im Beitrag #2709413: > int reset(void) > { > //Pin als Eingang > DDRC &= ~(1<<PC5); > //internen Pullup aus bzw. Pin auf Masse ziehen wenn DDRC.5
-
Thread
Endlich neue Probleme! :-(
Stell mal runter auf 1200 Baud, eventuell auch noch weniger. Der interne Oszillator ist zu ungenau.
Hi >Er arbeitet mit 1 MHz (interner RC-Oszillator --> ungenau!) >> - Welche Baudrate willst Du einstellen? >Ich möchte 9600 Baud verwenden. Wenn du dir die Baudraten-Tabellen im Datenblatt angesehen hättest, dann wüßtest du, da
-
Thread
Geschwindigkeit von Programm
Ich wollte damit auch nur zeigen, dass selbst bei einem ungenauen Takt der Uart immerhin bis 4800 Baud funktioniert. Klar heißt das nicht, dass das bei jedem so ist. Nur bei 300 sollte es selbst mit interner Taktversorgung immer ordentlich funktionieren.
Habe mal die Fuses angeschaut: Die Taktquelle war als interner Oszillator 8 MHz definiert. Außerdem war dieses Bit gesetzt, was den Takt durch 8 teilt, das habe ich rausgenommen und schon läuft das ganze angemessen schnell. Allerdings scheint es, dass ich
-
Thread
Was bedeutet UART Frame Error genau?
Oder Du hast Dich tatsächlich bei der Baudrate verrechnet. 4Mhz und 9600 Baud ist kein Problem, der Fehler wäre nur 0.2%. Ich tippe mal auf ein falsch initialisiertes UART Controllregister.
Bei der Fleury-lib reicht doch: [c] #define UART_BAUD_RATE 9600 ... uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) ); [/c] zum initialisieren, oder? Ich glaube man muss 8 Datenbits, ein Stopbit, und keine Parität einstellen, und das ist
-
Thread
EMV und aktuelle uC
Datenblätter vergleichbar sind). Die L0 sind auch von der Takterzeugung her flexibler, man kann z.B. einen internen Oszillator mit 1MHz haben. Die STM32G0 strahlen wieder etwas mehr und haben weniger VDD/GND-Pinpaare, aber dafür haben sie als einzige STM32x0xx einen internen Oszillator, der stabil genug für UART
im* µC abspielt, kommt dann gar nicht erst auf die Leiterplatte. Und wenn du dir dann noch den internen Oszillator leisten kannst, dann ist Ruhe. Und wenn es wegen hoher Genauigkeitsanforderungen ein externer Taktgeber sein muss, dann nimm keinen Oszillazor mit ns-Flanken, sondern einen Quarz, der
-
Thread
ATMEGA328P-PU: USART sendet ungültige Zeichen bei 8MHz, funktioniert aber bei 1 MHz
Problem, bei dem ich nicht mehr weiterweiß... Die Fusebits sind so gesetzt, dass der µC auf dem internen RC Oszillator läuft, bzw. laufen sollte: FUSES = -U lfuse:w:0xE2:m -U hfuse:w:0xd9:m Leider bekomme ich auf meinem Serial-Terminal nur Fragezeichen, egal welche Baudrate ich beiderseits eingestellt
Klaus V. schrieb im Beitrag #4863978: > Ich bin dankbar für jeden Versuch mir zu helfen! Der interne Oszillator ist warscheinlich nicht genau genug um die Baudrate ausreichend korrekt zu erzeugen. Du wirst womöglich auf längere Sicht einen Quarz verwenden müssen. Klaus V. schrieb im Beitrag
-
Thread
Empfindlichkeit von Quarzoszillatoren
fast immer recht grob daneben, einfach weil man bei der Auslegung weder die Kapazität der Pins des internen Oszillators kennt, noch die des Layouts. Bei Standardanwendungen wie Ethernet, UART oder USB sind <65ppm Fehler natürlich egal. Aber wenn man die 10ppm herausholen will, kommt man um Finetuning
WLAN-Modul höchstwahrscheinlich für den RF-Teil und das SDIO verwendet. > - Selbst wenn der Oszillator anläuft, kann durch falsche Kapazitätswahl > der Oszillator später wieder stoppen oder falsch laufen? Ja, wäre möglich. Ein weiterer möglicher Fehler wäre zu hohes oder zu niedriges Spannungsniveau
-
Thread
Atmega 1284p lässt sich häufig nicht flashen
entwickle aber keine Schaltkreise, die das extern brauchen. Ich benutze bei nackten AVR entweder den internen R/C Oszillator oder bevorzugt einen 7,3728 MHz Quarz (wegen UART Baudraten). Das klappte bisher immer auf Lochraster, Steckbrettern, fliegender Aufbau mit ungekürzten Beinchen und ich muss mir
liegt, was den Schwierigkeitsgrad angeht. Naja... > Ich benutze bei nackten AVR entweder den internen R/C Oszillator oder > bevorzugt einen 7,3728 MHz Quarz (wegen UART Baudraten). ... ich habe bisher ausschließlich mit 8, 14.7, 16 oder 20 MHz gearbeitet und hatte nie Probleme. Außerdem alles
-
Thread
Atmega8 + STK500 - USART funktioniert nicht
weg, dann bleibt es bei 1 (einem) Stopp-Bit. wenn es das nicht ist, wäre mein tipp, dass der interne oszillator zu ungenau ist.
@Conehead: Der interne Oszillator des STK500 ist schon ziemlich genau. Zumindest reicht es, um UBRR (mit Rundung) richtig zu belegen. Andererseits hat der interne RC-Oszillator des ATMega8 für eine saubere Übertragung die
-
Thread
STM8 internal RC Genauigkeit
Hallo, möchte einen STM8S003 einsetzten und würde gernen eure Erfahrungswerte über den internen RC hören... Reicht der interne RC aus um stabil über UART zu kommunizieren? Eine Geschwinigkeit von min. 115kbit ist erforderlich THX
geht das oft > noch, aber bei derartig hohen Raten mit Sicherheit nicht mehr. Der relative Fehler ist bei *allen* Baudraten der selbe. Wenn der OP mit RC den internen Oszillator meint: Das sollte von der Genauigkeit her gehen. STM8 sind ja keine AVR...
-
Thread
Atmega8 und I2C-Display startet nicht
SDA) --> PCF8574 SDA --> TC2004-LCD Atmgea Pin28(PC5/SCL) --> PCF8574 SCL --> TC2004-LCD Die internen Pullups für PC4 und PC5 sind an. Den Programmer über ISP. Dazu noch Grundbeschaltung mit Kondensatoren und 5V-Spannungsregler. Hab nach jedem Senden eines I2C-Pakets eine Ausgabe auf den UART
angestellt Dazu muss man nur das Datenblatt des Mega8 lesen. Dann sieht man schnell, das der interne Oszillator auf 1, 2, 4 oder 8 MHz gefused kann. Armin R. schrieb im Beitrag #4597056: > Die internen Pullups für PC4 und PC5 sind an. Wie oben angemerkt, reicht das für den I²C Betrieb nicht
-
Thread
Seltsames Problem mit einer Mikrocontrollerkarte
liefern.Achja, er kommt offensichtlich nicht mal zur Initialisierung, denn gemerkt haben wir den Fehler, weil die Controller sich nicht via UART melden, gemessen ist der TX Pin Low, was nach initialisierung aber nicht der Fall ist und bei der funktionierenden Platine auch nicht vorkommt, dort springt
durchgemessen? AVcc und AGnd ebenfalls nachgemessen? Nutzt Du die PLL für die Erzeugung des internen Takt aus dem externen? Ich würde probehalber den Takt aus dem internen RC-Oszillator erzeugen. Grüßle, Volker
-
Thread
ATMega32-16PU für die Arduino IDE vorbereiten und benutzen
mit einem Quarz getaktet wird. Was bei Arduino üblich ist. Im Lieferzustand wird er über einen internen 8Mhz R/C Oszillator getaktet, dessen Frequnez durch 8 geteilt wird. Für serielle UART Kommunikation (also den Arduino Bootloader) ist das nur notdürftig geegnet. Also ja, schließe einen Quarz an
eine bessere Taktquelle erfordert, als den internen R/C Oszillator. Zumindest wenn es zuverlässig gehen soll. AVR Mikrocontroller werden normalerweise ohne Bootloader verkauft. Die Arduino IDE unterstützt beide Methoden, UART mit Bootloader und
-
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
Raspberry Pi Verbindung zu Atmega 328P UART
Der interne Oszillator im AVR ist zu ungenau für übliche UART-Anwendungen. Oder soll das an dem ewig langen kabel da ein Quarz sein... Ohje Einige andere wichtige Bauelemente scheinen dem AVR auch zu fehlen
Simon K. schrieb im Beitrag #2844906: > Der interne Oszillator im AVR ist zu ungenau für übliche > UART-Anwendungen. > > Oder soll das an dem ewig langen kabel da ein Quarz sein... Ohje > > Einige andere wichtige Bauelemente scheinen dem AVR
-
Thread
Wie OSCCAL einstellen?
ich OSCCAL einstellen, dass mein ATMega 8 mit ungefähr 12 > Mhz läuft, wenn die Fuses auf 8 Mhz interner Oszillator > eingestellt sind? Das hängt von der Betriebsspannung, der Temperatur und dem individuellen Chip ab. Das Register ist ja dazu da, um den Oszillator zu kalibrieren, weil er so große
Vielen Danke euch allen! Mit Quarz geht es nun einwandfrei. Das mit dem internen Oszillator war echt ne Schnapsidee. Der schwankt laufend in der Frequenz. Für UART reichts aber. Falls es noch jemand braucht: Wenn man OSCCAL auf 240 einstellt, läuftm mein Mega8 mit ca. 12 Mhz.
-
Thread
Systick zu langsam / Hardwarefehler
Schaltpläne posten, aber letztendlich handelt es sich nur um den Prozessor mit Hühnerfutter, der ein paar UARTs betüddelt. 99,9% werden ohne Fehler gefertigt, weshalb es in meiner Frage nicht um einen systematischer, sondern Einzelfehler geht. Dieser zeigt sich wie folgt: Der Systick läuft ca. Faktor
Folglich funktionieren einige Timeouts auch nicht wie erwartet. Das Interessante ist, dass die UARTs mit der richtigen BAUD-Rate arbeiten! D.h. deren Taktquelle ist in Ordnung. Also bin ich von einem defekten Controller ausgegangen, doch auch dies hat den Fehler nicht behoben! Bevor jetzt Aussagen
-
Thread
AVR BASCOM Tiny15L - Problemchen
Hast du den Oszillator auf 1,6MHz calibriert? Oder tuckert der irgendwie mit umbekanntem Takt vor sich hin? Wobei ich UART mit RC-Oszillator sowiso für Roulett halte. Nimm lieber einen AVR mit Hardware-UART und Baudratenquarz
ein effizientes Programm schreiben soll... - Sorry... Da ich mich aber noch nicht mit Software-UART mit automatischer Baudraten-Anpassung beschäftigt habe, kann ich dir leider nicht helfen. Denn mit einer fest berechneten Baudrate wird das ein Lottospiel, weil der interne RC-Oszillator für UART zu
-
Thread
FT232RL mit Attiny2313
Der interne RC-Oszillator bietet keine sehr verläßliche Basis und streut von Exemplar zu Exemplar. Vllt einfach mal die Baudrate runter setzen. Wenns dann läuft, dann tippe ich auf Baudratenfehler. Gruss, Heinz
Markus D schrieb im Beitrag #3319952: > hatte auch schon gedacht, das der interne Oszi > evtl. nicht sauber läuft?!?... So ist es, der interne Oszillator ist für den UART ungeeignet.
-
Thread
atmega8 uhr
Man Sonic was redes du denn da, Quarz so viel fehler wo hast du denn Quarz gekauft ich glaube du hast in selber gebastelt. Wenn du den externen Quarz als ungenau bezwéichnst was sagst du dann zu dem internen Quarz vergleich mal die Datenblätter befor
wollte mir auch eine Software Uhr basteln. Welchen Takt sollte ich denn jetzt dafür verwenden? Den internen oder ist doch besser meinen 4MHZ Oszillator über XTAL1? Es gibt ja auch noch die Möglichkeit einen Oszillator zwischen XTAL1 und XTAL2 zu schalten? Also, welches ist auf Dauer gesehen die Beste
-
Thread
Müll in serieller Übertragung wenn Kondensator am Quarz berührt wird
ein 4808? Hat der 1% garantiert oder typisch? Schon dieser mit "nur" 1,8% Genauigkeit seines internen 16/20 Mhz Generators noch etwas ältere AVR beweist die Praxistauglichkeit eines quarzlosen Designs mit UART-Aktivitäten und unter Außenbedingungen. > Dann machst Du aber (gerade für Anfänger) ein
Gerhard H. schrieb im Beitrag #7624341: > Schon dieser mit "nur" 1,8% Genauigkeit seines internen 16/20 Mhz > Generators noch etwas ältere AVR beweist die Praxistauglichkeit eines > quarzlosen Designs mit UART-Aktivitäten und unter Außenbedingungen. 1.8% reichen natürlich, wenn die Gegenstelle
-
Thread
Ein Code, mehrere Controller.
oder? Dein Problem liegt nicht in hochzählen, sondern in deinem Programm. Max. möglicher Fehler mit internem Oszi beträgt 10%. Dein Fehler ist *viiiiieeeeeel* grosser. Willst du "deinen" Code endlich posten oder nicht ?
was es hier noch über die Ursache zu rätseln gibt - dachte, es wäre längst klar, daß der unpräzise interne Oszillator des Tiny für die Abweichungen verantwortlich ist. Knapp 4% reale Abweichung für einen Oszillator, der unkalibriert +/- 10% haben kann, ist doch auch plausibel, oder?
-
Thread
Problem UART Kommunikation 2er AVRs
der Baudrate auf 1200 funktionierts nun. Die blinkenden LEDs laufen schon gut auseinander mit dem internen Takt. Einen externen Oszillator habe ich nicht, aber werde mir wohl nun einen Anschaffen. Danke euch!
> ja, ob das parallel läuft oder langsam auseinander driftet. Seit wann hat ein AVR einen internen Quart? Er hat einen internen Oszillator, welcher mit 8MHz läuft. Wenn der Clock-Divider drinnen ist läuft er sogar nur auf 1MHz. Könnte hier der Fehler liegen?
-
Thread
ATTiny13A vom Breadboard zu Rasterplatine und es funktioniert nicht mehr
und 4 hängen TX und RX; Klingt nach serieller Übertragung. Wie erfolgt den die Taktversorgung? Interner RC-Oszillator? Könnte sein, das der kalibriert werden muss.
Sockel verwenden. - Wie genannt, Stützkondensator. Ingo W. schrieb im Beitrag #5715729: > Interner RC-Oszillator? ATtiny13 kann nur internen Takt. UART und interner Takt ist "kritisch", der Taktgeber ist temperaturabhängig. Baudrate weiter nach unten setzen (mehr als 38400 Baud habe ich
-
Thread
Netzwerk Steckdose + Anhand welcher Daten wähle ich einen Quarz aus? + weiter Fragen (Bootloader)
für die Infos bezüglich Quartz/Oszillator. Hast du Empfehlungen nach welchen Kriterien die Frequenz auszuwählen ist? Für UART leuchtet mir das ein. Nur bei SPI hab ich z.B. keinen blassen Schimmer. Zu der Sache mit den 230V: Bevor
tatsächlichen Baudrate bei deinem Quarz raus lesen. Je > kleiner dieser Abweichung um so besser. Für den UART ist es völlig egal, ob der Fehler 1ppm oder 1 Promille beträgt. Bei hoher Leitungsqualität geht die Übertragung erst schief, wenn sich der Fehler innerhalb eines Bytes, also meist über 10 Symbole, über
-
Thread
ATMega8 an Serieller SS sendet Müll
/io.h" /* USART-Init beim ATmega16 */ #ifndef F_CPU #define F_CPU 16000000 /* Oszillator-Frequenz in Hz */ #endif // Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt) #define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1) #define UART_BAUD_RATE 19200 int main(void) { /* I/O Settings */ UCSRB |= (1<<TXEN); // UART TX einschalten UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 ); UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU
-
Thread
AT90S2313 gegen ATtiny2313 austauschen
weiß jedoch nichts darüber. Welche Fuse Bits muss ich denn da setzen, damit ich einen externen Oszillator benutzen kann? Auf welchen Frequenzen schwingen die internen Oszillatoren? Mir währe echts ehr geholfen, wenn ihr mir weiterhelfen könnt. Und bitte keine Verweise auf das entsprechende Datenblatt
Der ATTiny2313 ist standard im 1MHz getacktet mit interne Oscillator. Vielleicht hilft das was... Und 1 MHz und dan UART 9k6 gab glaub ich 6.5% Fehler. Aber wenn du es programmiert mit eine andere Tacktwert, gibt es sicher fremde Sachen. P.S. Meine Entschuldigungen
-
Thread
STM32F407-DISC1 Board defekt
erreicht. Jetzt kann ich mich wieder der Frage zuwenden, ob mein repariertes Boar vielleicht noch einen Fehler hat, der bewirkt, daß der UART beim Starten der Anwendung nichts ausgibt, während das Board C (heiliges Anwendungsboard) diesbezüglich funktioniert. So, da sind wir jetzt.
8MHz HSE-PLL läuft auch. Mache jetzt den UART Test.
-
Thread
int RC-Oscillator kalibrieren ohne Stk500
Wenn man die UART benötigt, muß man immer einen externen Quarz anschließen, sonst hat man keine Zuverlässigkeit. Rein theoretisch kann man auch den internen RC-Oszillator durch einen externen Quarz nachkalibrieren
Toleranzbereich. Dabei zeigte sich, eben auch bei unterschiedlichen Temperaturen des AVR's, das der interne RC Oszillator garnicht mal so schlecht ist, nachdem man ihn kalibiriert hatte. In meinem Projekt besteht die Möglichkeit über ein Menu manuell nachzu kalibrieren. Da der UART des Projektes nur
-
Thread
Sehr kleiner Prototyp Wo am billigsten? 28x16mm
Budig Das ist nen Uhrenquarz... den brauch ich für den Power Save Modus und zum kalibrieren des Internen Oszillators (wegen UART) Ja bei Reichelt gibts schöne Miniquarze... leider alle über 16MHz... Oszillatoren sind auch schön klein, brauchen aber eine feste Betriebsspannung von 3,3 V.. die kann
Budig Das ist nen Uhrenquarz... den brauch ich für den Power Save > Modus und zum kalibrieren des Internen Oszillators (wegen UART) Z.B. Reichelt "32,768 PGD-9" (0.60 EUR, sollte auch noch von Hand lötbar sein) Irgendwie fehlen bei dem Quarz dann aber noch zwei Kondensatoren, oder? Ich finde es
-
Thread
Komisches Verhalten bei CPU-Frequenz und UART
Stephan Kempa schrieb im Beitrag #2270625: > Atmega168 mit internem Quarz Wo hast Du den her? Extra von Atmel produzieren lassen? Offiziel gibs sowas jedenfalls nicht. Aber vermutlich läuft auch Dein Atmega168 wie alle anderen mit dem internen RC-Oszillator.
Takt berechnet. Und damit bleiben es immer 4800 Baud egal welchen Takt du einstellst. ps: der interne Oszillator ist kein Quarz sondern ein RC Oszillator. Dieser ist stark Betriebsspannungabhängig (und auch Temperatur) und daher ungeeignet um eine Baudrate einzustellen. Es sei denn du benutzt die
-
Thread
ISR Code schneller machen?
(); state_UART_MODE = FINISH; // Kalibrierung beenden done_cal_OSC = true; // Merker Oszillator syncronisiert } if (count_fail > 9) { // zu viele ungültige Messwerte state_UART_MODE
interrupt */ ATOMIC_BLOCK (ATOMIC_RESTORESTATE) { // wegen ISR(TIMER1_COMPA_vect) UART0_CONTROL |= _BV(UART0_UDRIE); } } [/c] Das läuft jetzt schon viele Minuten ohne Fehler, sodass ich sicher davon ausgehen kann der Fehler ist gefunden. :-) :-) Soll ich vorsichtshalber
-
Thread
UART Studienarbeit dringend :D
UART Studienarbeit schrieb im Beitrag #4721226: > also ich kann den mega32 nicht mit dem internen 8Mhz und > 115200baud > laufen lassen? Und nochmal: Schaue dir das Timing an. Von beiden! Vergleiche
arbeiten, z.B. 38400, da beträgt der Baudratenfehler > nur 0,2% bei 8MHz, beim 7.3728MHz-Quarz ist der Fehler 0%. Nee, sorry, vergiss es, du nimmst ja den internen RC-Oszillator, hab ich gerade erst gesehen. Der ist wahrscheinlich zu ungenau. Das mit der niedrigeren BR wird auch nur dann funktionieren,
-
Thread
STM32F405RGT6 keine Verbindung über USB
Fehlt da nicht die Entkopplung der interne Spannung?
alles nachgelötet. Und dann hab ich noch folgende Anpassungen gemacht: 2x 22nF an den Quarz-Oszillator und R32 ausgelotet (der bewirkte, dass UART4-RX high war). Wenn man dann den S1 gedrückt hält (also boot0 auf 3,3V zieht), PA9 und PA10 auf GND zieht, während dem Einstecken des USB-Kabels dann
-
Thread
Atmega168PA-AU funktioniert nicht mit externem Quarz
Fehlinterpretation. Es wird nicht dazu gesagt, *was* denn nun "external" ist. Nur der Quarz oder auch der Oszillator? Abgesehen davon ist das anscheinend eine Arduino-IDE. AFAIK ist es bei Arduino gar nicht vorgesehen, den AVR mit einem externen Takt zu versorgen. Entweder interner RC-Oszillator oder interner
bei > Arduino gar nicht vorgesehen, den AVR mit einem externen Takt zu > versorgen. Entweder interner RC-Oszillator oder interner Oszillator mit > externem Quarz. Das ist eine Boarddefinition, welche der IDE hinzugefügt werden kann. Ist also nicht wirklich Arduino. Nur die IDE. In der Boarddefinition
-
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
ATMEGA162 - UART will nicht...
letzten Threads in diesem Forum gewühlt... Im Beitrag "Fusebits bei Quarz" von wulf hieß es, dass bei Uart-Anwendungen der interne Oszillator nicht genau genug ist.. Stimmt das? Wie soll ich dann meinen Mega162 fusen, damit ich 'nen normal 4MHz Quarz zwischen XTAL1 und XTAL2 hängen kann? (Hab zwar noch 2
Hallo Waldemar, hab den Fehler gefunden, mit den Fuses hat alles gepasst, nur mit dem initialisieren der Uarts habe ich einen Fehler gemacht: statt: // 8 N 1 UCSR0C = (1<<URSEL0)|(1<<UCSZ10)|(1<<UCSZ00); UCSR1C = (1<
-
Thread
DS18B20 Tempsensor mit PIC18F - Oszillatorprobleme?
ich mir das Datenblatt durchlese stellt sich mir die Frage ob ich den DS18B20 überhaupt mit dem internen Oszillator ansprechen kann, oder ob ich einen externen verwenden muss. Kann ich den DS18B20 überhaupt mit dem internen Oszillator verwenden? Bzw. wenn nicht: Kann jemand einen Oszillator von Reichelt
notiert :-S Ich dachte der PIC läuft default mit 8MHz? Auf mehr als 8MHz bekomme ich den mit dem internen Oszillator auch nicht, richtig? Kann man den Code auf 8MHz oder weniger Takten? Vielen Dank danny
-
Thread
Geschwindigkeisproblem mit RS232 und ATMega8
Wert bekommst. Ich habe hier schon viele Atmegas gehabt, deren interner Oszillator um ca. 5% von der Nennfrequenz abwich und entsprechend mit dem OSCAL kalibriert werden mussten. Schau mal ins Datenblatt unter den ATmega8 Typical Characteristics => Internal Oscillator
Hi >Mit internem Takt sind max. 4800 baud möglich, ... Mit 8MHz sind bis 38400Bd mit 0.2% Fehler möglich. Allerdings scheitert das an den besagten Taktfehler. MfG Spess
-
Thread
MSP430 - serielle schnittstelle nutzen, aber wie ?!
angeschlossene 32kHz Quarz wird nämlich nicht automatisch als Clock Source verwendet, sondern der interne Oszillator, welcher ca. 800kHz hat. mfg, thomas
sind LFXT1 (1. Quarzoszillator, auch für Uhrenquarze), XT2 (2. Quarzoszillator) und DCOCLK (der interne Oszillator, der nach einem Reset standardmäßig aktiviert ist und mit etwa 800kHz schwingt). Je nach gewünschter Konfiguration kann man jetzt diese Taktquellen (mit oder ohne Vorteiler) an die
-
Thread
Welche ARM Modelle eignen sich für Anfänger?
also mit 16 MHz. Nicht jeder STM32 läuft zu Anfang mit 16MHz. Die STM32F1xx nur mit 8MHz da der interne RC Oszillator auf 8 MHz kalibriert ist. Der STM32F2xx und STM32F4xx mit 16 MHz. Steht für den jeweiligen Chip im Datasheet unter HSI RC Oszillator.
#3872217: > Nicht jeder STM32 läuft zu Anfang mit 16MHz. Die STM32F1xx nur mit 8MHz > da der interne RC Oszillator auf 8 MHz kalibriert ist. > Der STM32F2xx und STM32F4xx mit 16 MHz. Steht für den jeweiligen Chip im > Datasheet unter HSI RC Oszillator. Danke für den Hinweis :-) Liegt wohl
-
Thread
Probleme mit UART_RX mit AtMega2560
Zeit lang an einem recht großen Programm. Jetzt bin ich an der Stelle angekommen, bei der ich die UART0 verwenden muß. Diese UART wird nur empfangen können. Daten: 2400_8n1. Habe schon etliches ausprobiert und komme nicht drauf was da jetzt falsch sein sollte. SpeicherOszi direkt an PortPin, Signal
FramingError, DataOverRun if (!(UCSR0A & ((1<<FE0) | (1<<DOR0)))) { uart0zaehler++; //global data[uart0zaehler] = UDR0; if (uart0zaehler == 69) { uart0zaehler = 0; } } else //bei
-
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
Taktfrequenz messen
Hi! Ich habe einen Mega128 extern mit 8Mhz getaktet, weil ich dem internen Takt nicht getraut habe. Leider konnte ich die Masse Cs nicht mit anlöten, weil mir die Pins bei einem früheren Problem mit dem Oszillator "abhanden" gekommen sind. Somit fehlt mir nun die Masseanbindung, um ein Signal messen zu können. Der Oszillator scheint zu schwingen, weil die Fuses auf ext. gesetzt sind und ich noch immer programmiern kann, aber ich traue dem Takt nicht über den Weg. (Problem mit der UART) Gibt es einen Weg den Takt trotzdem
-
Thread
RS485 mit atmega und 1 Mhz takt
jetzt lies mal nach wieviel Abweichung der interne RC Oszillator so hat.
Weniger als 2400 geht sicher auch. Allerdings kannst du dich nicht darauf verlassen, dass der interne R/C Oszillator seine Soll-Frequenz langfristig genau genug einhält. Für Experimente reicht es meist, aber verkaufen soll man so etwas nicht.
-
Thread
nach Takterhöhung an ATtiny25 nur noch Müll aus der Sotware Uart
meinst einfach einen ext. Quarz anschließen. Der int. Quarz erzeugt dann sicher mit der Software Uart tolerierbare Fehler bis zu den 1Mhz und darüber ist die Fehlerquote zu hoch und das schei... Timming gibt der Uart den Rest. Ich werde es direkt heute Abend testen. Vieleicht probiere ich das ganze
int. Quarz erzeugt... Ja, aber die 22p-Kondensatoren nicht vergessen. Der ATTiny hat keinen internen Quarz, sondern einen RC-Oszillator. Deswegen ist der ja so grottenschlecht. MfG Spess
-
Thread
Atmega UART mit internen Takt nachregel anhand der empfangenen Daten
1. Ist ein externer "Baudratenquarz" zu teuer? 2. Es gibt Controller deren interne Taktquelle hinreichen exakt für UART sind.
doch da, oder? Damit hättest du auch gleich genauere Frequenzen für Timer o.ä. und nicht nur für ein UART. > Noch andere Ideen? * Wenn sowieso zyklisch Daten ausgetauscht werden (also Timer-gesteuert), könnte man Nachrichten-Takt statt Bit-Takt verwenden. * Auf einem STM32 trimme ich den Oszillator
-
Thread
Messung niedriger Frequenzen schlägt fehl
C] .... UART_SendString( "Fehler: Ueberlauf\n" ); .... [/C] dann noch welche für Zahlen [C] void UART_SendUI32( uint32 number ) { char Buffer[10]; ultoa( number, Buffer, 10 ); UART_SendString
meinetwegen auch noch PIND auszugeben [C] .... UART_Dump( "TCNT1 :", TCNT1 ); UART_Dump( "ICR1 :", ICR1 ); UART_Dump( "PIND :", PIND ); ... [/C] Lass dir die Dinge als Text hinschreiben (OK, der Text "Fehler: Ueberlauf\n" ist ein
-
Thread
RS232 Schnittstelle mit Bascom
16MHz? (typisches Problem wenn man Code kopiert) Wird der Quarz auch benutzt und nicht etwa der interne Oszillator mit (Default: ) 1MHz. Kann man einfach testen: $Crystal-Zeile auf 1MHz stellen. Wozu dient das Printbin? Vielleicht verwirrt das ja das Hyperterm. Markus
Das Problem am internen Oszillator ist, daß er nicht temperaturstabil ist. D.h., selbst wenn es jetzt läuft, dann kann es gut sein, daß es an einem heißen Sommertag nicht mehr läuft. Markus