mikrocontroller.net

Forum: Compiler & IDEs Probleme mit WINAVR-20070525


Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen

Ich habe mit dem 2006er Compiler aus einem Programm ein hex-File erzeugt 
und dabei folgendes erhalten

...

Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep

...

>Process Exit Code: 0
...


Das war alles super und hat auf anhieb funktioniert.


Als ich das selbe Projekt... wirklich nichts verändert ... mit dem 
Winavr-20070525 compiliert habe, stand da folgendes:

Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
  --change-section-lma .eeprom=0 -O ihex main.elf main.eep
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be 
copied!
c:\WinAVR-20070525\bin\avr-objcopy.exe: --change-section-lma 
.eeprom=0x00000000 never used
make.exe: [main.eep] Error 1 (ignored)

...

>Process Exit Code: 0
...


Erstmal nicht schlimm dachte ich,da ja ">Process Exit Code: 0", aber das 
Programm verhielt sich anders. Der MCP2515, den ich über die SPI 
ansprach, will plötzlich nicht mehr mit dem Atmel reden. Was kann ich 
tun? Was sagt mir diese Fehlermeldung?

Danke

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

Bewertung
0 lesenswert
nicht lesenswert
Die Fehlermeldung besagt, dass dir die aktuellen binutils nicht mehr
gewillt sind, eine leere EEPROM-Ladedatei anzlegen.  Das ist aber
komplett harmlos, wenn du keine EEPROM-Daten hast, wird dich die
leere Datei ja ohnehin nicht interessieren.  (Wenn du welche gehabt
hättest, gäbe es keine Fehlermeldung.)

Dein Problem muss also komplett andere Ursachen haben, die du einfach
mal analysieren musst.

Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, hilft mir jetzt zwar nicht weiter, aber da muss ich wohl durch. 
Auf den 2006er ausweichen, will ich auch nicht. Muss ja irgendwie gehen. 
:-)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> make.exe: [main.eep] Error 1 (ignored)

Zeigt, dass die neuen Tools den Fehler "EEPROM leer" ignoriert haben. 
Das ist eine Einstellung im Makefile (- vor dem avr-objcopy Kommando). 
Das ist sicher nicht die Ursache für die unterschiedliche Funktion.

Der wesentliche Unterschied alter WinAVR <-> neuer WinAVR (2007) ist die 
sehr erweiterte Optimierung des moderneren GCC. Ein typ. Fall ist z.B. 
das ersatzlose Streichen von Leerschleifen, die manche Leute gerne als 
Ersatz für die Wartefunktionen (_delay_ms,...) benutzt hatten.

Vielleicht kannst du die Funktionsabweichung im Sourcecode genauer 
lokalisieren und magst den Abschnitt (oder ganz) posten. Wenn nicht - 
mal auf die Schleifen und bewusstes Nixmachen achten.

Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-) Mein grinsen geht von einem Ohr zum Anderen. Vor 1min bin ich der 
Sache auf die Schliche gekommen. Dann wollte ich euch sagen, was es war 
und BUMMS da hat doch der Stefan das ganze schon vermutet :-).

Es war wirklich die delay-Funktion aus der util/delay.h. Der Aufruf 
"_delay_us(XX);" wurde übergangen bzw. wegotimiert und damit hat die SPI 
den MCP2515 nicht lange genug Zeit gelassen, den Config.Mode zu 
betreten. Ich habe es nun wieder mit einer for-Schleife und einer 
wiederkehrenden Addition darin gemacht -  wie sonst auch... nur jetzt 
mußte ich alles mit volatile abändern. Nu geht's.

Ich finde es schade. Als ich den Quellcode gelesen habe, fand ich es 
interessant, dass es eine Funktion gibt, die ja anscheinend eine 
definierte Pause erzeugt. Und nun optimiert die sich weg...hmmm... . Der 
Herbert hat dazu die passende Frage..."Huuuuu, was soll das?" :-)

Bis dann

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

Bewertung
0 lesenswert
nicht lesenswert
Nein, das darf nicht passieren, da muss irgendwas anderes faul sein.
Genau dafür sind die
_delay_*()
-Funktionen ja da, dass du nicht
irgendwas mit der Hand zusammenbasteln musst.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg:
> da muss irgendwas anderes faul sein.

Sehe ich genau so. Aber schon mal gut, dass die Ursache eingegrenzt 
werden konnte!

Marco:
> Der Aufruf "_delay_us(XX);" wurde übergangen bzw. wegotimiert
> und damit hat die SPI den MCP2515 nicht lange genug Zeit
> gelassen, den Config.Mode zu betreten.

Vielleicht ist das eine Tückung. Die delay... Funktionen werden als 
Inline-Funktionen direkt in den Hauptcode eingebaut. Dadurch sieht man 
im Debugger keinen üblichen Funktionsaufruf.

Die korrekte Zeit der delay... Funktionen ist von VIER Sachen 
abhängig:

1/ Die F_CPU muss richtig definiert sein. Wenn keine F_CPU definiert 
ist, schmeisst delay.h eine Warnung und definiert sich F_CPU auf 1MHz. 
Die Schleifen sind sehr zu lang (nicht dein Fall).

2/ Die Zeiten in den Schleifen müssen unterhalb eines F_CPU abhängigen 
Maximalwerts liegen. Liegt die Zeit darüber gibt es durch Überläufe 
seltsame Effekte. Das Timing wird nicht stimmen.

3/ Die Übersetzung muss mit einer Optimierung gemacht werden. Ohne 
Optimierung stimmt das Timing auch nicht.

ADD:
4/ Der Funktionsparameter für die delay... muss zur Compilezeit eine 
Konstante sein. Es darf kein erst zur Laufzeit bekannter Variableninhalt 
sein.

Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen alle zusammen

Ich habe gerade eure Kommentare gelesen und denke mir, das ich mich mit 
der delay.h mal genauer befassen müsste. Ich mag meine "handgebastelte" 
Pause nähmlich garnicht. Und wenn Ihr der Meinung seit, dass die delay.h 
funktionieren müsste, dann wird sie das wohl auch. Ich mach mich schlau. 
Danke Euch.

PS: Liegt beim  Compiler eigentlich irgendwie eine Zusmmenfassung der 
mitgelieferten Funktionen ... wie die besagte delay.h ... dabei und 
unter Umständen mit Beispielaufrufen? Ich werde oft das Gefühl nicht 
los, dass ich mir das Leben mit dem AVR nur unnötig schwer mache, weil 
ich die Möglichkeiten des AVR GCC nicht nutze.

Bis dann
Marco

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Verzeichnis

WinAVR\doc\avr-libc

findest Du u.a. ein komplettes pdf.-Manual für die Bibliotheksfunktionen

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.