-
Thread
RTC an XMEGA Hilfe!!
ohne BL (2MHz), aber mit dem BL zählt der counter (RTC.CNTL) nicht mehr hoch. Hab auch mal den internen 32KHz RC Oszillator versucht, keine Änderung. Es scheint ein Register im BL gesetzt zu werden, das den RTC verriegelt, leider finde ich nichts im Internet oder Dokument, was denn noch gesetzt sein
Hallo Timmo, ich verwende diese Version: chip45boot2_atxmega64a3_uartF0_v2.9N.hex Es passiert beides: Kein RTC Interrupt und genau deshalb hab ich mal zum Debuggen den CNT ausgelesen. Wenn ich ohne BL brenne bekomme ich immer verschiedene Werte, mit BL immer den selben
-
Thread
ATMEGA168 vs ATMEGA328 RC Oscillator
auch, inkl. Migration Note: Hier gibt es Unterschiede in den Quartzpin - Kapazitäten; sollte beim internen RC - Osci nicht relevant sein.
sind die Ergebnisse der Frequenzmessung stark fehlerbehaftet. Als Gegenbeweis, dass der RC-Oszillator es besser kann, verstellt man dessen Kalibrierung manuell. Damit kann man ihn auf <1% Fehler abgleichen und der UART läuft stabil und fehlerfrei. Ich hatte mal ein Projekt, wo nur ein 32k Uhrenquarz
-
Thread
Hackbarer(?) 21 EUR Quadcopter
wieder drauf zu bekommen)? Eventuell kommt ja mit der original-Firmware auch schon was aus dem UART...
> 28,83€ wären mir auch zu teuer. Oder habe ich mich verrechnet? Ja. Die Versandkosten fehlen.
-
Thread
Faktensammlung Buderus EMS
mal zum spielen einen PIC mit zwei Seriellen Ports im DIP-Gehäuse mit 14 Beinchen bestellt. Wegen internen Oszillator würden keine externen Bauteile benötigt (Außer EMS-Teil natürlich) Meine Idee wäre dass er einfach eine Umsetzung vom EMS-Bus auf die serielle Schnittstelle macht. Also ein kleiner ems-Gateway
00 95 00 89 - CRC-Fehler UBASollwerte ( 10 08 1a 00) 01 02 03 04 05 06 07 08 09 Daten: 10 08 1a 00 00 00 00 00 91 - CRC-Fehler RCTimeMessage ( 10 00 06 00) 01 02 03 04 05 06 07 08 09 10 11 12 13
-
Thread
(UART) AVR sendet wirre Zeichen zurück an BTM222
F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" .endif
Gaaaaaaanz komisch... liegt irgendwie am quartz Oszillator. Hab aus spaß mal den internen RC benutzt und dann ging es. Auf dem Oscillator steht 3.6864 MHz. Hab ich in dem Programm irgendetwas falsch gemacht ? oben bei F-CPU ? Ich hab die fuses beim ATMEGA
-
Thread
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
Board oder Steckbrett für den Einsteiger?
Habe mir jetzt gerade einen Warenkorb zusammengestellt. Widerstände fehlen, da wollte ich mir ein günstiges Sortiment bei eBay holen. Habe jetzt einfach mal die Bauteile von den ersten beiden Schritten im Tutorial zusammengeklickt, wollte am Anfang damit arbeiten. Ihr
> Quarzoszillator brauchste eigentlich nicht, ein Quarz tut es auch. Einspruch. Mit einem Oszillator kommst du auch bei versehentlich falsch gesetzten Fuses noch an den µC ran, mit Quarz meist nicht. Da hier weder Preis noch Platzbedarf von Bedeutung sind, geht die Empfehlung ganz klar an den Oszillator
-
Thread
EMV ATmega Board (Abstrahlungsproblem)
veröffentlichen, da es ein kommerzielles Produkt ist. > Du könntest mal von dem Quarz auf den internen Oszillator gehen (falls > Deine Schaltung das zulässt). Das kann ich über die Fuses mal so einstellen. > Evtl. 10 Ohm in die XTAL2 Leitung Reicht hier ein einziger Widerstand in Serie
nicht wirklich know-how. >> Du könntest mal von dem Quarz auf den internen Oszillator gehen (falls >> Deine Schaltung das zulässt). > Das kann ich über die Fuses mal so einstellen. Ich hatte ehr bedenken, da ja der Resonator um einiges ungenauer ist als der Quarz und
-
Thread
UV-Laserdrucker
Hinterkopf gehabt. ATTINY2313 geht aber - und den habe ich jetzt genommen. Mal im Trockenlauf mit dem internen Oszillator probiert und funktioniert prima (wobei der interne Oszillator entweder heftig vom Soll abweicht oder mein Oszi es mit der Genauigkeit der Messung nicht so hat. Egal wie, CPU-Taktausgang
Problem aus der Welt zu schaffen, habe ich aber temporär alles, was irgendwie mit dem UART zu tun hat aus dem Code geschmissen, keine uart.h wird mehr included und sogar die uart.c ist aus dem Makefile raus. Erst danach habe ich den Fehler überhaupt genauer lokasisieren können, siehe meinen
-
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
Wieso externe Komponenten nutzen?
z.B. einen eigenen Quarz für die Takterzeugung eingebaut, nein hat er nicht. Er hat einen RC-Oszillator der z.b für UART schon zu ungenau ist. (bzw erst Kalibriert werden muss)
oder ähnliches. Für den externen Widerstand kann es schon den einfachen Grund geben, dass der interne zu groß ist und damit leichter Störungen einfängt. Es kommt aber auch vor das kommerzielle Entwickler Fehler machen - sonst würden die Produkte ja noch seltener kaputt gehen.
-
Thread
Atmega8/88 mit 8Mhz betreiben.Kondensator`?
marixstorm schrieb: > Die 19K2 macht der 88er bei Zimmertemperatur auch problemlos mit dem > internen Oszillator. > > Den Atmega8 würde ich ohnehin da liegen lassen, wo er ist. > > mfg. ich bin hier in der Luft zerrissen worden als ich den internen Oszillator zusammen mit der UART nutzen
Tobi88 schrieb im Beitrag #3277141: > ich bin hier in der Luft zerrissen worden als ich den internen > Oszillator zusammen mit der UART nutzen wollte Von irgendwelchen Knalltüten, die noch nicht gemerkt haben, daß die Atmega8/16/32... nicht mehr State-of-the-Art sind. Bei denen soll der interne
-
Thread
Mega328p UART Problem
MKII zugelegt. Flux aufgebaut und los gings mit dem Assembler Tutorial. nun bin ich beim Kapitel UART und konnte den Mega nicht mehr mit dem internen Oszillator betreiben. Daher habe ich einen 8Mhz Quarzoszillator mit angeschlossen und wollte die Fuses setzen, leider hab ich das wohl falsch gemacht,
F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" .endif ; hier geht
-
Thread
µC mit Uhrenquarz betreiben
Lastkapazität der Quarze ist zwar unterschiedlich braucht aber nur bei Uhren genau zu sein. Ob der Oszillator des betreffenden Kontroller Uhrenquarze "kann",siehe Datenblatt. Mit den 32 kHz als Takt ergäbe das beim Stromverbrauch gegenüber dem internen Takt eine deutliche Stromersparnis (ohne sleep-mode
Lastkapazität der Quarze ist zwar unterschiedlich braucht aber nur bei Uhren genau zu sein. Ob der Oszillator des betreffenden Kontroller Uhrenquarze "kann",siehe Datenblatt. Mit den 32 kHz als Takt ergäbe das beim Stromverbrauch gegenüber dem internen Takt eine deutliche Stromersparnis (ohne sleep-mode
-
Thread
USART sendet nur kryptische Zeichen zurück
BAUD_ERROR ((BAUD_REAL*1000)/BAUD) #if ((BAUD_ERROR<990) || (BAUD_ERROR>1010)) #error Systematischer Fehler der Baudrate gršsser 1% und damit zu hoch! #endif void uartInit(void); int main(void) { //PORTB als Eingänge mit internen Pull-Ups ausser PB0 & PB1 setzen DDRB = 0x00; PORTB = 0xFC
Also ich habe jetzt das ganze nochmal mit einem 4MHz Quarz Oszillator aufgebaut. Offenbar hat mir die Ungenauigkeit der Internen Frequenz einen Streich gespielt. Allerdingss würde mich interessieren wieso es im Interruptbetrieb nicht funktioniert wo es doch ohne wunderbar
-
Thread
UART Tutorialbeispiel auf Atmega 8 klappt nicht
Hallo Experten, ich möchte nun schon seit zwei Tagen das UART Beispiel aus dem Tutorial (http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART) zum Laufen bringen und schaffs einfach nicht. Ich hab das zweite Programm zum Senden ("Senden von Zeichenketten
entweder ein Quarz (der ist nämlich in diesem Schaltplan nicht vorhanden) oder Du verwendest den internen RC-Oszillator (der zu ungenau ist, um damit serielle Schnittstellen zu betreiben). Da Du aber einen statischen Pegel feststellst ist höchstwahrscheinlich ersteres der Fall. >Es blinken keine LEDs
-
Artikel
Der Multiplex Sensor Bus (MSB)
weiteres define übernimmt das Abfragen des Pegels. MB_Bitlen enthält die Zeitdauer für ein Bit in µS. UART. Da der Tiny85 keinen HW-UART besitzt muss er in Software nachgebildet werden. Das Senden eines oder mehrerer Bytes auf den Bus gestaltet sich einfach. Es müssen nur alle 8 Bit im korrekten zeitlichen
der Drucksensor wird per I2C direkt an den Controller angeschlossen. Externe PullUp Widerstände fehlen. Aus Platzgründen werden die internen des Controllers verwendet. Zur Spannungsmessung kommt ein Spannungsteiler 10k/1k3 zum Einsatz. So können Spannungen bis 26 Volt (6 Lipozellen) gemessen werden.
-
Thread
AVR-Tutorial: USBasb, Fuses, Anfängerprobleme
Welchen Clock hast Du gewählt und ist er bei Deiner HW auch vorhanden? Der Klassiker ist, den internen Clock abzuschalten ohne dass ein Quarz oder externer Clockgenerator vorhanden ist. Gruß Dietrich
ganz grob abschätzen. Mit dem Multimeter sollte an den XTAL-Pins ca. Vcc/2 messbar sein, wenn der Oszillator schwingt.
-
Thread
Bewertung des Zufallsgenerators für einen Spielwürfel
Yalu X. schrieb im Beitrag #3224301: > So rund wie der zugrundeliegende Quarz- oder RC-Oszillator (der > Zählerüberlauf kostet keine zusätzliche Zeit). Da der Jitter des > Oszillator nicht mit der Periode des Zählers korreliert, hängt die > Qualität des damit realisierten elektronischen
Es ist nicht mein Fehler wenn Ihr nicht in der Lage seit meine Antwort zu verstehen oder zu akzeptieren... . Over and End Löti
-
Artikel
USB IO Expander
eingebauten Halbleiterrelais können Ströme bis zu einem Ampere schalten. Sie sind durch optionale interne 5x20mm Sicherungen abgesichert, so dass auch hier eine Beschädigung der Hardware fast ausgeschlossen ist. SPI. Weiterhin befindet sich eine SPI Schnittstelle im Gerät. Diese kann frei konfiguriert
PC Software: Überarbeitete interne Struktur + übersichtlicherer Code USB Kommunikation überarbeitet: erhöhte Stabilität Ergänzung von neuen Modulen wesentlich vereinfacht Paneel auf der linken Seite ausblendbar (für kleinere Monitore
-
Thread
UART @ 1MBit -> over-/undershoots beseitigen
Ralf schrieb im Beitrag #3212647: >>>SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz Hast du auch überprüft mit welchen Fehler der UART-Baudrategenerator die 921k6-Baud generieren kann? Bei höheren Baudraten hat man da normalerweise einen größeren Fehler und
@Holger: > Das heisst du hast versucht einen internen RC Oscillator > für eine UART Verbindung zu benutzen? Kein Wunder das das > nicht funktioniert. Da muss kein Datenblatt neu geschrieben werden. Richtig lesen bitte: für 115k2 -> ja, interner Oszillator
-
Thread
Neue Cortex-M0+-Familie von Atmel
datenblatts: -) neues kapitel SAM D20 Schematic Checklist (beinhaltet auch die anschaltung der oszillatoren -) div fehlerbehebungen/ergänzungen allerdings fehlen immer noch die ac/dc characteristics. gruss gerhard
Interruptprioritäten der Cortex-Mx verweisen. Hier ist ein 8-Bit AVR klar unterlegen, was aber nicht an seiner internen Busbreite liegt.
-
Thread
Projektidee.Oszilloskop die 12334543te
den DMA gemütlich von lesen. Etwas übertakten (210Mhz war bei mir am Tisch drinnen beim einem Oszillator-abnormal-test) kommt man also mit einem F417er auf die samplingrate des DSO Quad. die 4k Samplingbuffer ließen sich auch problemlos realisieren... Die Projektidee wäre nun so etws ähnliches
mit den einschrängungen des jeweiligen derivats natürlich... zusätzlich werde ich versuchen die internen ADCs auch dranzuhängen.. damit ist dann auch 12bit high-res möglich :) 73
-
Thread
ATtiny: Hinzufügen von Fuses durch anpassen der boards.txt??
nur mit dem 16 MHz Quarz. Muss ich die Hexfile noch editieren? Die wird ja soweit immer für den internen Oszillator verwendet. Viele Grüße Dennis
ich habe mal folgendes Programm getestet: [c] #include <SoftwareSerial.h> SoftwareSerial uart=SoftwareSerial(0,1); void setup(){ uart.begin(9600); } void loop(){ uart.print("Hallo Bernd"); uart.println(); delay(1000); } [/c] Das läuft bei mir richtig. Ich habe allerdings
-
Thread
DMX Board geht nicht :/
Quarz(inklusive passenden Kondensatoren) bekommst Du keine Übertragungsrate von 250kB/s hin. Der interne Oszillator ist dafür viiiiel zu ungenau. Womit wird die Schaltung eigentlich angesteuert?
genauer. Entweder sind deine Fuses falsch eingestellt und dein AVR läuft in Wirklichkeit mit dem internen RC-Oszillator, der hat auch 8 MHz, aber UNGENAU! Oder du hast die Optimierung im Compiler nicht aktiviert, dann funktionieren die _delay_ms() auch nicht genau.
-
Thread
UART-Verbindung zwischen 2 µC
geht jetzt in beiden Richtungen, genau wie es soll. D.h. Du hast einen schweren konzeptionellen Fehler. Vermutlich arbeiten die UARTs blockierend und nicht als Interrupt mit FIFO.
@ Tilmann (Gast) >> Hört sich nach internen RC-Oszilletor an. >Stimmt, aber 4800 Baud müßte das noch schaffen, oder ? Oder. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
-
Thread
8bit-Computing mit FPGA
in grauer Vorzeit begangenen Entwurfsfehlern. Natürlich kennt nicht jeder jeden jemals begangenen Fehler, so dass bestimmte Fehler auch wiederholt werden. Das Neue an Deiner Vorgehensweise ist dabei, dass Du ignorierst, dass es sich dabei um Fehler handelt. Wenn man eine "neue" Idee hat, gibt es üblicherweise
Zum internen Aufbau der CPU: https://www.mikrocontroller.net/topic/407050?goto=5178924#5178924
-
Thread
ATtiny13: UART Problem mit External-Interrupt
Bisschen mit einem ATtiny13 zu beschäftigen und diesem die grundlegendsten Funktionen einer Software-UART zu programmieren, damit ich diesem zukünftig Befehle senden kann, um z.B. eine AD-Wandlung zu starten. Das Ergebnis kann dann am Rechner weiterverarbeitet werden. Der u-Controller ist über den internen Oszillator auf 9,6 MHz, ohne Vorverteiler, getaktet. Das Programm ist aktuell noch sehr simpel und soll auf PORTB-Pin 2 ein Byte empfangen und dieses auf PORTB-Pin 1 wieder ausgeben. Einfach, um UART, den
-
Thread
[AVR] UART geschossen?
Mit internem Oszillator kann die UART-Verbindung schon mal in die Hose gehen ... nimm einen Quarz! Gruß Jobst
genau diese Baudrate brauchst. Die Seite dürfte dir dabei helfen: http://www.gjlay.de/helferlein/avr-uart-rechner.html . Die 115.200 Baud lassen sich z.b. mit einem 9,216 MHz Baudquarz ohne Fehler erreichen ^^
-
Thread
Assembler lernen für Mikrocontroller-Programmierung
anderen Threads gewundert warum diese öfter dort erwähnten +/- 10% Toleranz für den kalibrierten internen RC-Oszillator genannt wurden. Endlich habe ich es auch gefunden ( Calibrated Internal RC Oscillator Accuracy -> siehe Screenshot ). Bernd_Stein
Beitrag #6123277: > was auf 128kHz bezogen Jetzt fällt es mir erst auf, Du nimmst ja den WD-Oszillator. Der läßt sich nicht kalibrieren und ist super ungenau. Kalibriert ist nur der RC-Oszillator 9,6MHz. Bei meinen Tests war er in der Regel so genau, daß es für eine UART taugte.
-
Thread
Einstieg ARM
Clock ist tatsächlich ein Kapitel für sich, aber üblicherweise macht man es so: entweder reicht der interne RC-Oszillator (meist 12 MHz), dann macht man gar nichts. Oder man ruft das CMSIS System_Init() auf, dann bekommt man einen für den Chip üblichen Takt (z.B. 96 MHz) und noch den USB Takt (48 MHz). Wenn man jetzt eine UART Baudrate braucht, die genau damit nicht erreichbar ist, gibt es für jeden Chip ein Excel-Sheet zum Download, wo man die Baudrate einträgt, und dann wirft es die ganzen PLL Register raus. Die meisten
-
Thread
Atmel oder PIC Gesperrt
gleicher Eignung würde ich immer einen AVR nehmen. Einmal hat sich der PIC zB nur wegen genauerem internen Oszillator durchgesetzt, da so eine externe genauere Taktquelle eingespart werden konnte. Privat bin auf AVR 8-Bit, Cortex M-3 von ST und Renesas RX unterwegs. Letzterer übrigens mein Liebling,
RAM für Register, Stack und Daten. Ich entwickelte auch Anwendungen, die nur mit den 128 Byte internes RAM des 8051 klar kamen. Indirekt adressiertes RAM hatten diese gar nicht. Der Stack bewegt sich ja darinnen auch noch. Deswegen wählte ich gerne auch den 8052 und Derivate, die das doppelte interne
-
Thread
AVR UART externe Quarze - Taktfrequenz - Pollin Board
Fehler vom Ozillator fehlt. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
schneller ;-) Edit End ich konnte bisher nicht feststellen, das externe Taktquellen stören wenn interner Takt genutzt wird. Allerdings habe ich im Kopf, das Atmel davor warnt die interne Taktquelle im Zusammenhang mit UART zu verwenden weil diese dafür nicht genau genug sind. Ich müsste mein Pollin
-
Thread
AVR UART Interner Externer Timer
mit Atmegas und Attinys meistens mit dem internen Oszillator und habe bei seriellem Interface zum PC als Feedbackkanal eigentlich keine großen Probleme - funktioniert bei z.B. 38.400 Baud sehr gut. Aber in einer Produktivschaltung die so etwas tut
OSCCAL-Register lädst. Außerdem ergeben selbst genaue 1/2/4/8MHz bei den meisten Baudraten schon einen Fehler. Externe Quarze sind um Größenordnungen genauer und stabiler als der interne RC-Oszillator. MfG Spess
-
Thread
MSP430 im 40poligen DIP-Gehäuse
Fusekram bietet die Möglichkeit, /zur Laufzeit/ die Taktquelle umzustellen, d.h. stromsparend mit internem RC-Oszillator und niedriger Taktfrequenz zu arbeiten und nur, wenn es darauf ankommt, einen externen Quarzoszillator anzuwerfen. MSP430 verwenden die von-Neumann-Architektur und benötigten keine
wohl ein klassischer Knieschuß beim Argumentieren. Die AVRs schaffen bei 4MHz und 38.4kBaud einen Fehler von 0,2%. > und 1 MHz Systemtakt kann > für viele Anwendungen ausreichen Bei 1MHz schaffen sie immerhin noch 9600 mit ebenfalls 0,2% Fehler. > Mit natürlich grenzwertiger Fehlerrate ist es
-
Thread
ATTIINY12 Probleme mit int. Oszillator
Karl Heinz Buchegger schrieb im Beitrag #3194531: > Hannes, weißt du wie gut der Oszillator der 12-er ist? Nicht gut, UART wüede ich damit ungern machen wollen. > Ist das noch einer von den alten oder schon ein neuerer, der weniger > Temperatur-Drift hat. Es ist der erste nach
ATtiny 12 und '15 mussten von Hand calibriert werden, ebenso ATMega8, '16, '32, ATTiny26, wenn der interner Oszillator auf 2, 4 oder 8 MHz eingestellt wurde. Die automatische Calibration beim Reset funktionierte nur für 1 MHz. Man sollte aber beachten, dass Tiny12 und Tiny15 obsolet sind. Die Nachfolger
-
Thread
Lightweight WS2811/WS2812 Library
Ja jetzt mit der F_CPU im Makefile(über die Toolchain-->Symbols) funktioniert es (Auch bei 4MHz internem AtMega32-Oszillator). Könnte mir das bitte jemand näher erklären? Da fehlt mir eindeutig noch tiefergehendes Wissen.
jetzt mit der F_CPU im Makefile(über die Toolchain-->Symbols) > funktioniert es (Auch bei 4MHz internem AtMega32-Oszillator). > > Könnte mir das bitte jemand näher erklären? Da fehlt mir eindeutig noch > tiefergehendes Wissen. Wahrscheinlich hat irgendein Teil des Code F_CPU nicht gesehen. Im
-
Thread
Digitaluhr bleibt plötzlich stehen
Für die Erzeugung des Sekundentakts nutze ich Timer1 im CTC-Modus (Takt läuft zu Testzwecken über internen RC-Oszillator, ist also nicht besonders genau) . Nach dem Drücken des Ein-Tasters kann man die Minuten und Stunden mit zwei separaten Tastern eingeben und durch erneutes Drücken des Ein-Tasters Timer1
Wenn du noch einen UART Ausgang frei hast, dann nimm den zum debuggen. Einfach Ausgaben bei ISR einstieg und raus rein und bei jedem Druchlauf in der main
-
Thread
AVR-Programmierboard
Controller reagiert nicht mehr, weil er keinen Takt mehr hat. Wenn man aber _immer_ nur mit dem internen Oszillator arbeitet, kann man den Quarz auf dem Programmierboard auch weglassen.
Datenübertragung beim Programmieren da, er betreibt _nicht_ den Prozessor. Nur, wenn man beim internen Oszillator bleibt und keine Fuses ändert, nur dann braucht man keinen Quarz. Wenn ich dich falsch verstanden habe, korrigiere mich bitte, ok? :-)
-
Thread
Exakte Zeit warten für Frequenzmessung?
Läuft der AVR überhaupt mit einem Quarz? Der interne RC-Oszillator ist bei weitem zu ungenau.
B e r n d W. schrieb im Beitrag #3094039: > Läuft der AVR überhaupt mit einem Quarz? Der interne RC-Oszillator ist > bei weitem zu ungenau. Er hat doch gar keine Angaben über die gewünschte Genauigkeit gemacht.
-
Thread
ATmega168 UART Problem
ich auf das Bit geprüft, das 9 Datenbits konfiguriert, es ist nicht gesetzt. Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU ist 8MHz. Ich benutze weiters die UART Library von Peter Fleury (http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html)
Armin B. schrieb im Beitrag #3090124: > Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU > ist 8MHz. Du weißt, dass der interne Oszillator nicht sehr genau ist? Eventuell musst Du die Baudrateneinstellung noch etwas trimmen (oder den Oszillator
-
Thread
DMX Baudrate - Einstellungen und Datenpakete "debuggen"?
folgendes initialisiert: [c] void init_Timer(void) { //OSCCON MPU Frequenz SCS1 = 1; //1x internem Oszillator OSCCONbits.IRCF = 0b1111; //Bit 3-6 16Mhz //OPTION_REG Timer 0 0b0x0x0111 OPTION_REGbits.PS = 0b000; //Prescaler = 0b000=1:2, 0b001 = 1:4, 0b010 = 1:8, 0b011 = 1:16,...,0b111
Pegelanpassung an Schnittstelle nicht vergessen (MAX2323 etc). Vielleicht!!! funkteoniert das sogar mit dem internen Oszillator. Bevor so etwas "primitives" nicht läuft, brauchst du keine DMX-Routine testen.....
-
Thread
Decompiler AVRstudio 6
HF-Modul, das dann vom Spannungsregler gestört wurde, und somit nicht sauber arbeitete. Der interne Oszillator des Atmega reicht allemal für diese Anwendung, auch wenn die Baudrate nicht ganz stimmt.
Hi >125000 Baud halte ich mit dem internen R/C für ein Gerücht. Ergibt bei genau 8 MHz einen Baudratenfehler von Null. Die 127kBd entsprechen einer Oszillatorfrequenz von ca. 8,128 MHz und einem Fehler von 1,6%. Etwes Luft ist da noch.
-
Thread
MAX3232 "sendet" endlos ein 70-100kHz Signal ohne Einkommende Daten
Das Problem habe ich am MAX3232 auch schon gehabt. Da spricht der interne Oszillator auf die Eingänge über. Begünstigt wird das durch Flussmittelreste zwischen den Pads. Mach die Platine mal mit Leiterplattenreiniger sauber (notfalls Isopropanol oder Spiritus)
Da kann es bei offenen Ein-/Ausgängen passieren, daß die entweder oszillieren oder Störungen vom internen Oszillator (Ladungspumpe) aufnehmen. Es sollte nichts offen sein. Schließ mal die Ein- und Ausgänge der beiden D's mit Widerständen ab. Im realen Betrieb ist ja auch alles angeschlossen. Vielleicht
-
Thread
UART und atmega8
auf den Quarz zu verzichten, nämlich, wenn man dessen Genauigkeit einfach nicht benötigt. Selbst UART-Nutzung ist nicht zwingend ein Hindernis. Wenn die Umweltbedingungen annähernd konstant sind (Temperatur, Spannung), reicht der interne RC-Oszillator aus. Man muß ihn aber natürlich kalibrieren. Auch sollte die UART-Bitrate so niedrig gewählt werden, daß wenigstens kein systematischer Fehler durch durch die ganzzahlige Teilung mehr da ist, denn natürlich addieren sich dieser systematische Fehler und der durch die
-
Thread
Fehlerbild im Anhang AVR Studio 4.1
befindet sich, wenn du ihn ganz neu gekauft hast, im Auslieferzustand, meistens sind sie auf den internen 8MHz Oszillator und die CLKDIV8 Fuse gesetzt. D.h. im Auslieferzustand läuft der MC mit 1 MHz effektiver Taktfrequenz. Wenn das zufällig auch die gewünschte Arbeitsfrequenz ist, bist du mit der Fuserei
sind vielleicht nervig oder lästig, aber es sind keine Fehlermeldungen, und sie sind nicht für Fehler in deinem Programm verantwortlich.
-
Thread
AVR32 AT32UC3C0512C Bootloader Frequenz
Ja laut Datenblatt macht die CPU bis zu 66 Mhz, und bis 33 Mhz ohne wait states für das interne flash. Handbuch auszug "• Up to 49 DMIPS Running at 33 MHz from Flash (0 Wait-State)" Ausserdem benutze ich 4 Usarts, wenn ich eine andere Frequenz benutze läuft der Usart ohne Fehler .
da ist noch einiges dazwischen... Hast Du wirklich Übertragungsfehler oder ist das nur der Fehler, der auf dem Papier steht. Normalerweise können UARTS mit einigen Prozent an Abweichung von der nominellen Frequenz durchaus umgehen. Da dürfte noch was anderes im Argen sein... Ich hab' bei
-
Thread
Homebrew computer
Abschnitte zum ZDI und zum internen RAM habe ich ziemlich oft durchlesen müssen, bevor ich mir sicher war, wie ich es hinbekommen würde. Wenn man einmal verstanden hat, was die von einem wollen ist es nicht schwer, aber es sind schon
ist keine Harvard mehr also nicht wie die normalen AVRs und Programme laufen Problemlos aus dem internen sowie externem RAM. Prozessor Geschwindigkeiten liegen bei 60-66 MHz. Kannst dir ja einfachmal den Text von Wikipedia ansehen.
-
Thread
Arduino - bringt's das ? Gesperrt
seit ercheinen des Arduinos nicht mehr gestellt wurden? Und die Fragen nach dem Betrieb einer UART. Mir sind noch zig Threads in Erinnerung, in denen es um Ponyprogeinstellungen, nicht schwingende Quarze und interne ungenaue RC-Oszilatoren usw. ging. Stundenlanges "Hast du das schon probiert
für andere Aufgaben - Oftmals nutze ich den Port-Pin am Reset-Beinchen - Vielfach nutze ich die internen Oszillatoren statt externer Quarze - Im Zuge der Code-Entwicklung ist für mich eine Simulation mit Betrachtung aller Flags, Register, SRAM/EEPROM-Memories unumgänglich - Sehr oft muss ich in meinen
-
Thread
AVR-Tutorial: Equipment wird nicht erkannt
einen pullup und evtl einen c. wenn der µc noch nicht geflashed wurde sollte er eigentlich den internen oszillator benutzen (datenblatt checken), ansonsten könnte es noch sein das du einen externen oszillator verwendest der einen (pullup?) am derzeit unbenutzten pin benötigt (enable). dann kann es
Der Controller ist noch "jungfräulich"? Dann dürfte da ja der interner Oszillator laufen. Schmeiss einfach mal alles ausser der ISP und der Versorgungsgeschichte runter und probier es noch mal.