-
Thread
Probleme RS232
Hatte auch mal einen Fehler bei den Kond. das sah dann auch so aus.
Und der AVR läuft auch damit, oder vielleicht doch noch mit dem internen RC-Oszillator? Fuses checken!
-
Thread
5V aus 12V für PIC16F15325
Bruno V. schrieb im Beitrag #7946620: > Das fällt fast alles weg, wenn Du den PIC mit dem internen > 32k-Oszillator betreibst, nur µA verbrauchst (...) Der PIC braucht µA? Dann könnte man sogar über energy harvesting nachdenken. So ein Automotive-Taster hat einen relativ kräftigen Pullup,
Verpolung, Überspannung, Bursts, ...). > > Das fällt fast alles weg, wenn Du den PIC mit dem internen > 32k-Oszillator betreibst, nur µA verbrauchst und die Spannung durch LEDs > erzeugst. ... Aber Hallo, auf welchem Tripp bist du den? Verpolung? Wo denn? Ich bau die Schaltung ja selbst. Bursts
-
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
AVR-Atmega32 RS232 keine PC Verbindung?!
.1s! Das heisst der µC läuft schon mal mit der externen Taktquelle (Quarz) und nicht auf dem internen RC-Oszillator. Das ist gut! Ca. 1s ist OK. Per Ansehen sieht man nicht, ob es ein 1s (14,756 MHz) oder 0,92s (16 MHz) Blinken ist.
> und MAX232 falsch sind. Bei dem Hardwaretest oben würde man gekreuzte > Leitungen nicht als Fehler erkennen, weil die Drahtbrücke in der > IC-Fassung des µCs symmetrisch arbeitet - anders als ein UART eines µCs. > Kreuzen der TX/RX Leitung, brint mir im AVR Studio trotzdem "no supported board
-
Thread
Atmega8, DCF an Interrupt. Ungültige Signaldauer mit externem Quarz
einem Atmega8 anzusteuern und mir die Zeit korrekt ausgeben zu lassen. Im leichtesten Fall mittels UART. In diesem Fall läuft der Controller mit dem internen RC-Oszillator auf 4 MHz. Das Signal vom DCF Modul wird an Pin4 mit einem Interrupt getriggert. Beispielhafte Debugausgabe im UART (Zahlen sind
Analyzer (z.B. einen Slaeae Clone mit freier Software Sigrok für <8€ (oder 17€ Prime)) und finde den Fehler mit Leichtigkeit. Ein Pin an die UART, ein Pin an das DCF Signal und lasse Dir durch die integrierten Decoder beide Signale in Klartext(!) anzeigen, wo es schiefgeht. Vermutung sind kurze Spikes im
-
Thread
Atmega128 - Programm wird geladen, aber LED blinkt nicht?
Quarz? Thread durchgelesen? Die Fuses stehen auf Default, d.h. das Dingens läuft mit dem internen durch 8 geteilten RC-Oszillator mit 1 MHz. Ohne laufenden Oszillator ließe er sich ja gar nicht erst programmieren. > Erste inbetriebnahme des Prozessors? dann Frequenz korrekt einstellen.
lässt eine LED an PortB.0 im Sekundentakt blinken. Systemeinstellungen: - Chip ATmega168p - interner Oszillator, 1 MHz - PortB.0 Output Viel Erfolg!
-
Thread
Raspberry Pi ATmega328p pu per SPI
werd ich es dann wohl auch machen, da ich keinen Quarz hier hab kann ich sowieso höchstens die internen 8 Mhz nutzen und bei 3v3 dann die 4Mhz. Hoffe das der interne Oszillator genau genug läuft :)
Olovskos Bla schrieb im Beitrag #3550428: > Hoffe das der interne Oszillator genau genug läuft :) Für SPI ist der genaue Takt nicht ganz so entscheidend, wie für eine UART-Kommunikation. Außerdem läßt sich der interne Takt mit OSCCAL auch etwas verbiegen...
-
Thread
FS20 Sender mit ATmega für Dimmer und Heizungsregeler
Der interne RC Oszillator ist nicht sehr genau, ob der soviel abweicht kann ich nicht sagen. Die Abweichung laut Deinen Angaben ist ca. 0.8mS. Falls Du nicht irgendetwas Merkwürdiges misst, denn ich hoffe das
) & 0x07)*10)+ (sekunde & 0x0F); i2c_stop(); } void Alarmzeit() { alarmstunde = uart_getc(); asm("nop"); asm("nop"); asm("nop"); alarmminute = uart_getc(); } uint8_t uart_getc(void) { while (!(UCSRA & (1<<RXC))) ; // warten bis Zeichen verfuegbar return
-
Thread
Fehler in der Anzeige bei GLCD
Zeile 65 - da ist dein Fehler
keine delay nehmen. Wie macht man dann sowas? >achim Dann aktiviere mal zwischenzeitlich den internen Oszillator und teste das ganze bei niedrigerem Takt. MfG Spess
-
Thread
AVR-UART-Ausgabe kommt oft aus dem Takt
0; } // puts ist unabhaengig vom Controllertyp void uart_puts (char *s) { while (*s) { // so lange *s != '\0' also ungleich dem "String-Endezeichen" uart_putc(*s); s++; } } [/c]
@Bensch: Es gibt doch den iternen RC-Oszillator und nen externen Takteingang wo in der Regel ein Quarz angelötet wird.
-
Thread
Logic Analyzer bauen
einen schnellen µC, lege die Signale an einen Port, tastet diesen ab und speichere die Daten im internen RAM.
Hi, vielleicht solltet ihr ein USB AVR nehmen (48Mhz). Der interne USB schafft 12Mbit. Gruß, Dirk
-
Thread
ADC Board für Trenz Electronic FPGA Modul
erzeugen und messen. Wenn immer noch Fehler auftreten, liegen diese zwischen FPGA, USB und PC, wenn nicht, zwischen Bus und FPGA. Da die Fehler scheinbar immer den Pixelwert 0 haben, sieht das nach Timingproblemen an einer Schnittstelle aus,
Muster erzeugen und messen. Wenn immer noch Fehler > auftreten, liegen diese zwischen FPGA, USB und PC, wenn nicht, zwischen > Bus und FPGA. Da die Fehler scheinbar immer den Pixelwert 0 haben, sieht > das nach Timingproblemen an einer Schnittstelle
-
Thread
ATMEGA328P-AU läuft etwa um Faktor 10 langsamer als normal
pF sind empfehlenswert. Wenn du sonst nicht viel programmiert hast (Fuses?), sorgt da der interne RC-Oszillator (ca. 8 MHz) bei CKDIV8 für etwa 1 MHz.
bestimmt den Takt und da muss der "geflashte" Bootloader das auch wissen was F_CPU war sonst kann er die UART nicht richtig beim Start initialisieren. Wenn kein Bootloader auf dem Chip ist nimmt er eh weder was an der UART an noch passt der interne Takt zu den Fuses. Warum läuft der bei ihm 10x langsamer
-
Thread
Bewegungssensor für Fahrrad Alarm
Serial-Interface ausgegangen, ala LSM6DS und Konsorten... Stimmt natürlich, mit Analogausgang und ohne interne Register fällt das alles weg.
Versorgungsspannung. Allerdings bezweifle ich, dass der Schaltplan korrekt ist. Ich sehe da auf Anhieb schon 2 Fehler, mit denen die Schaltung meiner Meinung nach unmöglich funktionieren kann. Als dritten Fehler vermisse ich im Plan das Potentiometer.
-
Thread
BASIC-Computer mit Mega32
der Codesammlung, das Testbild dort stammt vom 32-er Basic) einfach anschließen zu können. Da der interne Quarzoszillator dafür ungeeignet ist, synchronisiere ich den internen Oszillator auf den 16MHz-Ausgang vom CPLD um Jittereffekte ("Schwimmen" des Bildes) zu vermeiden. Stecke ich stattdessen ein Adapterkabel
port die videosignalgenerierung stattfindet? Soweit ich weiß haben doch die avrs portpins alle interne pullups die per software aktivierbar sind. und dann noch eine frage, warum sind an der parallel schnittstelle die vielen vorwiderstände R1-R8, wenn man doch jetzt zum beispiel den internen ad wandler
-
Thread
Midi über USART - ich bin am verzweifeln ;o(
include <avr/delay.h> int main(void) { #ifndef F_CPU #define F_CPU 16000000 #endif #define UART_BAUD_RATE 31250 #define UART_BAUD_CALC(UART_BAUD_RATE,F_OSC) ((F_CPU)/((UART_BAUD_RATE)*16L)-1) UBRRH=(uint8_t)(UART_BAUD_CALC(UART_BAUD_RATE,F_CPU)>>8); UBRRL=(uint8_t)UART_BAUD_CALC(UART_BAUD_RATE
programmiert (1) Schon mal mit nem Oszi den Takt gemessen?? vieleicht läuft dein ATMega ja mit internem Oszillator. Das würde das ganze Verhalten erklären. Achja für die Hardware. Bei Logischem High Pegel fließt kein Strom in der Midischnittstelle. Logisch Null als entsprechend Stromfluss. Dann
-
Thread
[msp430] 9600 Baud mit 32kHz
Hallo ich kenne den MSP nicht. Aber wenn der keinen eigenen Oszillator für die UART-Schnittstelle hat, Du also also mit deinem Sytemtakt arbeitest wird das schon ein Problem. Schon die 4800 Baud aus 32768 Hz zu erzeugen wird ein Problem: 32768:6 = 5459 baud, 32768:7
Hallo, Standardmäßig ist der interne Oszillator an. wird der verwendet ist bei höheren Baudraten die Abweichung zu groß und dazu kommt noch die Abhängigkeit der Frquenz von der Temperatur. Lösung : am besten einen externen (höheren)
-
Thread
STM32F4 discovery auslesen - unbekannte Programmgröße
bootloaden kann? Und das dann über einen anderen UART? Kann man testen, ob ein Bootloader am UART "wartet", ihm also eine Sequenz einfüttern, auf die hin er sich "meldet"? Ist das dieser Intel ":"-Loader? Für erhellende Beiträge danke ich im Voraus
Pins 39 und 42 von P2. > R68 - entf. > > SB10 - ON Ha, dann ist ja auch klar, warum der interne ST-Link nicht funktioniert ... > SB12 - OFF > SB15 - OFF > SB16 - OFF > SB18 - OFF > SB19 - OFF > SB20 - OFF Das betrifft Oszillator und SWO, ist also uninteressant, weil man sowieso wohl
-
Thread
PIC oder AVR Microcontroller - Unterschiede?
sind natürlich die 8051-er. Und mit über 30 Herstellern auch die Familie mit den meisten Varianten (interne ADC, DAC, PCA, UART, I2C, CAN, USB, MP3, Ethernet). Zum 8051 kann ich Dir ne Menge sagen. Die PICs habe ich mir auch mal angesehen, aber wenn man erstmal 8051 gemacht hat, will man sich mit
MHz Bustakt hochtreiben, was einer Zykluszeit von 125 ns entspricht. Das läßt sich über einen Oszillator regeln, die lassen sich aber auch mit einem 32 kHz Quarz betreiben und dann wirde die Takfrequenz über die Programmierbare PLL variabel gesteuert. Manche haben auch einen Internen Oszillator. Die
-
Thread
Unterschiede zwischen ARM und ATmega in der Programmierung
Kommunikations-Schnittstellen. Der ist auf den Eval Boards sowieso immer vorhanden. Beispielsweise beim STM32F103 hat der interne RC-Oszillator "HSI" ab Werk eine Toleranz von -2% bis 2.5% bei 8MHz. Nils N. schrieb im Beitrag #5319567: > Ein paar µS Timerinterrupt Sekunden schafft auch ein AVR relativ > genau > mit internen Quarz. Es gibt keinen internen Quarz, nur interne RC-Oszillatoren. Und diese Angabe der Auflösung sagt nicht viel aus.
-
Thread
LCD Ansteuerung mit ATtiny 2313
irgendwo aus Netz. Nein. Schauen wir mal deine Fuses an. Da steht "Int RC Osc. 8Mhz". D.H. interner Oszillator ist deine eingestellte Taktquelle, mit 8MHz. Dann steht etwas oberhalb noch "Divide clock by 8 enabled". Dein Takt aus dem internen Oszillator wird also noch durch 8 geteilt. Dein Controller
am Anfang angehängt habe aus dem Internet kopiert und bei Bascom nur eingefügt, ich glaub das war Fehler Nr.:1 Fehler Nr. 2 : Ich habe beim Programmieren nie vorher manuell erased sondern immer gleich auf write dann bekomme ich zwar eine Meldung "writen to flash" aber es passiert einfach nix.
-
Thread
Dimmer-Schaltplan Verständnis Problem
so alles richtig gemacht? Irgendwelche offensichtlichen Fehler?
der PLL (dazu gleich mehr) am Oszi verifiziert/debuggt habe. Eine Erkenntnis dabei war, das der interne Oszillator des uC zu viel jittert woraufhin ich dann einen uC mit externem Quarz vorgesehen hatte. Zur Funktionsweise der Nulldurchgangserkennung: Über den Pin PB2 (Originalplan) wird die Leerlaufspannung
-
Thread
Datensatz aus UART "gewinnen"
Ich kann eigentlich kein Fehler im code sehen. (bis auf das C Dateien auch die Endung .c haben sollten). Hast du einen Quarz oder nutzt du den internen Oszilator?
Hast du mal ausgerechnet wie groß der Fehler der UART bei 115kBaud ist? Denn ich habe die Geschwindigkeit mit keinem ATMEGA stabil zum laufen bekommen!
-
Thread
AT Befehle zum Handy senden
Wenn der Atmel ohne Quarz weiter funktioniert dann ist der interne Oszillator aktiv. Und der hat ab Werk 8MHz/8 = 1MHz Also Fuse Bits ändern.
, 10); uart_puts(buffer); } uart_putc('\r'); [/c]
-
Thread
Daten an PC mit MAX232
// 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 //UART-Schnittstelle Initialisieren void uart_init(void) { UBRR0H = UBRR_VAL >> 8; UBRR0L = UBRR_VAL & 0xFF; UCSR0B = (1<<TXEN0); // UART TX einschalten //UCSR0C |= (1<<UCSZ00) | (1<<UCSZ01); // UART 8-Bit Modus UCSR0C = (1
-
Thread
Senden/Empfangen Problem mit ATtiny 2313 und FTDI FT232R
uint8_t in; DDRB |= 1 << 2; PORTB |= 0 << 2; DDRB |= 1 << 3; PORTB |= 1 << 3; uart_init(); // wait on key while(1) { in = uart_getc_wait(); if( in == 0x31) PORTB |= 0 << 3; uart_putc(in); } } [/c] Die LED's steuere ich im moment zu debugzwecken
Hi, Danke für die Infos, dachte ich kann den Internen Oszillator auch bei UART benutzen, vor allem da ich die Tests mit 300 Baud durchgeführt habe... Werde deine Vorschläge mal ausprobieren. mfg Andreas
-
Artikel
AVR Bootloader optiboot Assemblerversion
installierten Bootloaders einfacher, selbst mit einem anderen PC. Unterstützt die Anpassung der Oszillator-Frequenz für den AVR internen RC-Oszillator. Dadurch ist auch in Problemfällen die Benutzung eines Bootloaders mit fester Baudrate möglich. Das Laden des optiboot Programms in den jeweiligen AVR
LFUSE Einstellung. Im ersten Beispiel paßt die Betriebsfrequenz 16 MHz nicht zu dem gewählten RC-Oszillator Betrieb. Korrekt wäre ein Aufruf wie make atmega328p LFUSE=E2 F_CPU=8000000 BAUD_RATE=38400. Hier soll aber gezeigt werden, daß beim Erstellen des Bootloaders versucht wird, Fehler zu vermeiden.
-
Thread
CAN UP - Aktor (LPC11Cxx)
Hallo Den Quarz kannst Du auch ganz weg lassen und mit dem internen Oszillator arbeiten. Gruß Ulf
Der Quarz ist nicht nötig, der LPC11C24 läuft auch mit dem internen 12 MHz RC Oszillator. Aber der J6 am LPCLink2 ist ein Problem, ich habe den auch modifiziert. Entweder du setzt noch den Jumper JP2, dann wird der µC über den Pin1 vom J6 mit Strom versorgt. Das
-
Thread
UART receive data
Hallo ihr, kann mir mal einer helfen bei der UART programmierung. (AT90S2313) ich möchte mit dem UART von einem anderen avr daten empfangen. Diese sollen per interrupt, ausgewertet werden. Nur leider springt der processor die int routine nicht an
Hi Eine Datenübertragung mit dem Oszillator vom STK500 kannst du knicken. die Genauigkeit reicht um eine Led Blinken zu lassen, mehr aber auch nicht. Der UART-Interrupt wird erst ausgelöst wenn ein Datenbyte incl. Start- und Stopbit vollständig
-
Thread
LCD Controller für 640x480 LCD mit mega8515
Hi Leute, es hat sich erledigt -> habe den Fehler gefunden. ;-)) Alex
immer genau 50% Tastverhältnis. Die Software ist ziemlich stark kaputt optimiert, vor allem da von UART mit 9bit auf parallel mit 9bit (LPT), von parallel auf UART mit 8bit (FT232) und von UART mit 8bit auf parallel mit 8bit (FT245) umgestellt wurde... Wenn du den Code nicht verstehst, beschreib mal
-
Thread
Schaltungsvorschlag AtTiny
nachgehen, habe aber keine große Hoffnung auf einen Bootloader. Daß AtTiny12 und AtTiny15 keinen HW-UART haben hatte ich schon bemerkt, dann werde ich das Ganze entweder wie von dir vorgeschlagen per Interrupt betreiben oder wie in der AN305/AVR305 (DOC0952.pdf) von Atmel beschrieben als Software UART
AtTiny25/45/85 Typen. Die haben immerhin eine HW-USI. Damit soll laut AN307/AVR307 (DOC4300) auch eine UART-Funktion programmierbar sein. Ob die mit dem internen Oszillator besser funktioniert wie die Softwarelösung habe ich aber noch nicht nachgelesen. Das mit dem Resetpin ist mir klar, ich benötige ja
-
Thread
UART Übertragungsfehler bei bestimmten Zahlenwerten
frage ich mich sofort ob denn die Baudrate ausreichend genau stimmt. Wenn man im Controller einen internen Oszillator als Zeitbasis verwendet kann das schon mal schiefgehen.
> du dann low byte und high byte ? Übertragungsfehler habe ich bereits ausgeschlossen, der Fehler passiert nur bei manchen bestimmten Zahlenwerten. Ich habe schon >1000 Übertragungen ohne Fehler hintereinander, wenn ich eben nicht die paar besonderen Werte übertrage.
-
Thread
Linux Uart AVR
Was gibt es für einen Grund so zu schicken uart_puts_P("Hallo Linux\n\0"); und nicht so uart_puts_P("Hallo Linux\n"); oder uart_puts_P("Hallo Linux\n\r"); ? Gruß Sven
: Sind die Fuses richtig gesetzt? Falls du da noch nix dran geändert hast, stehen die noch auf internen RC-Oszillator. -> Baudrate stimmt nicht. Gruß Roland
-
Thread
UART beim Atmega 88 will nicht
wie kommst du auf die krummen zahlen? der interne oszillator ist doch ab werk auf 8MHz eingestellt...
Hi Bist du sicher,das du die richtigen Datenblätter hast. Der ATMega162 hat definitiv 2 UARTs und der ATMega88 nur eine. MfG Spess
-
Thread
Magische Hand oder doch das Quarz?
Thomas Gruber schrieb im Beitrag #2578399: > Ist das ein Fehler oder? Stimmt das Symbol denn?
genommen. Hab jetzt den Quarz komplett gelöscht und neu eingefügt. Doch leider immer der selbe Fehler. Anbei die Fotos von der Fertigen Platine. Der Fehler vom Quarz habe ich hier behoben.
-
Thread
vom Layout zum Schaltplan
. Den externen Quarz kannst du dir sparen. Lt. Datenblatt ist er nicht mal nötig, wenn man mit UART rummacht, der interne 8MHz Oszillator sei selbst dafür genau genug. RB0 kann als Interrupt benutzt werden, ist also genau richtig am 'Wasser-vorhanden' Sensor.
> Den externen Quarz kannst du dir sparen. Lt. Datenblatt ist er nicht mal > nötig, wenn man mit UART rummacht, der interne 8MHz Oszillator sei > selbst dafür genau genug. wenn ich das richtig erkannt habe, ist der ext. Quarz auch 8 Mhz (Aufschrift 8.000) Was bringt das dann überhaupt, wenn der
-
Thread
Schon mal jemand das CY8CKIT-049 4200 in der Hand gehabt?
ich bin von Tag zu Tag begeisterter. Ich habe einige kleine Projekte realisiert. (LCD-Ansteuerung, UART Kommunikation, KeyPad u.a,) Das größte Projekt ist bisher eine Anzeige von Digitalen Messschiebern. Da komme ich dank der internen Analog- und Digitalcomponenten nahezu ohne externe Bauteile aus (
starten... das macht man 2h mit und bestellt sich dann das pioneer kit ;-) (oder man benutzt den 2. uart - dann fehlen aber schon wieder ressourcen...) ...alex
-
Thread
Analoge Orgel mit USB-MIDI steuern
später - schon mit SN74, aber ansonsten keine Unterschiede. Damals baute man noch so: 12 LC-Oszillatoren, für jeden Ton, und Oktavteiler. Eine Orgel, wo separate Oszillator für jede Taste vorhanden war, habe ich nie getroffen (so könnte eine analoge Orgel aussehen) - schon allein deshalb, weil man
Frequenzteilung im Verhältnis 2:1, und zwar auf analogem Wege über synchronisierte Sperrschwinger-Oszillatoren.