mikrocontroller.net

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


Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht 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:
00000566 <_Z9usartInitv>:
}

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

Neu und geht nicht:
000007fc <_Z9usartInitv>:
     7fc:  e1 ec         ldi  r30, 0xC1  ; 193
     7fe:  f0 e0         ldi  r31, 0x00  ; 0
     800:  80 81         ld  r24, Z
     802:  88 61         ori  r24, 0x18  ; 24
     804:  80 83         st  Z, r24
     806:  60 e8         ldi  r22, 0x80  ; 128
     808:  75 e2         ldi  r23, 0x25  ; 37
     80a:  80 e0         ldi  r24, 0x00  ; 0
     80c:  90 e0         ldi  r25, 0x00  ; 0
     80e:  0e 94 e6 03   call  0x7cc  ; 0x7cc <_Z16usartSetBaudRatem>
     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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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. ;-)

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.