Forum: Compiler & IDEs Usart - Gleicher Code, unterschiedliche ASM-Listungs und nix geht


von Michael Z. (incunabulum)


Lesenswert?

Moin!

ich bin gerade mal wieder am Verzweifeln. Nach einigen größeren 
Änderungen an meiner Lib funktioniert der HW-Usart meines 
Mega32-Testaufbaus in der neuen Version nicht.

Ausschließen kann ich:
- Änderungen am Usart-Code (diff ist abgesehen von DocString-Änderungen 
leer
- Unterschiedliches Kompilieren (Makefile bis auf 2 zusätzliche Files 
identisch)
- Unterschiedliche hardware (die alte Version geht auch heute noch)

Schau ich mir die Assembler-Listings an, so sehe ich folgendes. Hier die 
UsartInit()-Funktion:

Alt und geht:
1
00000566 <_Z9usartInitv>:
2
}
3
4
void usartInit() {
5
  UART0_CONTROL |= (1<<TXEN) | (1<<RXEN);    
6
     566:  8a b1         in  r24, 0x0a  ; 10
7
     568:  88 61         ori  r24, 0x18  ; 24
8
     56a:  8a b9         out  0x0a, r24  ; 10
9
  usartSetBaudRate(USART_BAUD_RATE);
10
     56c:  60 e8         ldi  r22, 0x80  ; 128
11
     56e:  75 e2         ldi  r23, 0x25  ; 37
12
     570:  80 e0         ldi  r24, 0x00  ; 0
13
     572:  90 e0         ldi  r25, 0x00  ; 0
14
     574:  0e 94 9d 02   call  0x53a  ; 0x53a <_Z16usartSetBaudRatem>
15
     578:  08 95         ret

Neu und geht nicht:
1
000007fc <_Z9usartInitv>:
2
     7fc:  e1 ec         ldi  r30, 0xC1  ; 193
3
     7fe:  f0 e0         ldi  r31, 0x00  ; 0
4
     800:  80 81         ld  r24, Z
5
     802:  88 61         ori  r24, 0x18  ; 24
6
     804:  80 83         st  Z, r24
7
     806:  60 e8         ldi  r22, 0x80  ; 128
8
     808:  75 e2         ldi  r23, 0x25  ; 37
9
     80a:  80 e0         ldi  r24, 0x00  ; 0
10
     80c:  90 e0         ldi  r25, 0x00  ; 0
11
     80e:  0e 94 e6 03   call  0x7cc  ; 0x7cc <_Z16usartSetBaudRatem>
12
     812:  08 95         ret

Mir ist bewusst, dass Assembler-Code optimierungsbedingt unterschiedlich 
aussehen kann. Nur - da Assembler für mich ein Buch mit 7 Siegeln ist:
- wieso sehe ich einmal den C-Code in der alten Version, in der neuen 
aber nicht
- und kann hier die mögliche Fehlerursache (Bug im GCC Optimier etc.) 
für meine Probleme liegen?

gcc ist 4.1.2

Danke und cu, Michael

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Meine Kristallkugel ist gerade aus der Reparatur zurück und hat mir
verraten, dass du den Code für einen ATmega324P statt für einen
ATmega32 compiliert hast.

von Karl H. (kbuchegg)


Lesenswert?

@Michael
Spann uns doch nicht so auf die Folter!
Hat Jörgs Kugel recht oder nicht?

@Jörg
Wahnsinn, wo lässt du deine Kugel reparieren? Kannst du die mal
fragen woran sie das erkannt hat?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl heinz Buchegger wrote:

> Wahnsinn, wo lässt du deine Kugel reparieren?

Ist immer gar nicht so einfach, dafür noch eine Jungfrau aufzutreiben,
die in der Lage ist, Kristallkugeln zu reparieren...

> Kannst du die mal
> fragen woran sie das erkannt hat?

Ich habe mir alle Controller angeguckt, deren UCSR[0]A auf Adresse
0xC1 liegt und mir dann den davon rausgesucht, der dem ATmega32 am
nächsten liegt. ;-)

von Michael Z. (incunabulum)


Lesenswert?

@Jörg:
Soll ich das Ironisch als Wink mit der Glaskugel - die ich insbesondere 
für diesen Zweck kenne - verstehen? Wenn ja, welche Infos bräuchtest du 
noch?

Wenn nein, dann versteh ich auch nix mehr. Beide werden mittels 
mcu=atmega32 oder so (identisches Makefile) gebaut.

Was könnte ich noch testen bzw. welche Infos könnten Euch helfen, mir 
bzw. meiner Doofheit auf die Sprünge zu helfen? ...

cu, Michael (Wie ich mich kenne, liegt der Fehler ja zwischen Tastatur 
und Rückenlehne)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Z. wrote:

> Soll ich das Ironisch als Wink mit der Glaskugel - die ich insbesondere
> für diesen Zweck kenne - verstehen? Wenn ja, welche Infos bräuchtest du
> noch?

Naja, irgendwie kann man halt nur raten, wenn man die zugehörigen
Kommandozeilen etc. nicht sieht.

> Wenn nein, dann versteh ich auch nix mehr. Beide werden mittels
> mcu=atmega32 oder so (identisches Makefile) gebaut.

Dann muss dein <avr/iom32.h> vergurkt sein.

von Michael Z. (incunabulum)


Lesenswert?

@Jörg: Da in beiden Fällen identische makefiles zum Einsatz kommen, war 
meine Meinung, dass diese nicht relevant sind. Ausgaben und 
Kommandozeilen waren ebenfalls identisch, soweit verglichen.

Also nach einigem Versuchen, langem, langem Studium von SVN-Diffs und 
noch mehr Probieren ist der Fehler nun behoben... gefunden aber nicht. 
Mal wieder ein Fall von magischer Selbstheilung beim "Herumfummeln".

Geändert wurde:
- Update auf aktuelle WinAVR mit altem avr-objdump
- zig-mal kompiliert
- Änderung der Compile-Reihenfolge im Makefile
- und nichts in den Usart-Routinen.

Völlig unklar, woran es lag... anyway, es geht mal wieder...

cu, michael

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
Noch kein Account? Hier anmelden.