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:
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
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.
@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?
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. ;-)
@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)
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.
@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