-
Thread
mit CAN Bus Fensterkontakte abfragen.
scheint mir der sehr gut zu passen, weil ... - er einen CAN Tranceiver bereits eingebaut hat - der interne Oszillator bereits CAN tauglich scheint (bis 100KBit - aber das ist für den Zweck vollkommen ausreichend) einzig 'lästig' ist die Stromversorgung (3 & 5 Volt notwendig). Damit sollten sich die
der sehr gut > zu passen, weil ... > - er einen CAN Tranceiver bereits eingebaut hat > - der interne Oszillator bereits CAN tauglich scheint (bis 100KBit - > aber das ist für den Zweck vollkommen ausreichend) > einzig 'lästig' ist die Stromversorgung (3 & 5 Volt notwendig). > > Damit sollten
-
Thread
ATMega16
Hallo, ich hab einen ATMega16. Wollt nun einmal das Tutorial durcharbeiten. Bin beim UART-angelangt. Im Datenblatt zum AtMega16 steht, dass sich bei UART-Funktionen im Sinne von der Registerbelegung usw. nichts geändert hat. Defacto müsste bei folgendem Code ja auch auf einem PC über ein
Der interne Oszillator ist zu ungenau (+- 3% Abweichung), UART mag aber keine Abweichungen >1%. Nimm einen externen Quarz (evtl. sogar Baudratenquarz), damit sparst Du dir viel Ärger. Pete
-
Thread
ATmega8 -UART Problem(dringend!!!)
Die interne Oszillator wurde wahrscheinlich benutzt. :-P Die Fusse wurden nicht richtig eingestellt. Ich benutze ICCAVR als Complier und Ponyprog ueber ISP(kein JTag), um die Programm unterzuladen. Wie kann
geklappt!!!! War der Fehler mit Fuse!!! Hatte die Datenblatt nicht alle durchgelesen! selber Schuld! Aber danke Euch! Ihr hat mir sehr viel geholfen!
-
Thread
Ungültige Kombinationen bei RS232
konfigurieren > > Damit ist Euer "erwartet" sinnlos oder zumindest verwirrend. Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in einem Software-UART
Hmmm schrieb im Beitrag #6465787: > Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit > rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie > auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in > einem
-
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
Atmega88P USART Kommunikation funktioniert nicht
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<990) || (BAUD_ERROR>1010)) #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! #endif void uart_init(void) { UBRR0H
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<990) || (BAUD_ERROR>1010)) #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! #endif void uart_init(void) { UBRR0H
-
Thread
AVR Atmega32 CKOPT
mit einem Atmega rumgespielt und soweit hat das Programmieren auch ganz gut funktioniert (immer interner Oszillator). Nun wollte ich den Atmega mit einem 16 MHz Quarz takten (UART). Deshalb habe ich alle CKSEL Bits zurückgesetzt (in Ponyprog die Hacken entfernt). Danach konnte ich nicht mehr per ISP
Vermutlich hast du CKOPT nun ausgeschaltet und dadurch geht der Oszillator mit dieser Frequenz nicht mehr. Probiere mal, einen kleineren Quarz (3,686 MHz oder 7,37 MHz) zu benutzen.
-
Thread
Langzeittimer per RC-Glied?
Aufwachen zweckentfremdet. Stattdessen gibt es den dedizierten Real Time Counter (RTC), der vom internen Ultra Low Power RC‑Oszillator getaktet wird. Dabei beträgt die Stromaufnahme z.B. bei tinyAVR® 0,1,2-series ungefähr 0.7µA @ 3.0V, 25°C.
#7339545: > es kommt dabei nicht drauf an, ob die Zeit nun 3.5 > oder 5Std. beträgt, dann ist der interne (Watchdog-)Oszillator eines jeden AVR ausreichend genau und stabil genug. Der kostet gar nichts extra.
-
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
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
Probleme mit Rs232 Empfang
noch: Du bist ein ganz kleines bischen neben der eingestellten Frequenz. Das kann zb auftreten bei internem RC-Oszillator. Der schwingt normalerweise auf zb 8 Mhz, hat die aber nicht ganz genau. Ist nun die UART im PC etwas toleranter auf die Abweichung dann kann sie zwar noch empfangen, aber das was vomPC
Waitkey() 'Waitkey waits untill a char is received from the UART Print Akey Loop
-
Thread
Fragen zum PCF8583 als Event Counter
und für Evennts die Seltener vorkommen noch 2 Softwarezähler mit Interrupts realisieren, mit dem Internen LO Oszillator Laufenlassen. dann sparst du rund 3.6X 50µA weil du nur 1 IC und nicht 4 PCF8583 brauchst. ;-)
nie mehr als 3.4V an. Der µC läuft so auch viel Stabiler und grad bei > Zeitmessungen mit den Internen Oszillatoren, sollte man sehr darauf > achten das nicht über die interne ESD Schutzdiode, die VCC des µC > /Unruhig/ wird, das kann selbst ein Quarzoszi aus dem Tackt bringen. Wird nach der
-
Thread
externer Quarz nötig?
Ich möchte meinen Atmel 89C51CC03 über die UART Schnittstelle programmieren. Der Prozessor hat ja nun auch einen CAN-Controller on Board der 1Mbit/sec bei 8Mhz erreichen kann. Allerdings kann CAN ja Fehler erkennen, UART nicht. Sollte ich zur sicheren Übertragung mittels UART lieber einen Bauratenquarz einsetzen oder reicht der interne aus? Sollte der interne nicht auch so genau sein, dass damit auch eine fehlerfreie Übertragung möglich ist?
-
Thread
ATmega8 verhält sich fehlerhaft
Was ist denn am Port D angeschlossen? PD0: Signaleingang von der Codeeingabe-Einheit (mittels UART und RS232 über MAX232) PD1: Signal an die Türeinheit (langsames Signal, kein UART oder so) PD2: Signal von der Türeinheit (zur Meldung von Fehlern) (langsames Signal, kein UART oder so) PD3
Fehler erst sehr spät suchen. Auf mechanische Einwirkung reagiert er auch nicht. Habe an den Kabeln gewackelt - nichts. Zudem müssten da viele Kontakte auf einmal kaputt sein. Und der Fehler dürfte nicht
-
Thread
suche vergleichbaren typ pic16f84 aus der 18er reihe
18pins interner oszi 1 uart oder auch 2 umso mehr enthalten umso besser schau mir den mal an. whitenoise
von reg nach reg, der ja wiederum 2 takte zu brauchen schéint wenn ich recht gesehen habe und der internen pll) - enlich ist der RW fehler der alten pic reihe ausgeschaltet, dieser hatte mir in der vergangenen zeit viel ärger beschert, gerade im aufbau von charlieplexinganzeigen, wo man dann ohne externe
-
Thread
Atmega8 + Uart
undendlich so weiter habe ja im programm eine dauerschleife drinn. Der holt sich den takt aus dem internen qaerz. Ich habe eine baudrate von 9600. Hier mal mein Programm: /* * UartTest.c * * Created: 28.05.2012 12:35:08 * Author: Rene */ #define F_CPU 8000000 #define BAUD
ironisch gemeint. Ein einziges Zeichen hätte auch gereicht. > Der holt sich den takt aus dem internen qaerz. Intern befindet sich gar kein Quarz, sondern nur ein Oszillator, welcher nicht unbedingt genau ist. Und das ist auch schon Dein Fehler! ... wenn nicht noch weitere vorhanden sind ...
-
Thread
Retro Fieber: Z80 oder 68000 ?
Einzelgattern aber die Lösung gefällt mir besser. 3 Adressleitungen auf 8 Demuxer Ports. 2. KIO Uart: Welchen uC Takt muss ich wählen, damit ich die bekannten Baudraten mit geringem Fehler erzeugen kann? Aktuell habe ich einen 3.6864 Mhz Oszillatorbaustein und einen 4.0000 Mhz Baustein. Der KIO wird
Adressbits dekodieren reicht aus. Bei bis zu 4 Bausteinen tuts auch ein halber 74HCT139. > 2. KIO Uart: KIO war der PLCC 84 Klops. Du meinst sicherlich den STI. > Welchen uC Takt muss ich wählen, damit ich die bekannten > Baudraten mit geringem Fehler erzeugen kann? Wie bei so ziemlich jeder
-
Thread
Mein neuer Lieblingsmikrocontroller
Vergangenheit. Aber der Controller ist einfach toll! Also es ist ein 16 Bit Controller, der auch mit dem internen RC-Oszillator mit den vollen 32MHz betrieben werden kann! Allerdings brauchen die Befehle mindestens 2 Takte, so dass effektiv etwas weniger als 16MIPS rauskommen. Der Controller ist im bastelfreundlichen
kann man auch I2C nicht verlegen Hatte ich schon erwähnt. > Damit bleibt nicht viel übrig. UART und die Timer-Geschichten (PWM und > so). Ob sich das lohnt? 2x SPI, jede Menge Timer-Pins, 2x UART, externe Interrupts, ... Bei dem oben betrachteten 28pin Zwerg sind das 23 Inputs und 17 Outputs
-
Thread
seriell auslesbare Taster/Schalter, Idee zur Diskussion
sinnvolle Wiederholrate festgelegt werden. Dieses Primitivverfahren setzt nur voraus, daß die UARTs der beteiligten µCs eine ausreichend genaue Taktquelle haben, damit es in der Übertragungskette zu keinen Fehlern kommt. Man kann natürlich auch ein komplexeres Protokoll als einzelne Bytes verwenden
LPC811,LPC812,LPC824 haben HW-UART und vor allem einen abgeglichenen internen 12MHz-Oszillator mit max. 1.5% über den gesamten Temperaturbereich. Man kann direkt UART betreiben ohne ext. Taktgeber. Kosten so 80ct @ >100Stk. Andererseits
-
Thread
Zeichendarstellung im Monitor
mit 80%-iger Wahrscheinlichkeit läuft der Mega mit internem Oszillator. Kontrollier mal die Fusebits. Als ersten Test könntest du auch den Quarz auslöten, wenn immer noch Zeichen kommen liegt obiger Fehler vor. Eine andere Möglichkeit wäre die Baudrate auf
Sieht deine Initialisierung so aus ? // UART initialization // Communication Parameters: 8 Data, 1 Stop, No Parity // UART Receiver: On // UART Transmitter: On // UART Baud rate: 9600 UCR=0x98; UBRR=0x19; ACSR=0x80; UDR = 'S'; //'
-
Thread
AVR Butterfly Taktfrequenz
Von 1 MHz würde ich ohne Studium der Butterfly-Doku auch erstmal ausgehen -- das wäre nämlich der interne RC-Oszillator. Einen Quarz hat er meines Wissens bestenfalls für die RTC (32 kHz).
Ja, eine gewissen Kalibrierung braucht's schon, um die 0,2 % einzuhalten. Der interne RC-Oszillator wird im Auslieferungszustand so kalibriert (Voreinstellwert des OSCCAL-Registers), daß er bei 5 V Ucc die 1 MHz recht genau einhält (genau genug für eine RS-232 auf jeden Fall). Leider
-
Thread
Attiny45 und Arduino
Welcher Takt intern erzeugt werden kann, steht im Datenblatt (128kHz, 8MHz, 16MHz. Die 100nF an VCC fehlen auf jeden Fall. Ohne das Programm und die Fuseeinstellungen kann Dir keiner sagen, was Du noch falsch machst.
programmierst du den ATtiny jetzt ? Ohne dass du die Fuses veränderst, arbeitet der ATtiny45 mit internen 1 MHz. Wenn das reicht, ok. Sonst musst du die Fuses verändern.
-
Thread
USART und mein Code
In Zeile 42 ist ein logischer Fehler.
falsch? Ist > nicht, ist Werkseinstellung mit 1 MHz Intern. lies bitte das Tutorium mit dem internen Oszillator kannst Du bei der UART keinen Blumentopf gewinnen. Du brauchst einen Quarz und musst auf ext. Oszillator umstellen. Gruss Otto
-
Thread
LED Adressierung bei Buslängen > 10 m
mittlerweiler mit RS485 gelöst. Funktioniert soweit ganz gut. Setzte allerdings ATMegas ein, so dass ich eine UART habe. Sollte Dein ATTiny keine UART haben, kannst Du ja auch eine Software-UART implementieren. Bei RS485 Treibern kannst Du die Std.Bauteile nur mit max.32 Nodes am Bus betreiben. Aber es gibt Bausteine
Auf jeden Fall werde ich eine bitweise Synchronisierung brauchen, da die Controller mit ihren internen Oszillatoren bei schwankenden Temperaturen (evtl. auch als open-air Lichtkette) funktionieren sollen. Nur der Master bekommt einen Quarz. Tendieren tue ich zu b.), weils noch etwas einfacher zu
-
Thread
Ich verstehe den Timer0 beim ATtiny 13 nicht.
. Wenn ich den ATtiny 13 nun laut dem Fusecalculator von Engbedded so einstelle, das ich den internen RC Oszillator auf 9,6 MHz stelle und den Takt durch 8 teile (CKSEL=10 SUT=10) dann bekomme ich doch bei aktiviertem Timer0 den TimerOverFlow Interrupt 4687.5 (4688 ?) mal pro Sekunde, oder liege ich
im Beitrag #2251215: > das ich den internen RC Oszillator auf 9,6 MHz stelle und den > Takt durch 8 teile (CKSEL=10 SUT=10) Den Takt würde ich auf 9,6 MHz lassen und stattdessen den Prescaler für den Timer auf 8 setzen. Evtl. noch höher
-
Thread
Empfangen mehrerer Zeichen
UBRRL = 25; stimmt weil ich den internen 1 MHz Oszillator verwende. Und Hardwaremäßig müsste auch alles ok sein da ich einen STring senden kann. Ich kann ein einzelnes Zeichen Empfangen nur sobald es mehr als eines sind funktioniert
> UBRRL = 25; stimmt weil ich den internen 1 MHz Oszillator verwende. Das wäre mir zu unzuverlässig. Wenn ich UART nutze, verwende ich auch grundsätzlich einen baudratentauglichen Quarz. ...
-
Thread
ATTiny10/11/12
vor allem wenn man ein print auf einem avr benutzt der überhaupt kein uart hat. das zeigt doch recht schon, dass da grundlagen fehlen. deshalb mag ich bascom nicht. das abstrahiert die hardware zu sehr mit den ganzen fertigen routinen, so dass man keine ahnung mehr hat was
@markus wie erklärst du dann das das wohl das problem war? ich kann nur vermuten, dass der sw uart wohl erst initialisert werden muss und der standardmässig versucht den hw uart zu nehmen. und das schlug wohl fehl
-
Thread
I2C Monitor mit Mega8
senden. Wenn dies schon nicht funtioniert, dann stimmt was an der UART übertragung nicht. Entweder falscher Quarz oder UART-Teiler Einstellung. Oder Falsche parameter im Terminalprogramm (Parity,Stopbit Baudrate) Wenn das "Start" nach dem Reset immer sauber rauskommt
rumbiegen muss, wenn ich mich doch halbwegs auf die "gesnifften" Daten verlassen will. Mit dem internen Oszillator ist das sowieso so eine Sache. Bei Anwendungen, wo das Timing nicht relevant ist kann man ihn gut benutzen. Aber Anwendngen mit RS232 fallen bei mir unter "Timingrelevant". Lg EC
-
Thread
STM32F103 "verfused"? Wie kann ich ihn wiederbeleben?
Konfiguration ist es nicht möglich sich komplett auszusperren (Der Controller startet immer mit dem internen Oszillator und wechseln die Taktquelle erst durch deine Firmware.
Es ist eben _immer_ vorteilhaft, sowohl die BOOTx Pin(s) als auch Reset und RxD und TxD vom ersten UART an irgend einen Steck oder wenigstens an ein Testpad zu legen, um mittels Bootlader an den Chip heranzukommen. W.S.
-
Thread
Daten vom UART am LCD ausgeben
Hallo Leute, Ich denke ich habe ein "kleines" Problem aber ich find den Fehler im System irgendwie nicht richtig. Ich wollte folgendes probieren: Ich wollte per UART Daten zum Mikrocontroller (ATMega8) schicken. So diese müssten ja im Buffer UDR abgelegt sein. Jetzt wollte ich
z.B. nicht, wie du den Wert für MYUBRR berechnest und ob du einen externen Quarz (gut) oder den internen RC-Oszillator (schlecht) verwendest.
-
Thread
UART von einem PIC24F zu einem PIC16F
Sockel haben, empfängt er die "falsche" Nachricht und reagiert "richtig" auf sie, wir schließen einen Fehler beim Empfang des PIC16 deswegen praktisch aus. Hier die Register-Einstellungen beim PIC24F: /* UART-EINSTELLUNGEN: Siehe Seite 192-195 von Datenblatt */ IEC0bits.U1TXIE = 0; //Interrupt
Datenblättern entnehmen kann. Der PIC24F wird von einem externen 32MHz-Quarz, der PIC16F von seinem internen 4MHz Oszillator getaktet. Wie gesagt, Simulation tut richtig, Schaltung aber nicht =( Wir denken nicht, dass es dran liegt, dass der interne 4MHz Oszi vom PIC16f einfach schlecht ist, weil er wie
-
Thread
Brauche Unterstützung beim OV7670 (bzw. SCCB)
Blumen gehen an ihn). Sodann folgt das eigentliche Problem, das seinen Ursprung beim Aufruf von "UART0_senden_Byte(Ov7670_readByte())" hat. Bei der Sichtung dieser Routine fiel mir auf: sie ruft die Unterroutine "UART0_tx_in(Byte)" auf und in dieser Unterroutine wiederum wird ein internen Puffer
Wenn meine Vermutung richtig ist, dann habe ich den Fehler: (muss ich aber noch mit einem Sniffer nachweisen: wenn hier was schief geht, flute ich den Buffer mit Bytes, die er nicht erwartet: [code}void OV_SCCB_RegisterToUart(char RegisterAddress){
-
Thread
Abblockkondensatoren bei hoher Packungsdichte
zucken, das ist Fast schon Morsen. > Das kann >aber auch dadran liegen das der Tiny kein Hardware UART kann und es uU >bessere Softwarelösungen gibt. uhhhhhh!! Warum nimmst du keinen Tiny mit Hardware-UART? Oder einen GUTEN Soft-UART? Ob es ein Kabel- oder Softwareproblem ist, kannst du prüfen
. Außerdem hast du das Problem, daß der interne RC-Oszillator nicht so super genau ist und ggf. kalibriert werden muss. https://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART >DS76176 komme ich jedenfalls völlig stressfrei auf
-
Thread
Darstellungproblem
RC-Oszillator ? Peter
Ich denke, dass Peter dich gefragt hat, ob du mit dem internen RC-Oszillator arbeitest. Eine Antwort wäre hilfreicher als eine Gegenfrage. ...
-
Thread
ATmega16 - UART
hallo leute, habe folgendes problem. ich verwende ein stk500 mit einem atmega16. hab mit den zugehörigen tools von internen rc oszi auf externen hochfrequenz resonator umgeschaltet. wollte jetzt wie im tutorial test über die rs232 senden. hab natürlich auch die dafür nötigen adaptionen am testboard vorgenommen, doch ich erhalte nur schrott. einstellungen habe ich wie im tutorial getroffen und sogar mal probiert anstatt 2 stopbits mal 1 stopbit. doch auch wieder nur schrott. hab auch schon rx mit tx vertauscht, da kommt dann gar nichts. betreffend der baudrate habe ich die oszillator frequenz
-
Thread
Unterschied ATmega88 / ATmega168
@ Richard (Gast) >Der Fehler lag in der Baudrateneinstellung. >Ich musste den Wert etwas anpassen, da sich der interne >Oscillator bei 2MHz anscheinend etwas anders verhält >als der des ATmega88. Nun läuft die Anwendung. Du hast soeben einen Preis gewonnen. 1000er UART-User, der mit internem Oszillator arbeitet. Das soll man nicht machen. Warum? Lesen Sie hier. [[AVR-Tutorial: UART]] >Der kompilierte Quellcode besteht beim mega88 aus 3015 words, und beim
-
Thread
sleep - Timer2 soll aufwecken
Taktfrequenz schwankt zwischen 7.9 und 8.2 MHz bei 8Mhz interner Frequenz
(Gast) >Sag mal Falk, was hast Du denn gegen meinen Beitrag? Weil er suggeriert, dass eine UART Kommunikation mit internem RC-Oszillator ganz easy ist. Das ist nicht der Fall. Es kann laufen. Man kann auch mit gewissen Aufwand (Kalibrierung, zyklische Rekalibrierung) das hinbekommen. Aber man
-
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
Eigenes i.MX6 Board - JTAG läuft. Wie nun weiter mit U-Boot?
Habs bisher nur über die C Datei gemacht.. Dann würde noch MDIO und Reset Muxing fehlen ;-) zb: MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(MDIO_PAD_CTRL), MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL), MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),
Dirk M. schrieb im Beitrag #5872180: > MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL), Wofür ist RESET Dirk M. schrieb im Beitrag #5872180: > Reset Muxing fehlen ;-) Was meinst du mit letzterem? Hab den RESET des PHYs an GPIO
-
Thread
Neuer Controller, altes Programm: Fahler im Zeitkonitnuum
mitteilen, dass nun ein 4MHz Quarz dranhängt bzw., da ich hörte, dass Atmel mit eingeschaltetem internen Oszillator geliefert wird, welches Programm brauche ich oder nach was muss ich suchen, um die Fuses zu setzen, die dem Chip sagen, dass er nun auf den externen hören soll. Eine hab ich noch: angenommen
mitteilen, dass nun ein 4MHz Quarz dranhängt bzw., da ich > hörte, dass Atmel mit eingeschaltetem internen Oszillator geliefert > wird, welches Programm brauche ich oder nach was muss ich suchen, um die > Fuses zu setzen, die dem Chip sagen, dass er nun auf den externen hören > soll. Wie bereits
-
Thread
Arduino Timerprobleme - suche programmierbaren Oszillator
benötige, sehe WIE Stabil? Atomuhrgenau wird es sicher NICHT sein! Selbst der eher gurkige Oszillator der kleinen Arduinos mit ca. 0,1% Fehler wird es VERMUTLICH tun. Ein Quarz, den man auch sehr einfach nachrüsten kann hat nur 0,01% (100ppm) und weniger Frequenzfehler. > ich in den kleinen Abweichungen
laufen. Man könnte der AVR also auch gut mit seinem internen 8MHz RC-Oszillator laufen lassen und der OP wäre glücklich. Ich sehe auch nirgends die Anforderung, daß ein Parameterwechsel besonders oft oder schnell erfolgen muß. Man kann also neue Frequenzen
-
Thread
8 Lichtschranken mit Tutorialaufbau abfragen
Jo ich würde auch ganz einfach die internen Pull UP Wiederstände aktivieren.
genau sein muss, z.B. > für UART (dann Baudratenquarz benutzen) oder Uhr. Ich bräuchte beides. Eine genaue Uhr und Datenübertragung zum PC. Welchen Oszillator soll ich dann nehmen? Bei Reichelt gibts ja mindestens 20 im Bereich
-
Thread
Induktiver Positionssensor - Fragen dazu
Änderung angeben. Man müßte also die Frequenz deutlich erhöhen, um sinnvolle Meßwerte zu erzielen. Es fehlen aber Angaben, wie sich dabei die Verluste in Spule und Magnetkreis erhöhen. Da wirst Du also noch viel experimentieren müssen. Allgemein würde ich einen Oszillator mit der Spule in einem Schwingkreis
-) > > Alles vorausgesetzt, dass ich das richtig aufgebaut habe. Da ist Dir vermutlich ein Fehler unterlaufen, denn meine Schaltung funktioniert ja bei mir (auch wenn ich - wie im Nachhinein festgestellt - keinen echten RL-Oszillator sondern eine Kippstufe aufgebaut hatte). > Als nächstes probiere
-
Thread
USB IR Remote Receiver (V-USB + IRMP)
MHz, 16 MHz or 20 MHz crystal or from a 12.8 MHz or 16.5 MHz internal RC oscillator." Da der interne Oszillator vom ATTiny85 nur max. 8MHz liefert, ist der Quarz zwingend erforderlich. Gruß, Frank
> in etwa den 10kHz Abfragerate entspricht. "In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder? Gruß, Frank
-
Thread
CP/M auf ATmega88
wie von Leo vorgeschlagen, bei 20 MHz uC Takt und dann noch mit 1 bzw. 2 Waitstates bei 8 MHz uC internen Takt. Aber es hilft alles nichts, diese beiden IC's sind definitiv defekt! Vielleicht solltest Du Deinen DRAM's auch mal nur 8 MHz uC internen Takt gönnen, dann sollte aber wirklich nichts fehlen
> aber bei 4800 Baud funktioniert unsere Soft-UART (RX) nicht mehr. :( Geht jetzt ab 2400 Baud. Noch langsamer ist zusätzliche Arbeit, die ich mir jetzt spare. Der Fehler mit Wordstar ist auch mit 2400 noch da. Wordstar schreibt erst das Directory
-
Thread
Programmieren von STM32F765VGT6
ausprobieren. Na dann, lass blinken. Beim dem Blinky im Anhang wird PC13 geschaltet und dazu der interne Oszillator benutzt. Zum übertragen empfehle ich das neue STM32CubeProg. https://www.st.com/en/development-tools/stm32cubeprog.html
Ups, kleiner Fehler. Hier die Richtige:
-
Thread
ATMEGA644 Timer on Compare Match Problem
jetzt genaue Zeiten über enen längeren Zeitraum (Minuten) > messen will , hab ich dann nicht einen Fehler von 0.1% ? Du hast Karl Heinz nicht verstanden. Der Fehler liegt nicht im Timer, sondern in der Methode, wie du ihn festzustellen versuchst. Die Ausführung dieses Codes: [c] uart_puts("s:
internen Oszillator.
-
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
Prozessor 100% voll, Problem?
es zu teuer, ein "fertiges" Produkt auf dem Markt zu kaufen. Welche Features brauche ich: - interner Oszillator 8Mhz (andere Taktfrequenz würde die ganzen Zeitroutinen im Programm ändern), externer Quarz nicht nötig (so genau muss es nicht sein) - 2 Timer, mind. einer 16-bit mit Input Capture, Compare
Siegfried schrieb: > Welche Features brauche ich: > - interner Oszillator 8Mhz Haben nahezu alle. Der in den neueren AVRs ist allerdings etwas stabiler als der frühere. > - 2 Timer, mind. einer 16-bit mit Input Capture, Compare Match, einer > 8-bit mit
-
Thread
CH340 als Einzelchip in DE?
diesen Chips eine Seriennummer eingestellt werden. Das ist sehr hilfreich wenn mehrere solcher USB UART Wandler angesteckt sind. Ich bin wieder beim FTDI, auch wenn der etwas mehr kostet.
EUR im DIL14 ( Baudrate 300 ... 460800 ) https://www.shotech.de/de/mcp2221a-i-p-usb-2-0-to-i-2c-uart-protocol-converter-with-gpio.html 1,90 EUR im SO14 ( Baudrate 300 ... 460800 ) https://www.shotech.de/de/mcp2221a-i-sl-usb-2-0-to-i-2c-uart-protocol-converter-with-gpio.html Versand kostete nur