ATmega2561 Problem mit WinAVR

Maik Scholz wrote:

>   C:/subver/homenet/sw/ethernut/nut/crt/vfprintf.c:65: warning: internal
>     error: out of range error
>   C:/subver/homenet/sw/ethernut/nut/crt/vfprintf.c:65: warning: internal
>     error: out of range error
>
> Was kann ich dagegen unternehmen?

Vielleicht als allererstes mal gucken, was da auf Zeile 65 steht?

Ich fürchte, Ethernut macht hier irgendwas, was man eher nicht tun
sollte.

Möglicherweise liegt es an der Übergabe eines Function pointers als 
Parameter. Dann hilft es evtl., wenn man im Makefile die LIBS Einträge 
anders anordnet.

Gunter Weisbrod wrote:

> Den 'internal error: out of range error' gibt es daher
> auch, wenn man eine ungerade(!) Anzahl Datenbytes im .text-Segment.
> Abhilfe: Daten im .progmem -Segment plazieren.

Ja klar.  Eine ungerade Anzahl von Datenbytes in .text ist schlicht
nicht zulässig.  Warum kommt man auch auf so'ne Idee?  Der Compiler
selbst macht das ja nicht...  Genau dafür ist ja progmem da, dort
kümmert sich der Linkerscript nötigenfalls um das Padding.  Der
zweite Vorteil ist, dass progmem immer vor dem eigentlichen text
platziert wird, damit es (nach Möglichkeit) unterhalb der 64-KiB-
Grenze landet, innerhalb derer man mit den diversen _P-Funktionen
auf die Flash-Daten zugreifen kann.  Oberhalb 64 KiB muss man dann
umständlich manuell mit den pgm_..._far()-Funktionen arbeiten.

Wenn der Compiler das nicht macht, wäre die Frage: Wie bekommt man das 
dann hin?

Wie viele Bytes im Text Segment sind, ist aber doch eigentlich 
belanglos. Wichtig ist lediglich, dass alle Elemente auf Wortgrenzen 
beginnen, oder?

Noch als Info: Nut/OS verwendet, wenn es für AVR gebaut wird, die Linker 
Skripts von avrlibc. Explizite .text Segmente werden nur für den 
ImageCraft Compiler definiert, beim avr-gcc beschränken wir uns auf 
pgmspace.h. Also kein Voodoo oder andere Tricks, bis auf die für's 
Multithreading nötigen Stack-Manipulationen. Die o.g. Routine ist 
übrigens klein:

 int vfprintf(FILE * stream, CONST char *fmt, va_list ap)
 {
   return _putf(_write, stream->iob_fd, fmt, ap);
 }

Als Problem vermutete ich, dass der erste Parameter, ein 
Funktionspointer auf die _write() Routine (ganz normale stdio _write 
Funktion, aber nicht aus avrlibc) das Problem verursacht.

Die Geschichte mit ungeraden Bytes im .text Segment hat mich jetzt 
irgendwie verunsichert. @Gunter: Woraus schließt Du das? Map File? Wenn 
ja, wleches Modul?

Harald Kipp wrote:

> Wenn der Compiler das nicht macht, wäre die Frage: Wie bekommt man das
> dann hin?

Der Compiler packt normalerweise nach .text nur generierten Code,
keine Konstanten.  Da beim AVR alle Befehle Vielfache von 16 Bits
lang sind, kann dabei immer nur eine gerade Zahl von Bytes
entstehen.

Wo ggf. die ungerade Zahl herkommt, musst du dir schon selbst
ansehen.  Die Vermutung liegt nahe, dass es irgendwie mit NutOS
zu tun haben könnte, denn ich habe ansonsten noch nie eine
derartige Fehlermeldung berichtet gehört.

> Die o.g. Routine ist
> übrigens klein:
>
>  int vfprintf(FILE * stream, CONST char *fmt, va_list ap)
>  {
>    return _putf(_write, stream->iob_fd, fmt, ap);
>  }

Das kann gut und gern schief gehen.  NutOS hat formal kein Recht,
Teile der normalen C-Bibliothek (mit den dort standardisierten
Namen) neu zu implementieren.  Der C-Standard verbietet dies
ausdrücklich und gibt gleichzeitig dem Compiler damit die Möglich-
keit, sein internes Wissen darüber, was die Funktionen der
Standardbibliothek machen, für Optimierungen zu nutzen.

Hallo Zusammen,

auch ich habe Probleme von ATmega128 auf 2561 zu gehen.
Mit Optimierungen (-Os/-O2) ist alles ok.

mit Optimierung (-O1) nicht mehr Warnings, aaaber Funktionspointereien 
scheinen schief zu gehen,

ohne Optimierung (-O0) plötzlich knapp 400 Warnings, z.B.:

(.text+0x4): warning: internal error: out of range error
c:/user/tools/winavr20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/li 
b/avr6\libc.a(sprintf.o):  In function `sprintf':

oder

menucfg.o:(.progmem.data+0x3d48): warning: internal error: out of range 
error

Eigentlich hatte ich ja gehofft, mit dem CPU-Wechsel mehr als 128k 
nutzen zu können, aber so einfach scheints ja nicht zu gehen.
Was gibts denn da als Lösung oder workaround?

CU
KäptnAhab