Probleme mit WINAVR-20070525

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.

> 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.

Nein, das darf nicht passieren, da muss irgendwas anderes faul sein.
Genau dafür sind die

1

_delay_*()

-Funktionen ja da, dass du nicht
irgendwas mit der Hand zusammenbasteln musst.

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.