Sehr geehrtes Forum, ich habe vor einen Atmega48PA per RS232 mit dem PC kommunizieren zu lassen. Ich verwende HTerm und AVR Studio. Dazu habe ich Pin 2 (RXD) und Pin 3 (TXD) des Atmegas mit meinem MAX232 Modul verbunden. (Mein Max232 Modul ist ein Fertigbauteil, ich habe schon zwei verschiedene Module verwenden, und die funktionieren eigentlich) Auf meinem MAX232 Modul gibt es sogar leds, die anzeigen ob die Stromversorgung korrekt angeschlossen ist, und LEDs für RXD und TXD. Nun habe ich nochmal nach diesem Tutorial und Code : http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART#Senden_von_Zeichen Das Programm auf meinen Atmega geflashed. Wenn ich nun mein Terminalprogramm öffne, die im Tutorial beschriebenen Einstellungen vornehme, und dann die Stromverbindung für den Atmega anstelle, kommen einfach keine Signale am PC an. Der Atmega, so zumindest die LEDs von MAX232 Modul, sendet einfach keine Signale. Sorry, vielleicht überseh ich einfach eine Kleinigkeit, aber ich weiß nicht woran es liegen sollte. Danke für eure Hilfe, m.f.G.: K.R.
Hast Du RXD vom AVR mit RXD oder mit TXD von MAX232 verbunden? Je nachdem wie der Entwickler gedacht hat, mußt Du die kreuzen.
Nein ich habe sie nicht gekreuzt, müssten die LEDs aber nicht trotzdem blinken, oder müsste der PC dann nicht wenigstens Mist empfangen? *Edit: Es funktioniert gekreuzt auch nicht. Ich denke es liegt eher am Code. Es ist ein Atmega48 PA. Der Atmega funktioniert auch einwandfrei. Daran liegt es nicht. Ich vermute ein Softwareproblem. Kann es daran liegen dass der Code für Atmega8 geschrieben ist? (Sind doch eigentlich fast gleich ausgestattet auch von den Bezeichnungen)
Wenn 2 Ausgänge aufeinander liegen gewinnt einmal der Stärke und bei 2 Eingängen passiert garnichts (außer daß vielleicht beide Unsinn einfangen). Um zu testen, ob der Adapter funktioniert kannst Du den AVR mal weglassen und RXD und TXD verbinden. Dann muß alles was Du tipst wieder angezeigt werden und die LED syncron flackern.
Dann zeig doch deinen Code und verweise nicht auf ein Tutorial, in dem drinsteht, wie es richtig sein soll. mfg.
Also: Erstmal danke für eure Hilfe. Wenn ich RXD und TXD verbinde, kommt dasselbe auch wieder am PC an, was abgesendet wurde. Hardwaretechnisch steht soweit alles. Mein Code:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
Du solltest zumindest die .include "m8def.inc" in .include "m48def.inc" oder .include "m48pdef.inc" ändern.
Gast
#3437130
Einfach nur kopieren kann ins Auge gehen, wie schon mancher Minister erfahren musste. Im Datenblatt des ATmega48 das Kapitel Register Summary anschauen und danach den Unterschied zwischen out und sts ergründen.
Sorry, bin bisschen aus der Übung. Ich werde mich da im Datenblatt nochmal einlesen und melde mich gleich zurück.
> ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
URSEL hat da auch nichts verloren.
In C wäre das jetzt einfacher. Den Assemblercode musst du schon ein
bisschen mehr umkrempeln. Vor allen Dingen sind die Adressen nicht mehr
im I/O Space und daher nicht mehr mit out erreichbar.
mfg.
Gast
#3437141
Wobei nach dem Tipp von Oliver R. vermutlich der Assembler mit seinen Fehlermeldungen bereits in die richtige Richtung weisen wird.
Mein Problem ist folgendes, und erinnert mich an die PWM Geschichte von mir: Ich habe ein Tutorial, in welchem mir erklärt wird was ich machen soll. Sogar im Datenblatt ist eine Art Tutorial, interessant wird es dann aber, wenn selbst der Code aus dem Datenblatt von meinem AVR Studio nicht akzeptiert wird, und ich nirgendwo eine Tabelle mit Bezeichnugnen der ganzen Bytes finde. Nun steh ich da und weiß nicht mehr weiter. Z.B.: http://www.atmel.com/images/doc2545.pdf S.178, den Assembler Code zur Initialisierung bei meinem AVR Studio wird gesagt, dass UBRRnH nicht existiert (Undefined Symbol). Hat jemand vielleicht ne gute Erklärung was ich machen könnte?
Gast
#3437161
Hi
>Hat jemand vielleicht ne gute Erklärung was ich machen könnte?
Atmel hat da schöne Migration Notes. Auch eine vom Übergang vom ATMega8
zu ATMega48/88/168.
MfG Spess
Gast
#3437163
Das 'n' steht für eine Ziffer, in diesem Fall wohl '0', denn wenn ich es richtig sehe, hat der ATmega48 nur einen USART, eben USART0.
K. R. schrieb: > http://www.atmel.com/images/doc2545.pdf > S.178, den Assembler Code zur Initialisierung > bei meinem AVR Studio wird gesagt, dass UBRRnH > nicht existiert (Undefined Symbol). > > Hat jemand vielleicht ne gute Erklärung was ich machen könnte? Dir ist aber klar, daß "n" in diesem Fall für "0" steht und entsprechend ersetzt werden muß? mfg.
Und womit denn? Ich habe '_', '0', 'A', 'B' versucht, nichts funktioniert. Sorry aber diese Erklärungen finde ich nicht gerade sinnvoll, man kann nicht einfach hingehen, einen Code hinklatschen, ohne ein einziges Mal zu erklären was n ist, bzw. womit es zu ersetzen ist. Im gesamten Kapitel kommt es als Index in allen Bezeichnungen vor, aber nirgendwo wird gesagt, was es ist. Sorry, aber was soll ich denn da einsetzen?
Gast
#3437175
Welche Fehlermeldungen kommen denn, wenn Sie das 'n' durch '0' ersetzen?
Gast
#3437176
Hi
>Sorry, aber was soll ich denn da einsetzen?
Das was im Datenblatt steht.
MfG Spess
K. R. schrieb: > Und womit denn? > > Ich habe '_', '0', 'A', 'B' versucht, nichts funktioniert. > Sorry aber diese Erklärungen finde ich nicht gerade sinnvoll, > man kann nicht einfach hingehen, einen Code hinklatschen, ohne > ein einziges Mal zu erklären was n ist, bzw. womit es zu ersetzen ist. > > Im gesamten Kapitel kommt es als Index in allen Bezeichnungen vor, > aber nirgendwo wird gesagt, was es ist. > > Sorry, aber was soll ich denn da einsetzen? "0". Aus RXC im UCSRA-Register wird RXC0 im UCSR0A-Register. mfg.
der alte Hanns schrieb: > Welche Fehlermeldungen kommen denn, wenn Sie das 'n' durch '0' > ersetzen? C:\Users\user\Desktop\AVR RS232 Tests\RS232_Test_1.asm(30): error: Undefined symbol: UBRR0H
Gast
#3437187
Dann sind Sie vermutlich nicht dem Hinweis von Oliver R. gefolgt, dieses aber ist unabdingbar.
K. R. schrieb: > der alte Hanns schrieb: >> Welche Fehlermeldungen kommen denn, wenn Sie das 'n' durch '0' >> ersetzen? > > C:\Users\user\Desktop\AVR RS232 Tests\RS232_Test_1.asm(30): error: > Undefined symbol: UBRR0H Falsche xxdef.inc ? mfg.
Oliver R. schrieb: > Du solltest zumindest die > .include "m8def.inc" > in > .include "m48def.inc" oder .include "m48pdef.inc" > ändern. ^^^^^^^^ Das geändert? weil beim ATmega8 gibt es kein UBRR0H MfG Hans
Natürlich habe ich das schon geändert. Also das ist im Moment mein Verstümmelter Code, und ich weiß gar nicht so recht was jetzt konkret eingesetzt werden soll, weil, wenn ich das durch 0 ersetze kommen da Fehlermeldungen wie vorhin beschrieben.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
Fehlermeldungen
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Gast
#3437216
'... out of range' heißt in unserem Zusammenhang 'out' durch 'sts' ersetzen. 'Undefined symbol' weist meist auf einen Tippfehler hin. > ldi r16, (1<<USBS0)|(3<<UCSZn0) Was bedeutet dieses? UCSR0A liegt beim 48er im extended IO, also muss > serout: > sbis UCSRA0,UDRE0 ; Warten bis UDR für das nächste > ; Byte bereit ist > rjmp serout komplett umgeschrieben werden.
K. R. schrieb: > Undefined symbol: UCSRA0 Das Register heisst UCSR0A. Der Atmega48 hat ein paar grössere Verwandte, die mehrere USARTs haben. Um das konform zu gestalten, hat man bei dem die "0" da eingefügt. Nur derjenige, der die Namen für die Interruptvektoren festgelegt hat, ist bei dem Meeting, in dem das besprochen wurde, offenbar abwesend gewesen. Die Interruptvektoren heissen daher z.B. USART_RX. Das nur mal am Rande. mfg.
Gast
#3437230
> bei dem Meeting, in dem das besprochen wurde, offenbar abwesend gewesen.
Es menschelt eben überall.
Also, einige Probleme habe ich lösen können, andere wiederum nicht. Ich habe neben den ganzen Problemen eine Frage: Welche Taktfrequenz hat denn ein 48PA Standardmäßig? Ich habe nie was umgestellt oder nen externen Quarz.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Übrigstens bin ich da anscheinend nicht der einzige, der ein Problem mit diesem Chaos hat: http://www.roboternetz.de/community/threads/45300-Atmega48-Uart-Wahnsinn Danke für eure Hilfe bis jetzt
*Update Ich habe jetzt mal in die m48def.inc geschaut, und da habe ich UCSZn0 in UCSZn00 umbenannt. Der Fehler is schonmal weg.
Gast
#3437269
Natürlich habe ich das schon geändert Die erste Fehlermeldung sagt wohl, das die Datei nicht gefunden werden konnte. MfG Hans
Gast
#3437274
Ausgeliefert wird er mit 1 MHz. Und die Zeile > ldi r16, (1<<USBS0)|(3<<UCSZn0) ist noch immer da. Dass Sie den Code nach serout: umschreiben müssen, haben Sie mitbekommen? > und da habe ich UCSZn0 in UCSZn00 umbenannt. > Der Fehler is schonmal weg. Definitiv nicht, Sie sind etwas von der Rolle.
K. R. schrieb: > *Update > Ich habe jetzt mal in die m48def.inc geschaut, > und da habe ich UCSZn0 in UCSZn00 umbenannt. > > Der Fehler is schonmal weg. Das sind noch 2: out UBRR0H, HIGH(UBRR_VAL) out UBRR0L, LOW (UBRR_VAL) mfg.
der alte Hanns schrieb: > Ausgeliefert wird er mit 1 MHz. > > Und die Zeile >> ldi r16, (1<<USBS0)|(3<<UCSZn0) > ist noch immer da. > > Dass Sie den Code nach serout: umschreiben müssen, haben Sie > mitbekommen? > >> und da habe ich UCSZn0 in UCSZn00 umbenannt. >> Der Fehler is schonmal weg. > Definitiv nicht, Sie sind etwas von der Rolle. Gott sei Dank muss man sich C um so einen Scheiss nicht kümmern. Das musste jetzt einfach mal gesagt werden. mfg.
Gast
#3437283
Hi >Übrigstens bin ich da anscheinend nicht der einzige, der ein Problem mit >diesem Chaos hat: >http://www.roboternetz.de/community/threads/45300-... Haben nur Leute, die nicht Lesen können oder wollen: http://www.atmel.com/Images/doc2553.pdf MfG Spess
Gast
#3437301
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Den Rest, Tippfehler &c., können Sie sicher alleine.
So alle Fehler behoben (mit F_CPU=4000000), aber es kommt immer noch nichts an, eine Idee woran es liegen könnte? (Die LED flackert trotzdem nicht) Wenn ich F_CPU auf 1000000 setze, dann funktioniert es nicht, weil der Compiler dann natürlich folgende Zeile ausspuckt: .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit geht es nicht. Was soll ich da machen?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
K. R. schrieb: > So alle Fehler behoben (mit F_CPU=4000000), aber es kommt immer noch > nichts an, eine Idee woran es liegen könnte? > (Die LED flackert trotzdem nicht) > Das ist ja nun kompletter Unsinn. > Wenn ich F_CPU auf 1000000 setze, dann funktioniert es nicht, weil der > Compiler dann natürlich folgende Zeile ausspuckt: > .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit > geht es nicht. > > Was soll ich da machen? Setz die Baudrate auf 4800 und aktiviere das U2X0-Bit in UCSR0A. Damit verdoppelst du die Geschwindigkeit und hast wieder 9600. Aber dann passt der Teiler besser. mfg.
Gast
#3437327
Hi
>Was soll ich da machen?
Dann setze die Baudrate auf 4800. 9600Bd geht halt mit 1MHz nicht.
MfG Spess
Ich habe mal die Baudrate auf 4800 gesetzt und dasselbe auch in HTERM gemacht, anstatt mein U2X0-Bit in UCSR0A zu setzen. Aber trotzdem sendet mein Atmega nichts.
Gast
#3437337
Legen Sie vorläufig diese Berechnungen still und nehmen Sie die Werte
aus dem Datenblatt Examples of Baud Rate Setting:
ldi temp,high(12) ; 9600 Bd bei 1 MHz mit U2X0=1
sts UBRR0H,temp
ldi temp,low(12)
sts UBRR0L,temp
ldi temp,(1<<U2X0)
sts UCSR0A,temp
und weiter sollten Sie schreiben:
ldi temp,(1<<USBS0)+(1<<UCSZ01)+(1<<UCSZ00)
sts UCSR0C,temp
anstelle dieser Bitraterei bei UCSR0C.
Nebenbei:
> Dann setze die Baudrate auf 4800. 9600Bd geht halt mit 1MHz nicht.
Das stimmt so nicht ganz, siehe oben.
Gast
#3437360
> ldi temp, UCSR0A > sbrs temp, UDRE0 Das haben Sie aber nicht von mir!
Gast
#3437416
Eine geschlagene halbe Stunde ohne Reaktion ?! - Ich geh' schlafen. Kann mich aber doch nicht enthalten, bei allem Verständnis, Reinhard Mey zu zitieren: "Ich übe den Fortschritt, und das nicht faul, nehme zwei Schritt auf einmal und fall aufs Maul."
der alte Hanns schrieb: >> ldi temp, UCSR0A >> sbrs temp, UDRE0 > > Das haben Sie aber nicht von mir! Wie soll man das denn sonst lösen? der alte Hanns schrieb: > Eine geschlagene halbe Stunde ohne Reaktion ?! - Ich geh' > schlafen. > > Kann mich aber doch nicht enthalten, bei allem Verständnis, Reinhard Mey > zu zitieren: > "Ich übe den Fortschritt, und das nicht faul, > nehme zwei Schritt auf einmal und fall aufs Maul." Danke für Ihr Engagement, aber ich kann bedauerlicherweise erst morgen weiterarbeiten, ich muss zur Arbeit. der alte Hanns schrieb: > Legen Sie vorläufig diese Berechnungen still und nehmen Sie die > Werte > aus dem Datenblatt Examples of Baud Rate Setting: > > ldi temp,high(12) ; 9600 Bd bei 1 MHz mit U2X0=1 > sts UBRR0H,temp > ldi temp,low(12) > sts UBRR0L,temp > ldi temp,(1<<U2X0) > sts UCSR0A,temp > > und weiter sollten Sie schreiben: > ldi temp,(1<<USBS0)+(1<<UCSZ01)+(1<<UCSZ00) > sts UCSR0C,temp > anstelle dieser Bitraterei bei UCSR0C. > > Nebenbei: > >> Dann setze die Baudrate auf 4800. 9600Bd geht halt mit 1MHz nicht. > > Das stimmt so nicht ganz, siehe oben. Ich werde morgen versuchen den Schritten zu folgen Danke!
Gast
#3437488
Hi >> Nebenbei: >>> Dann setze die Baudrate auf 4800. 9600Bd geht halt mit 1MHz nicht. >> Das stimmt so nicht ganz, siehe oben. >Ich werde morgen versuchen den Schritten zu folgen Bei 1MHz bekommst du bei 9600Bd einen Fehler von 7%. Mit Double Speed kommst du auf (theoretische) 0,2%. Allerdings mit verminderter Störsicherheit. Wenn dein 1MHz-Takt vom internen RC-Oszillator kommt, wird das ganze eh zum Vabanquespiel. Kann (manchmal) funktionieren oder auch (manchmal) nicht. MfG Spess
spess53 schrieb: > Hi > >>> Nebenbei: > >>>> Dann setze die Baudrate auf 4800. 9600Bd geht halt mit 1MHz nicht. > >>> Das stimmt so nicht ganz, siehe oben. >>Ich werde morgen versuchen den Schritten zu folgen > > Bei 1MHz bekommst du bei 9600Bd einen Fehler von 7%. Mit Double Speed > kommst du auf (theoretische) 0,2%. Allerdings mit verminderter > Störsicherheit. > > Wenn dein 1MHz-Takt vom internen RC-Oszillator kommt, wird das ganze eh > zum Vabanquespiel. Kann (manchmal) funktionieren oder auch (manchmal) > nicht. Nein. Das funktioniert sehr zuverlässig. Sofern man die Bedingungen, unter denen der Oszillator werkskalibriert ist, einigermassen einhält. Daß es ohne Neukalibrierung über den gesamten Temperatur- und Spannungsbereich nicht funktioniert, ist klar. mfg.
Gast
#3437645
K. R. schrieb: > der alte Hanns schrieb: >>> ldi temp, UCSR0A >>> sbrs temp, UDRE0 >> >> Das haben Sie aber nicht von mir! > > Wie soll man das denn sonst lösen? Sie sollten korrekt kopieren: ich hatte lds geschrieben, nicht ldi (da UCSR0A=C0 und UDRE0=5, wird die Schleife nie verlassen). spess53 schrieb: > Wenn dein 1MHz-Takt vom internen RC-Oszillator kommt, wird das ganze eh > zum Vabanquespiel. Kann (manchmal) funktionieren oder auch (manchmal) > nicht. Schon, spess53, aber wir wären ja bereits froh gewesen, wenn K.R. irgendeine Reaktion auf dem Monitor gesehen hätte.
Gast
#3437658
K. R. schrieb: > Übrigstens bin ich da anscheinend nicht der einzige, der ein Problem mit > diesem Chaos hat: > http://www.roboternetz.de/community/threads/45300-Atmega48-Uart-Wahnsinn > > Danke für eure Hilfe bis jetzt Das hier ist wiedermal ein schoenes Beispiel fuer jemanden, der offensichtlich nicht zu Ende gelesen hat. Im verlinkten Thread lag es eben gerade nicht an "diesem Chaos", sondern wie so oft sass die Fehlerursache vor dem Computer. wendelsberg
Funktioniert jetzt alles :D
Nur die Geschwindigkeit ist auf 9600 Baud gedrosselt. Wenn ich dieses eine Bit setze, damit der Chip doppelt so schnell arbeitet, klappt das nicht, aber egal.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.