Hallo Forum, meine RS232 Datenübertragung ist extrem Fehlerhaft. Ich sende Daten vom Atmega 8 zum PC über nen Adapter (hab ihn gebaut wie hier im Forum beschrieben mit MAX 232). Was der Atmega raussendet sieht ja ganz gut aus(Kanal 2), aber was der Adapter daraus macht ist mir unklar (Kanal 3). Habe schon vieles probiert, alle elektrischen Geräte in der Nähe aus, am Laptop damit ich unabhängig vom Netzt bin... Den Adapter direkt an den Laptop anschließen, damit ich kein langes Kabel habe... Nix hilft... Hat jemand eine Idee? Gruß Stefan
Oder noch besser: Photo Denn wenn du die Schaltung nach Tut aufgebaut hast, sollte das eigentlich funktionieren (wenn wir mal davon ausgehen, dass die Komponenten nicht fehlerhaft sind). Nun passiert es aber manchmal, dass man zwar den richtigen Schaltplan hat, aber in Wirklichkeit was anderes aufgebaut hat. Ein zweites Augenpaar wirkt da oft Wunder.
Hallo Stefan, das sieht so aus als würde die Ladungspumpe des MAX232 nicht korrekt arbeiten. Sieh dir doch mal mit dem Oszilloskop die Spannung an Pin 2 (+8,5V) und Pin 6 (-8,5V) an. Ich denke, dass bei der negativen Spannung eine große Restwelligkeit ist. Prüfe mal, ob du alle Kondensatoren korrekt angeschlossen hast und ob die Werte stimmen. Gruß, Alexander
@Alexander Vielen Dank für deinen Tip, an Pin 6 war eine hohe Restwelligkeit, dort war eine kalte Lötstelle... So, nun sehen meine Signal gut aus, aber es treten immer noch krass viele Fehler in der Kommunikation auf... Momentan hab ich nur eine Endlosschleife die mir "255" ausgeben soll, ich bekomme aber nur 191 oder 253, grundsätzlich scheinen Bit 2 und Bit 7 zukippen... Hat da jemand noch ne Idee?
Stefan S. wrote: > "255" ausgeben soll, ich bekomme aber nur 191 oder 253, > grundsätzlich scheinen Bit 2 und Bit 7 zukippen... Was zeigt nun das Oszilloskop?
Das Oszi zeigt den richtigen Wert an... Baudrate passt, habe auch schon verschiedene ausprobiert. Der uC Takt kommt von einem QUarz, 8 Mhz
@Einhart Gute Frage, damit hab ich mich nicht beschäftigt, aber hier der Quellcode meiner Funktion zum Daten senden. Da würde ich spontan sagen, nein die wartet nicht
1 | USART_Transmit: |
2 | sbis UCSRA,UDRE |
3 | rjmp USART_Transmit |
4 | out UDR,temp |
5 | ret |
hab mir grad noch das das wiki über uart durchgelesen, also liegt es wohl auch nicht daran das die Schleife nicht wartet
Stefan S. wrote: > hab mir grad noch das das wiki über uart durchgelesen, > also liegt es wohl auch nicht daran das die Schleife nicht wartet Die ist ok. Sie wartet, korrekterweise, bis das Register zum Senden frei ist. Die wahrschinlichste Ursache ist nach wie vor, dass die Baudrate, bzw. der Takt aus dem die Baudrate abgeleitet wird, nicht stimmt.
Sag dochmal etwas mehr ... Welche Baudrate hast du eingestellt? 115k? Welcher Teiler?
Ich habe verschiedene probiert, 300,9600,19200 und 38400, hier noch die Berechnung für die Register
1 | .equ F_CPU = 8000000 ; Systemtakt in Hz |
2 | .equ BAUD = 300 ; Baudrate |
3 | |
4 | ; Berechnungen |
5 | .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; |
6 | .equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate |
7 | |
8 | ;initialisierung |
9 | |
10 | ldi temp, HIGH(UBRR_VAL) |
11 | out UBRRH, temp |
12 | ldi temp, LOW(UBRR_VAL) |
13 | out UBRRL, temp |
14 | |
15 | ; Frame-Format: 8 Bit |
16 | ldi temp, (1<<URSEL)|(1<<UCSZ0)|(1<<UPM1)|(1<<USBS);even parity, 2 Stopbits |
17 | out UCSRC, temp |
18 | |
19 | sbi UCSRB,TXEN ; TX aktivieren |
> .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ;
Was hat denn das "+BAUD*8" da zu suchen?
Hab mir nicht so viele Gedanken über den Text gemacht, hab das von irgendwo übernommen. Also muss das "*8" raus?
Also eigentlich nimmt man diese Formel:
.equ UBRR_VAL = ((F_CPU)/((BAUD)*16)-1) ;
> das hab ich aus dem Tutorial von hier...
Hm, stimmt, man kann damit natürlich eine Rundung des letzten Bit
erzeugen.
Stefan S. wrote:
> Was bringt mir denn diese Rundung?
ohne Rundung: 19/10 = 1
mit Rundung: 19/10 = 2
Also kramen wir mal das übliche raus: .equ F_CPU = 8000000 ; Systemtakt in Hz Ist verifiziert, dass der µC auch wirklich mit 8Mhz läuft?
Und der AVR läuft auch damit, oder vielleicht doch noch mit dem internen RC-Oszillator? Fuses checken!
Bin mir ziemlich sicher das die Fuses richtig sind, dummerweise hat mein Programmer grad die Hufe hochgerissen :-( Was kann ich noch alles checken sobald ich nen neuen Programmer hab, bzw meinen wieder hinbekommen hab?
Hallo Stefan .. hier ein paar Tipps. Um sicherzustellen, daß der µc geht - RxD mit TxD direkt am Chip verbinden - Prüfmuster 0x00 0xaa 0x55 0xff senden - selbst wieder empfangen und testen wenn das klappt dann hinter dem MAX232: - wie oben ... wenn es bis hierher klappt kann nur noch die Baudrate nicht stimmen oder das Problem liegt im PC oder der Leitung Parity even mit 2 Stoppbits ist SEHR exotisch nimm besser N81 (No Parity, 8 Datenbits, ein Stoppbit) Hatte bei einem PC Probleme damit weil dessen UART das nicht richtig konnte: Hab ich leder nur in C zur Hand ... UBRRH = 0; UBRRL = UBRR_16MHZ_115200; // direkt setzen SB3(UCSRB, RXEN, TXEN, RXCIE); // Rx und Tx einschalten SB3(UCSRC, URSEL, UCSZ1, UCSZ0); // N81 UDR; UDR; SB2(UCSRA, RXC, TXC); // opt. Interrupt einschalten sei(); SB2 und SB3 sind Macros die das hässliche (bitnr<<1) .. ersetzen Für die Baudrate UBRL den festen Wert aus dem Datenblatt setzen. Manchmal verrechnen sich die Compiler im Präprozessor (hat mich schon mal eine Nacht gekostet) Vielleicht hilft das weiter :-) viel Erfolg Frank
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.