Hallo zusammen, ich versuchs jetzt schon eine gewisse Zeit meinen ATmega8 mit dem PC ueber Uart Kommunizieren zu lassen. Erste versuche mit dem ATtiny 13 int. oszil ging ganz gut (Fanzis Microkontroller Lernkasten). Jetzt habe ich mir folgende Bauteile zugelegt: ATmega8, 1,8432 MHZ Oszillator (4 Beine) und versuche das erste Beispiel von http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Fusebits: Low: 11100000 High:11011001 Lock:11111111 Ausgelesen mit dem mySmartUSB MK2 Tool (atmega nutzt das teil auch, denn wenn ich den Oszillator ausbau geht gar nix mehr) Passt 1,8432 vielleicht nicht an den atmega8? Tja Test bezueglich der Frequenz habe ich auch gemacht: via AVR Studio ein ASM gebaut, dass 1000000+-1000 us wartet und eine LED an und aus schaltet, das passt etwa von der Zeit (1sec an 1 sec aus) aber im Terminal kommt nur Muell an 55 53 A3 51 5B FF 00 sollte eigentlich T e s t ! 13 10 bedeuten .... tja soweit so ratlos ... snip Beispiel fuers Blinken und AVR Studio ueber alt-o auf 1,8xxx mhz gestellt Warten: Ldi r16,253 ;1000000 Warten1: ;äußere Schleife Ldi r17,37 ;10000 Warten2: ;äußere Schleife Ldi r18,32 ;100 ;1 Warten3: dec r18 nop nop nop ;1 brne Warten3 ;1 || 2 dec r17 brne Warten2 dec r16 brne Warten1 ret ;Rücksprung Was genau passt hier nicht .... ? Vielen Dank cheers jens
> aber im Terminal kommt nur Muell an
Leider sieht man im QuellcodeAusschnitt nicht wie du die UART
initialisierst. IMHO steckt dort die größte Fehlerwahrscheinlichkeit.
Denkst du nicht, dass es vernünftig wäre dein UART Programm zu zeigen, wenn dir die UART Probleme macht?
wie gesagt, ist aus dem Tutorial http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART aber ich poste es gern nochmal .... .include "m8def.inc" .def temp = r16 ; Register für kleinere Arbeiten .def zeichen = r17 ; in diesem Register wird das Zeichen an die ; Ausgabefunktion übergeben ;.equ F_CPU =4000000 .equ F_CPU = 1843200 .equ baud = 9600 ; Berechnungen .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden .equ BAUD_REAL = (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 ; Stackpointer initialisieren ldi temp, HIGH(RAMEND) out SPH, temp ldi temp, LOW(RAMEND) out SPL, temp ; Baudrate einstellen ldi temp, HIGH(UBRR_VAL) out UBRRH, temp ldi temp, LOW(UBRR_VAL) out UBRRL, temp ; Frame-Format: 8 Bit ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0) out UCSRC, temp sbi UCSRB,TXEN ; TX aktivieren loop: ldi zeichen, 'T' rcall serout ; Unterprogramm aufrufen ldi zeichen, 'e' rcall serout ; Unterprogramm aufrufen ldi zeichen, 's' rcall serout ; ... ldi zeichen, 't' rcall serout ldi zeichen, '!' rcall serout ldi zeichen, 10 rcall serout ldi zeichen, 0 rcall serout rcall sync sbi ddrc,3 sbi portc,3 ende: rcall Warten cbi portc,3 rcall Warten sbi portc,3 rjmp ende serout: sbis UCSRA,UDRE ; Warten bis UDR für das nächste ; Byte bereit ist rjmp serout out UDR, zeichen ret ; zurück zum Hauptprogramm ; kleine Pause zum Synchronisieren des Empfängers, falls zwischenzeitlich ; das Kabel getrennt wurde sync: ldi r16,0 sync_1: ldi r17,0 sync_loop: dec r17 brne sync_loop dec r16 brne sync_1 ret Warten: Ldi r16,253 ;1000000 Warten1: ;äußere Schleife Ldi r17,37 ;10000 Warten2: ;äußere Schleife Ldi r18,32 ;100 ;1 Warten3: dec r18 nop nop nop ;1 brne Warten3 ;1 || 2 dec r17 brne Warten2 dec r16 brne Warten1 ret ;Rücksprung So jetzt aber ....
Der von dir gewählte Takt ist im Datenblatt auf Seite 159 explizit aufgeführt. Sollte also gehen. Ich würde noch mal die FuseBits prüfen. Ist die Fuse für die externe Clock gesetzt ? Ist die Fuse für den Clk/8 Teiler aus ? Im Quellcode habe ich die Konfiguration vom U2X Bit nicht gesehen. Ist das passend gesetzt ? Hatte die selben Probleme alle Konfig Parameter im Blick zu halten. Allerdings habe ich C benutzt und nicht Assembler. Gruß, dasrotemopped
Ich sehe die Ursache nicht. Sieht alles richtig aus (Quellcode und Fuses). Ist der Rest OK? Einstellungen im PC Terminalprogramm kontrolliert (Soll 9600/8N1)? Looptest schon gemacht? Atmega8 aus der Schaltung rausnehmen, Drahtbrücke an IC Fassung wo RXD und TXD war und dann PC was senden lassen. PC sollte exakt das gleiche als Echo zurück bekommen. Testet PC Schnittstelle, Kabel, Pegelwandler auf dem AVR Board.
Hi Bis auf, das >Sollte eigentlich T e s t ! 13 10 bedeuten .... ^ ^ nicht dem Code > ldi zeichen, 10 > rcall serout > ldi zeichen, 0 > rcall serout entspricht, kann ich auch keine Fehler entdecken. Wenn du wirklich dieses Programm auf dem ATMega flashst sollte es eigentlich funktionieren. Bleiben als Unbekannte die Hardware und die Terminaleinstellungen. MfG Spess
Angehängte Dateien:
-
terminal.png
70 KB
Hallo Zusammen, erst mal Danke fuer die vielen Antworten .... ok zu dem was ich noch gemacht habe: - TXD mit RXD verbunden geht - CLK/8 bin mir nicht sicher im mySmartUSB mk2 Tool gibt es die Option fuer den atmega8 nicht beim attiny13 hab ich die gesehen ... bin mir allerdings nicht so sicher ob son Teiler bei einem externen Oszillator noch greifen würde ....also weis jemand obs den gibt, wie er sich nennt und wo ich ihn verändere? - Terminal auf 9600 8n1 ok - U2X Bit habe ich nicht verändert - hätte ich sollen? Ich hab noch nen Bild vom Terminal an gehangen... Cheers Jens
Hi
CKDIV8 gibt es beim ATMega8 nicht. Und auch keinen sonstigen Prescaler
für den Takt.
>U2X Bit habe ich nicht verändert - hätte ich sollen?
Nein.
Was bekommst du denn, wenn du mehrere, gleiche Bytes sendest?
MfG Spess
Angehängte Dateien:
-
uartbits.png
7,7 KB
Guten Morgen, wenn ich 7 mal ein a (0x61) sende dann bekomme ich 7 mal 0x4F und ein 00 Byte. ich pack mal noch ein Bild vom USART-Register dazu ... vielleicht hab ich da einen Bock gebaut.
ach ja, habs mal mit nem 11,0592 Quarz und 2 Kondensatoren 15 pF versucht, Fuses auf Low: 11111111 High:11001001 Lock:11111111 Programm mit neuer Frequenz gebaut (siehe unten) .equ F_CPU = 11059200 liefert ebenfalls bei 7 mal a's (0x61) -> 7 mal 0x4F und ein 00 Mir faellt auch nix mehr ein ...
Beim Br@y++ Terminal (Link siehe RS232) kann man auch krumme Baudraten (custom) einstellen. Ich würde die 9600 Baud auf der PC-Seite mal +- geringfügig variieren ob sich damit die Anzeige verbessert. Wie sieht die Übertragung aus, wenn du den 1,8432 MHz Oszillator durch eine andere Taktquelle ersetzt? Wenn der Oszillator 1% daneben liegt: Bis du bei der 1s Blinkzeitmessung einen 1% Fehler siehst, musst du lange messen... In zwei Minuten kommt gerade mal eine gute Sekunde Abweichung zusammen! Aber +-1% bei UART wird kritisch.
ich habe folgende Taktquellen versucht: - 1,8432 mhz 5 verschiedene Oszillatoren - 4,9152 mhz Oszillator - 11,0592 Quarz und 2 Kondensatoren 15 pF fuer den letzten natuerlich auch fuses angepasst: Low: 11111111 High:11001001 Lock:11111111 immer das Gleiche .... :-( ich blicks nicht... hat jemand noch nen stueck c code das ich mal einspielen kann ... nur senden von hallo.
Jens Straube schrieb: > - TXD mit RXD verbunden geht Direkt am PC oder hinter dem MAX232 auf der µc seite? Mal mit dem Oszi die Signale durchgemessen? Ausgang µc -> Eingang MAX232 -> Ausgang MAX232 -> Eingang PC Gruß P.S: Hatte neulich auch ein UART-Problem: Die Belegung der RS232-Schnittstelle im Mainboard-Handbuch war falsch abgedruckt... hat ne ganze Zeit gedauert bis ich das rausgefunden hatte ;-)
Hi Versuche mal das Hex-File. Das gibt bei mir bei 11,0592MHz die ASCII-Zeichen $20-$7F mit 9600Bd aus. MfG Spess
Angehängte Dateien:
-
uart_1.png
39 KB
@ Spess53 Tja geht irgendwie auch nicht ....mist... hab dir nen Bild dazu gelegt Auf dem Atmega steht Atmega8a-pu, ich hatte gedacht ich hätte den atmega8, das setzen der fusebits geht im myAVR_ProgTool auch nur mit der Einstellung Atmega8 bei allen anderen kommt eine Fehlermeldung ... Kann es daran liegen .... @Djongambo ich hab kein max, ich benuze die Testplatiene vom Franzis Lernpaket, da sind alle Serialpegel schon auf 5V normiert... Daran liegts auch nicht - denke ich - da die Kommunikation mit dem ATtiny13 (auch Lernpaket) gut ging ... und auch die Kommunikation mit Kabel von RXD an TXD ,dort wurde per ASM der UART simuliert Vielleicht hat noch einer eine Idee .... gern auch abwegige...
Hallo zusammen, ich bin immer noch nicht weiter ... hat vielleicht jemand noch ein Progi, das ich in meinen mC flushen kann um zu testen worans liegt ...
Hi >@ Spess53 Tja geht irgendwie auch nicht ....mist... >hab dir nen Bild dazu gelegt Nimm doch mal HTerm und schalte nur ASCII ein. Ich habe eher das Gefühl das das Terminalprogramm in dem Bild Mist anzeigt oder falsch eingestellt ist. MfG Spess
Tut nicht ... gibts die moeglichkeit direkt in den mC rein zu debuggen? Und welche Hardware brauch ich dafuer?
du könntest mit nem oszi am uart ausgang ein singleshot machen und schauen ob die gesendeten daten den im programm(µc) vorgegebenen entsprechen. wenn ja, liegt's wohl eher am pc, wenn nein eher am µc. gruß
Angehängte Dateien:
-
uart3.png
57 KB
ES GEHT !!!! Das Problem lag: an dem FT232RL und zwar hatte ich ja schon gesagt, das ich das Lernpaket Elektronik Start mit USB von Franzis verwende, dort ist auf einer der ersten Seiten beschrieben wie man den FT232RL für die Übungen konfigurieren muss ... Naemlich: S.20 Uebungsbuch sagt: Fuer das Lernpaket werden jedoch nicht-invertierte Signale benoetigt Also Mprog(Bild) alle Häkchen an ... Fuer die Kommunikation mit via UART mit dem ATmega8 und dem FT232RL benötigt man die Standard-Einstellung also genau wie im Bild alle Häkchen AUS .... Das bedeutet, wer erst die Übungen macht und dann etwas eigenes probiert wird hier eine Umstellung wie im Bild gezeigt vornehmen müssen ... An alle die versucht haben mir zu helfen vielen Dank ... ich hoffe das ich nun ebenfalls anderen mit dieser Lösung weiter helfen kann... Cheers und einen schönen Sonntag Jens ( jaaaaa mann ! es geht !! Freu mir nen Ast ab)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.