Hallo, ich entwickle momentan ein Programm auf einem Atmega 2560 mit 64 KB externem RAM. Das Speicherlayout entspricht Variante 2 von "Memory areas using malloc", d.h. das interne RAM ist nur für den Stack und .data, .bss und heap liegen vollständig im XRAM. Mein Problem ist nun, dass das Datasegment trotz Verwendung von PROGMEM/morepgmspace.h mittlerweile über die 8 KB Grenze hinausgeht. Ich erhalte dann ein out-of-range-warning (vgl. Anhang) und das Programm ist nicht mehr lauffähig. Mit Optimierung (-01, -0s) funktioniert es im Augenblick noch problemlos, das macht aber ziemliche Probleme beim Debuggen. Gibt es eine Möglichkeit, das .data-Segment auf mehr als 8Kb zu vergrößern? Die naheliegenden Variante (à la --defsym=__data_end=0x80XXXX in den LD-Flags) brachte leider nicht das gewünschte Ergebnis. Das von mir verwendete Linkerskript (vgl. Anhang) ist im Prinzip avr6.x mit weiteren Segementen und schon in avr6.x ist der Databereich defaultmäßig auf die theoretisch maximal mögliche Größe (0xffa0) gesetzt. Rein interessehalber: Liegen gcc/ld nicht schon zur Compile-/Linkzeit genügend Informationen vor, um .data entsprechend der tatsächlichen Größe anzupassen? Ich bin für jeden Hinweis dankbar. Johannes
Irgendwas ist da schräg, aber ich sehe wohl den Wald vor lauter Bäumen nicht. Der adressierbare RAM-Bereich ist bereits mit dem standardmäßigen Linkerscript 64 KiB (minus die intern benutzten Adressen natürlich). Ich habe auch schon genügend Programme mit externem RAM betrieben, allerdings nie an einem ATmega2560, sondern immer nur an einem ATmega128 oder ATmega1281. Kannst du ein abgespecktes Beispielprojekt zusammenstellen, mit dem man das reproduzieren kann?
Ich habe jetzt versucht, das Projekt so weit wie möglich auszudünnen und den Fehler trotzdem zu erhalten, was mir leider nicht vollständig gelungen ist, da ich mit dem attachten Code nur einen out-of-range-Fehler im .text-Segment reproduzieren kann, und dies nur durch die in lddemo.c sehr oft eingefügten Füllfunktionen. Ich weiß nicht, ob das .text-Problem nicht das eigentlich grundlegende Problem ist und das .data-Problem nur eine Folge davon. Ohne Optimierung übersetzt, bekomme ich den angehängten Output. Mit Optimierung (-Os) lässt sich wieder alles problemlos compilieren. Überraschenderweise compiliert es in der abgespeckten Version auch problemlos durch, wenn in select_twi_multiplexer_channel() die _delay_ms()-Funktion auskommentiert wird. Ich bin etwas ratlos...
Ein Out Of Range fehler von den bedingten Sprüngen kommen da diese nur +-63 Worte springen können. ( BR**) Hab mir den Code jetzt nicht angeschaut.
1 | ../lddemo.c:11:19: error: debug.h: No such file or directory |
2 | In file included from ../lddemo.c:13: |
3 | ../main_loop/main_statemachine.h:69:26: error: statemachine.h: No such file or directory |
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.