AVR mit >64kB Flash: Wie sag ich's meinem Linker?

[Bronco (Gast)]

Hallo zusammen,

ich hab mit AtmelStudio 7 ein Projekt für einen 644 entwickelt.
Da mir das RAM ausgeht, werde ich auf einen 1284 umstellen.
Das Extra an Flash brauche ich in absehbarer Zeit nicht.

Jetzt greife ich an verschiedenen Stellen auf Daten im Flash mittels 
"pgm_read_byte()" zu, welches nur die ersten 64kB adressieren kann.
Beim 644 kein Problem, aber nun hat der 1284 ja 128kB.

Ich könnte nun natürlich alle Zugriffe auf "pgm_read_byte_far()" 
umstellen, was ich aber wegen des Overheads vermeiden möchte.
Stattdessen würde ich lieber dem Linker sagen, dass Daten im Flash nur 
in die ersten 64kB legen soll, oder dem Linker sagen, dass er auf den 
Adressraum jenseits der ersten 64kB ganz verzichten soll.

Nun gibt es aber in AtmelStudio keine projektspezifischen Linkerskripte.

Wie gehe ich am sinnvollsten vor?

Danke!

[Falk B. (falk)]

Compilier deinen Code für den 644er und lad das Hexfile auf den 1284er, 
das könnte klappen, da sich beide ja nur in der Größe des Flash 
unterscheiden, nicht aber in den Registern etc.

[Falk B. (falk)]

Andererseits, wer sagt denn, daß der Linker die Daten am oberen 
Speicherrand ausrichtet? Wäre das nicht ein wenig unlogisch? Ich würde 
vermuten, daß auch beim 1284er die Daten langsam von unten an die 64kB 
Grenze ranwachsen. Also muss man gar nichts tun.

[Stefan E. (sternst)]

Bronco schrieb:
> Jetzt greife ich an verschiedenen Stellen auf Daten im Flash mittels
> "pgm_read_byte()" zu, welches nur die ersten 64kB adressieren kann.

Und legst die Daten im Flash mittels PROGMEM ab, oder?

Bronco schrieb:
> Ich könnte nun natürlich alle Zugriffe auf "pgm_read_byte_far()"
> umstellen, was ich aber wegen des Overheads vermeiden möchte.
> Stattdessen würde ich lieber dem Linker sagen, dass Daten im Flash nur
> in die ersten 64kB legen soll, oder dem Linker sagen, dass er auf den
> Adressraum jenseits der ersten 64kB ganz verzichten soll.

Brauchst du alles nicht. Die Daten liegen zwischen den Vektoren und dem 
Code. Du bekommst also erst Probleme, wenn diese Daten selber größer als 
64k werden.

[Felix F. (wiesel8)]

Bronco schrieb:
> Ich könnte nun natürlich alle Zugriffe auf "pgm_read_byte_far()"
> umstellen, was ich aber wegen des Overheads vermeiden möchte.
Oder du machst es sauber und verwendest einfach die Refactor-Funktion 
der IDE und änderst alle Aufrufe von "pgm_read_byte" mit nur einem Klick 
zu "pgm_read_byte_far"

mfg

[Johann L. (gjlayde)]

Stefan E. schrieb:
> Die Daten liegen zwischen den Vektoren und dem Code. Du bekommst also
> erst Probleme, wenn diese Daten selber größer als 64k werden.

Eine Möglichkeit, um das zu testen, ist den Wert von __ctors_start 
auszuwerten, z.B. so:

$ avr-nm foo.elf | grep __ctors_start
00000026 T __ctors_start

__ctors_start wird im standard Linker-Description-File definiert in 
einer Section, die fast direkt auf .progmem.data folgt, nämlich .ctors. 
Falls .jumptables und .lowtext leer sind, was üblicherweise der Fall 
ist, taucht __ctors_start als Test, ob .progmem nicht übergelaufen ist. 
nm gibt die Werte in hex aus, und man kann dann in einem Skript (z.B. sh 
in einem Makefile) testen, ob der Wert <= 10000 ist.

.progmem.* ist die Section, die für PROGMEM und __flash verwendet wird.

Eigentlich wär's ganz sinnig, wenn man Binutils anweisen könnte, die 
Situation anzuwarnen oder nen Fehler auszugeben...

[Jörg W. (dl8dtl) (Moderator)]

Felix F. schrieb:
> Oder du machst es sauber und verwendest einfach die Refactor-Funktion
> der IDE und änderst alle Aufrufe von "pgm_read_byte" mit nur einem Klick
> zu "pgm_read_byte_far"

Und das beseitigt den zusätzlichen Overhead der "far"-Funktion?

Glaub' ich nicht.