-
Thread
FT800 / FT810 Library
Wo hast Du keinen externen Quarz dran? An dem BT817/BT818? Dann wird ja einfach nur der interne RC-Oszillator verwendet, der hat auch 12Mhz. Der ist nur nicht unbedingt so präzise oder temperatur-stabil wie ein Quarz oder Resonator. Wenn ich in dem EVE_RiTFT50 Profil das EVE_HAS_CRYSTAL auskommentiere
Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit externer clock :-) => ich nutze den ganzen internen quatsch nicht mehr.... und.... Ich habe den Fehler gefunden, warum ich nicht mit mehr als ca. 25ms zyklus per dma auf den Chip schreiben konnte ohne das sich das System aufgehängt hat... Für das
-
Thread
ATMega328, komisches Verhalten bei fast vollem Speicher
counter 25 Byte die keiner kennt. Ups! Diese Programmierroutine ist aber nicht unbedingt als Fehler anzusehen, sondern eher als Reflex.
Tom, mir wird wohl nichts anderes übrigbleiben, wenn ich den Fehler finden werde. Ich hab mit dem Simulator noch nie etwas gemacht, aber ich werde mich einarbeiten. Ach ja, um Fehler bei der Stromversorgung (Ripple durch Schaltregler, usw.) auszuschließen, habe
-
Thread
ATMega644 UART
Hallo zusammen, ich benutze einen ATMega644 und will daten vom ADC über den UART Senden. Leider kommt da nichts an. Mit einem ATMega32 funktioniert es ohne Probleme d.h. dass mein Terminal Programm richtig geschrieben ist und der Fehler am uC liegt. Die Register hab ich auch angepasst
Nach dem http://www.engbedded.com/fusecalc/ läuft der Atmega644 mit dem internen RC Oszillator und ohne die CKDIV8 Fuse. Damit solltest du den Wert für die Baudrate mit 8 MHz berechnen. Gruß JackFrost
-
Thread
ATtiny Clock Recalibration ohne externe Referenz
sein > als die ab Werk kalibrierte Frequenz, also entspann dich mal. Wenn Du wirklich einen Fehler entdeckst dann schreib das in in ein paar Zeilen hin anstatt dich seitenweise aufzuspielen
einfach mit einem Wert multipliziert" und der vorgestellten Methode womöglich entscheidend, ob ein UART noch läuft oder nicht.
-
Thread
Fragen zu Digispark pro - USB und VirtualWire
Man müsste sich einen neuen Bootloader schreiben und die Register umleiten - also ein USB-SoftwareUART bauen mit Vendor und Product ID. Wie auch immer: Mit dem UART auf 6/7 komm ich auch zurecht :-) Für den ATTiny45 nutz ich den internen CLK 8MHz. Der Flankenabstand am Ausgang ist (bei diesem Tiny
> also ein USB-SoftwareUART bauen Richtig. > Für den ATTiny45 nutz ich den internen CLK 8MHz. Der R/C Oszillator kann ein paar Prozent von der Nennfrequenz abweichen. Schau mal im Datenblatt für welche Temperatur und
-
Thread
ATMEL ARM SAMD ohne Framework programmieren
ich aber 6.04us Da geht wohl irgendwo ein Takt verloren und wenn mein Oszi stimmt, liegt der interne Oszillator wohl fast 1% daneben. I
). Auf dem Board sind für 32kHz XTAL keine Cs. Scheinbar hat aber das Kabel gereicht, um den Oszillator anzuschwingen. Dann habe ich den Clock scnell wieder auf den internen 8MHz Osczi umprogrammiert.
-
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
UART zwischen 2 atmega16
Wenn du nicht weisst, was eine Fuse ist, dann verwendest du die R/C Oszillatoren. Und die sind für UART Kommunikation nicht genau genug.
gibt und dann z.B. eine quarzgetaktete Sekunde schältet und sich dann ansieht, was der Timer1 mit internem Oszillator dabei rausbekommt. Verändert man dann mit Föhn, Kältespray und LNT die Bedingungen, erkennt man schnell die Tendenzen, die bei allen Controllern gleich sind. DÜ per UART funktioniert
-
Thread
Arduino oder Mikrocontroller - Was ist besser?
, aber auch Garnichts > anfangen. Naja... das ist so nicht ganz richtig. Da die Teile einen internen Takt haben, rennen die schon los, wenn sie nur an eine passende Batterie geknöpert werden. Wenn mann´s richtig machen will, braucht man noch ein paar Abblock-Kondensatoren, ´ne LED und einen Taster
das lange ignoriert und stelle jetzt mit Erstaunen fest wie einfach und nützlich das ganze ist. Bei UART genauso. Manchmal gibts halt ne Einstiegshürde.
-
Thread
LPC1756 - Grundschaltung
Quarz: Wenn Du vor hast USB zu benutzten solltest Du einen Quarz nehmen, aus dem sich einfach per internem PLL 48Mhz erzeugen lässt. 12Mhz und 24Mhz sind hier eine gute Wahl. Ich persönlich bevorzuge Oszillator Module, die sind robuster weil man mit den parallel Kapazitäten nichts falsch machen kann, aber
springt der LPC nicht in den Flash-Code sondern ins Rom. Dort befindet sich ein Bootloader über den via UART0 der Chip programmiert werden kann. (Dafür gibt es kostenlose Upload-Tools, das Protokoll ist aber sehr einfach, kann man auch selbst schreiben). Würdest Du Dir jetzt den ISP-Pin, Ground, sowie UART0
-
Thread
ATMEL verändert einige Dinge im ATMega
im Beitrag #4438597: > Ich dachte auch, diese Variante wäre recht präzise (mir geht es nur um > UART). Da du ja im Bastelkeller arbeitest: Du kannst für den UART auch den internen RC-Oszilator probieren, ggf. kalibrieren. Hat bei mir bisher immer hingehauen und benutze ich immer für eigene Basteleien
Probleme mit einem M0 überhaupt > nicht Wann braucht man schon 20 Mhz... Das meiste ist auch mit 8 internen MHz locker bedient. Da nimmt man einfach die für UART hinreichend taktstabilen PB Typen, spart sich Quarz samit Kondis und gut ist.
-
Thread
Falsche Zeichen per UART
#4421779: > Die Fuse-Bits sind 0xE1 und 0xD9 Es ist übrigens auch keine allzu gute Idee, den /internen/ RC-Oszillator mit seinen +-3% Fehler für die serielle Schnitte zu verwenden: [pre] At 5V, 25°C and 1.0MHz Oscillator frequency selected, this calibration gives a frequency within ±3% of the nominal
#4421779: >> Die Fuse-Bits sind 0xE1 und 0xD9 > Es ist übrigens auch keine allzu gute Idee, den /internen/ RC-Oszillator > mit seinen +-3% Fehler für die serielle Schnitte zu verwenden: Na da kann man dann selbst kalibrieren, dann kommt man auf 1 %…ist dann zwar immer noch sehr grenzwertig, kann aber
-
Thread
Verständnis Baudraten berechnung
meinem code oder am Aufbau liegt! Wenn dann alles klappt wird selber programmiert :) wenn ich den UART im griff hab kommt ein UART bootloader, dann ein can bootloader ;) > 3. Im vorliegenden Fall, mit 8% Fehler, wird der Code wohl i.A. > funktionieren, es ist bloss nicht so gut wie er sein könnte
Marc S. schrieb im Beitrag #4419234: > Im Moment läuft er noch mit dem internen 8MHz > Also baud=8000000/... W.A. schrieb im Beitrag #4419321: > Bei der Angabe 8000000 für die Taktfrequenz entspringen fünf Nullen der > reinen Phantasie. Beim /internen/ Oszillator darf
-
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
Atmega168 Power_down
ebendieser ab- und USART eingeschaltet, und Letzterer liefe bei einem beliebigen Muster auf einen Fehler.
Matthias Sch. Vielleicht mache ich ja etwas falsch, aber ich schaffe es nicht, auch nicht mit internem RC-Oszillator und UBRR=4095.
-
Thread
PIC32MZ Ports mit Pull up spinnt
anzeigen. Du magst ja vielleicht durchsehen, ein anderer aber kaum. Warum nimmst Du nicht die UART bzw. SW-UART oder den Debugger zur Ausgabe? Teile das Problem doch erstmal auf, d.h, setze nur die Pullups mit nachfolgender Endlosschleife. Und dann miß, ob an jedem Pin ~VCC anliegt. Wenn nicht
gemäß dem Datenblatt auf +3.3V. Das ist einer der Momente, wo man enttäuscht ist, keinen eigenen Fehler gefunden zu haben.
-
Thread
Arduino M0 (Pro) Takterzeugung
hin, den CPU-Clock auf 48 MHz zu bringen. Verstanden habe ich es so, dass die DFLL die 8 MHz vom internen Oszillator bekommt und mit dem externen 32,768 MHz Oszillator getriggert wird, im Closed Loop Mode. Ich kann in der Konfiguration aber nur einen Takt anlegen. Soviel also zur nicht sooo schweren
Nochmal, das ist quasi ein Atmel ICE. Das ist KEIN UART<->USB Wandler Chip wie auf dem Arduino Uno.
-
Thread
ATmega / Mosfet PWM Beschaltung
haben, um direkt auf der Schaltung > programmieren zu können. Pfosten-/Wannen-Stecker Da fehlen aber noch die Masseverbindung am Stecker. Oder?
https://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Kommt hier regelmässig immer wieder ein Schlauer vorbei und sagt: bei mir funktioniert das aber einwandfrei mit dem internen Oszillator. Und ja, es geht - mit OSCAL-Abgleich, nachgeführt mit ankommenden
-
Thread
XMEGA programmieren
Beitrag #4358338: > Ich kenne mich selber gut genug um zu wissen (und zugeben zu können), > dass ich Fehler mache. Ich mache auch Fehler. Dann sucht man halt den Fehler und gut ist.
natürlich auch mehrere parallel) und dann einfach HidUart_Open(...), und dann mit HidUart_Write und HidUart_Read lesen und schreiben.
-
Thread
ATmega328P UART in Assembler
es im RX Fenster. Also der Adapter geht und richtig verkabelt ist auch alles korrekt. Wo mag der Fehler liegen? Holger [code] ; ; ATmega328_Hardware_UART.asm ; ; Created: 07.11.2015 16:23:15 ; Author : Holger ; .include "m328Pdef.inc" .DEF temp = r16 .equ F_CPU = 10000000
Hi >Wo mag der Fehler liegen? Bei 1MHz Takt hast du bei 9600Bd schon 7% Fehler. Mit internem RC-Oszillator kann es noch mehr werden. Gehe mal auf 4800Bd runter. MfG Spess
-
Thread
PDP11 KL11 SLU in altem CPLD?
gibt es hier schon. Ich will wirklich was zusammen löten. Es wäre recht einfach eine beliebige UART an den Prozessor zu hängen, die Sache hat allerdings den Haken das üblicherweise PDP11 CPUs direkt Mikrocode enthalten um über eine Terminalschnittstelle Debugging zu ermöglichen (ODT). Das ist zwar
ATF1504AS und CDP6402 macht Fortschritte. Man könnte sicher auch ein grösseres CPLD nehmen und den UART gleich integrieren, aber zum Testen ist ein funktionierender UART weniger fehleranfällig. Folgendes Progrämmchen produziert für 030 (dezimal 24) Zeichen ein Echo auf der Console und dann ist wie vorgesehen
-
Thread
Layout für MCS51 Experimentierboard
In der Fehlerbeschreibung habe ich den RAM-Fehler durch einen Fehler ersetzt. OE des RAM gehört auch nicht auf WR, sondern auf RD (IC1-17) des 51er. :( Ich muß mich mal mit etwas Anderem beschäftigen, um den Kopf wieder frei zu bekommen. :P
sind durch das Layout hinreichend gegeben. Bleiben die größeren Kondensatoren am Quarz, hat der interne Oszillator Probleme beim anschwingen (schwingt nicht oder falsche Frequenz). Gruß. Tom
-
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
Basic für 80C31
der ist im 8031 nicht vorhanden. Auch die Autobaud-Funktion arbeitet mit dem Timer2. Weiterhin fehlen Dir 128 Bytes interner RAM, der 8031 hat nur 128, Basic braucht aber 256!
Sockel und den Molex, damit man den MC stromlos machen kann, bevor man > ihn rausnimmt. Der Oszillator ist für den Fall, das ich aus Versehen mal > den internen RC Oszillator verfused habe (gilt nicht für die AT89, weil > die immer externen Quarz haben) und am Molex stehen eben die bekannten
-
Thread
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
Space Age 2 der 32Bit MIPS Rechner in TTL
Emulator. Allerdings hatte sich die Karte anfänglich bei manchen Multiplikationen verrechnet. Die Fehler lagen alle im oberen Bereich (siehe muldiv_fehler_sreg). Im Endeffekt hatte sich da der Massepin beim Sockeln verbogen. (muldiv_fehler_sreg1) TTL hat eben keine Clampdioden und läuft somit nicht
Nacht lang durch. Natürlich mit angeschlossenem Debugemulator und Logic Analyzer um vllt doch den Fehler noch zu erwischen. Blöderweise lief das Ding fehlerfrei durch. Wenigstens bestätigt das, dass meine Debugzugriffe in den CPU Kern keine Fehler auslösen.
-
Thread
atmega328p mit FTDI und ArduinoIDE programmieren
Moin. Kurz zu meinem Vorhaben: Hab ein Board mit einem atmega328P (interner Oszillator 8Mhz) aufgebaut und möchte diesen über einen USBzuSeriell-Adapter und die ArduinoIDE flashen können. So, simple Sache eigentlich. Soweit funktioniert die Sache auch, allerdings nur ein
weiteren Flashvorgänge durchführen. Wenn ich es versuche, blinkt mein Adapter (da mein Scatch daten via UART raussendet). Der Port wird also schon geöffnet, allerdings schlägt das Flashen fehl. Ich muss jedes mal den Bootloarder über das AtmelStudio neuflashen..... Das ist ja nicht der Sinn eines bootloaders
-
Thread
zwei Attiny's über UART verbinden
must mehr als 4 Pins kurz gleichzeitig kurzschließen, um den Chip zu zerstören. Bedenke dass die UART Schnittstellen mit der gleichen Bitrate betrieben werden müssen, weswegen die Nutzung der internen R/C Oszillatoren ungeeinget ist. Die sind dafür zu ungenau - vor allem in der doppel-Kombination.
> als 4 Pins kurz gleichzeitig kurzschließen, um den Chip zu zerstören. > > Bedenke dass die UART Schnittstellen mit der gleichen Bitrate betrieben > werden müssen, weswegen die Nutzung der internen R/C Oszillatoren > ungeeinget ist. Die sind dafür zu ungenau - vor allem in der > doppel-Kombination
-
Thread
Entwicklung HV-Netzteil, Strom-Messung High-Side?
entsprechend ausgelegt und damit kann man prima nen MC versorgen, der die Ströme am heißen Ende mißt und per UART und Optokoppler nach unten sendet. So ein ADUM mit interner Versorgung ist ja abartig teuer. Allerdings sinnvoll ist eine solche Strommessung nicht, wird wohl nur als Gimmick sein. Überwachung
ausgelegt und damit kann man prima nen > MC versorgen, der die Ströme am heißen Ende mißt und per UART und > Optokoppler nach unten sendet. Laut Opener ist das ein eigens für diesen Zweck gewickelter Trafo, da wird keine Heizwicklung für eine Gleichrichterröhre sein. > So ein ADUM mit interner
-
Thread
Phasenerkennung 50kHz Sinus Signal
Phasenwinkels. Folgendes habe ich bereits konzipiert, simuliert und aufgebaut: „Wien-Robinson Oszillator“ zur Erzeugung einer 50kHz Sinusschwingung Das Ausgangssignal wird über ein Potentiometer an eine spannungsgesteuert Stromquelle gegeben, in diesem Fall eine „Howland current pump“. Somit kann
kann durch das Array durchschalten per Tastendruck. Demnächst setze ich mich noch an die Ausgabe per UART. Nur leider ergeben die Werte wenn ich diese Plotte keinen Sinn. Im Anhang ein Auszug von den Werten in dem Array. Vielen Dank für die bestimmt kommende Hilfe :-) So und nun gute Nacht.
-
Thread
AVR Libc & GCC: utoa() liefert Ziffern falsch rum?!
Taktquelle interner Oszillator. Versteh mich nicht falsch, ich kann hunderte Zeichen problemlos senden, ohne dass die RS232-Kommunikation Probleme bekommt. An der Kommunikation kann es nicht liegen. Stop-Bit sollte
Paul H. schrieb im Beitrag #4228220: > Taktquelle interner Oszillator. Versteh mich nicht falsch, ich kann > hunderte Zeichen problemlos senden, ohne dass die RS232-Kommunikation > Probleme bekommt. An der Kommunikation kann es nicht liegen. > > Stop-Bit
-
Thread
PIC10Fxxx oder PIC18Fxxxx für den Einstieg?
gehackt haben ... sind sie hoffentlich in der Lage den Debugger/Simulator soweit zu benutzen um den Fehler sehr schnell zu finden. Das muss man meiner Meinung nach am Anfang lernen. Yp, ich weiss: "echte Programmierer schreiben den Scheiss einfach hin und das läuft" ;-)
PIC16F84. Also, der ist ja nun wirklich schon arg veraltet! Er hat ja noch nicht einmal einen internen Oszillator, d.h. da muss man immer einen Quarz oder andere externe Taktquelle anschließen! Ich weiss wirklich nicht, warum der immer noch so beliebt zu sein scheint! Für's Bastlersortiment würde
-
Thread
Datenerfassung, Analog -> USB / RS232
(Discovery) bestellt, wie > empfohlen. Gut, damit hast Du erst einmal genug zu tun. Wenn der interne Speicher doch reichen sollte (ca. 180 kB wären nutzbar), hättest Du damit fast eine fertige Lösung.
konfigurieren. Capture Interrupt programmieren. Signal an den IO-Pin anlegen. Wert des Timer-Captures über UART an den PC schicken. Freuen wenns geht.
-
Thread
RC5 Modulation
Jan H. schrieb im Beitrag #4182739: > Benutze einen MEGA2560. Nö, damit hast du die internen 8MHz des RC Oszillators. Lies mal bitte 10.7 im Datenblatt. Es gibt 2 interne Oszillatoren, den 8MHz RC Oszillator und den 128kHz Watchdog. Das dein UART mit '16Mhz' Einstellung funktioniert
im Beitrag #4182743: > Jan H. schrieb: >> Benutze einen MEGA2560. > > Nö, damit hast du die internen 8MHz des RC Oszillators. Lies mal bitte > 10.7 im Datenblatt. > Es gibt 2 interne Oszillatoren, den 8MHz RC Oszillator und den 128kHz > Watchdog. > > Das dein UART mit '16Mhz' Einstellung funktioniert
-
Thread
Atmega8 empfängt bestimmte Bytes falsch über UART
Wenn kleine Werte nocht korrekt übertragen werden, und Fehler erst auftreten, wenn die oberen Bits 1 sind, dann liegt es mit sehr hoher warscheinlichkeit an einem ungenauen Takt. Falls du den internen R/C Oszillator verwendest, kann es daran liegen. Der R/C Oszillator aller ATmegas eigent sich nicht für zuverlässige UART Kommunikation. Laut Datenblatt des ATmega 8 Seite 159 hast du bei der Kombination 1Mhz 9600Baud schon 7% Abweichung vom Soll - unter der Annahne
-
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
STM32F7 Discovery Board
Warum so grossen interner Flash? Was spricht gegen QSPI?
\Projects\STM32746G-Discovery\Examples\FMC\FMC_SDRAM_DataMemory Soweit sogut, habe jetzt im internen SRAM nurnoch den SP und der rest ist alles auf dem externen (vorerst). Nun habe ich aber das Problem, dass meine Peripherien nichtmehr so richtig wollen. Ich kann über UART bsp. nichts mehr senden
-
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
AVR-ASM M8 USART-Funk problem
rjmp uart3 in usart3, udr uart4: sbis UCSRA, RXC rjmp uart4 in usart4, udr uart5: sbis UCSRA, RXC rjmp uart5 in usart5, udr ; ; uart6
Ich glaube weniger, dass es am internen RC-Oszillator liegt, aber die Quarzfrage lässt sich leicht entscheiden, indem man um +- 2 % verstellt, also UBRRL auf 203 bzw. 211 setzt und schaut, ob es funktioniert.
-
Thread
Erster Schaltungsentwurf - ATtiny Programming Board
im Beitrag #4139816: >> Nachdem du keinen Quarz angeschlossen hast denke ich du willst den >> internen Oszillator benutzen. > > Ja, ist das ein Problem? Im allgemeinen nicht außer du willst die UART oder andere Timing kritische Sachen benutzen. Siehe: https://www.mikrocontroller.net/articles/
Geister. Es ist ein typischer Anfängerfehler die Fuse falsch zu wählen. Wenn du aber eh nur den internen Oszillator benutzt musst du hier erst mal nichts ändern. Wenn du doch einen Fehler machst kannst den externen Oszillator immernoch vorübergehend an deine Stiftleiste hängen.
-
Thread
Uart empfängt immer das selbe
Framework mache, funktioniert es wunderbar und ich kann auf unterschiedliche Buchstaben reagieren. Mein Fehler wird also vermutlich in der Initialisierung des UART oder der Verarbeitung liegen. Meinen Fehler finde ich jedoch nicht. Ich habe ihn mit vielen Beispielcodes, unter anderem aus diesem Forum, verglichen
zu informieren, dass der µC mit 16Mhz rennt. Das ändert aber am Grundproblem nichts. Mit dem internen Generator (der kein Resonator ist), ist die Genauigkeit der Taktfrequenz schlechter als mit dem externen Generator. Wenn du mit dem Resonator keine saubere UART hinkriegst, dann kriegst du es mit
-
Thread
Mikrocontroller kompatibel mit USB bzw. programmierbar?
es die gibt bzw. eben woher ich weiß, ob die zu dem uC > passen. Ein CP2102/FT232 ist ein USB->UART Wandler. Der passt zu jedem µC mit UART, der µC muss kein USB können. UART hat fast jeder Controller, unter anderem alle STM8, soweit ich das sehe. Einzig aufpassen musst du wegen der Taktgenauigkeit für eine UART. Nimm einen Quarz / Keramikresonator (besser 1%), dann hast du kein Problem. Die internen Taktquellen der µC sind oft zu ungenau. Wie du einen STM8 über die UART programmieren kannst, steht hier:
-
Thread
32-Bit μC für zwei Layer PCB
Was soll der Furz, sich moeglichst Probleme einzuhandeln ? Man kann den Controller ja ab internem Oszillator auf 5MHz laufen lassen, dann ist das EMV Problem auch etwas entspannt.
erfolgt, daß man die entsprechenden Peripherie-Einheiten aktiviert oder eben nicht. Also wenn CAN > UART, dann ist Pin eben CAN und wenn man UART auch haben will (an anderem Pin), dann erhebt sich die Frage "Wie denn?", weil ja CAN aktiviert ist und deshalb den Vorrang hat. BÄH kann ich dazu nur sagen
-
Thread
uart interface pic18
NOCLKDIV // 1:1 mode (for 48MHz CPU) ... // -> 48 MHZ interne Oszillator Clock void InitializeUSART_115200(void) { unsigned char c; UART_TRISRx=1; // RX -> Eingang -> geht an BT_UART_RX UART_TRISTx=0; // TX -> Ausgang ->
Yo, sehe ich auch so. Interner Oszillator läuft auf 1MHz per default ... Kein Problem mit 115200 bei mir wenn man den Oszillator über das OSCCON vernünftig einstellt. Vergiss den externen vorerst mal ! #include <p18cxxx.h
-
Thread
Atmega644 Frequenz auf PORT PINS mit gelöschtem Flash Startfehler
also das normale verhalten eines gelöschten Atmega. Das Jtag fuse ist aus und es ist egal ob ich internen oder externen Oszillator verwende. Jedoch ändert sich mit dem Oscillator auch die Frequenz an PortD. Das verhalten kann unterdrückt werden wenn ich am reset einen 25uF Kondensator nach Masse hänge
!! Es ist Port A. Beim Atmega1280 steht der selbe text und der hat Port F also nen Copy Paste Fehler Vlt hilft es jemanden ?! Vielen Dank an alle. Mfg Simon
-
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
-
Artikel
Schwingquarz
= 500Hz. Bzw. eine Frequenz zwischen 9.9995MHz und 10.0005MHz. Verwendung. Quarzstabilisierte Oszillatoren werden immer dann eingesetzt, wenn die Anforderungen an die Grundgenauigkeit und/oder die Stabilität der Frequenz zu hoch sind, als daß sie durch RC- oder LC-Oszillatoren eingehalten werden könnten
Baudraten erreichen, siehe dazu Baudratenquarz. Mit "runden" Frequenzen entstehen u.U. einige Prozent Fehler. Quarze in Eagle. In Eagle findet man Quarze in der Bibliothek "Crystal" in der Untergruppe "Crystal". Im Forum wurde eine Bibliothek mit mehreren SMD-Quarzen und Oszillatoren hochgeladen: Siehe Eagle-Bibliotheken
-
Thread
µC nicht mehr ansprechbar
kann den µC immer noch nicht ansprechen. Warscheinlich weil der immer noch auf ein Signal vom internen Oszillator wartet? Wie schon geschrieben habe ich nur "SUT_CKSEL" auf "EXTCLK_6CK_64MS" gestellt. Wie kann ich den Atmega noch retten um ihn wieder ansprechen zu können?
>Wenn der Controller mit internem Oszillator läuft hat der >externe Quarz keinen Einfluss auf die Takterzeugung. Ja richtig! Darum >habe ich bei SUT_CKSEL die Option >EXTHIFXTALRES_16KCK_64MS ausgewählt Dies Option stellt den