Xmega 16Mb Adressierung

[Nomis3000]

Ich hab da mal eine Frage:
Die XMEGA können ja durch die X/Y/Z-Pointer-Erweiterungsregister RAMPX/Y/Z 16Mb adressieren.
Aber weiß jemand von euch inwieweit das der GCC schon unterstützt?
Würden dann nicht alle Speicherzugriffe über Pointer langsamer ablaufen, weil jetzt drei statt zwei Pointerregister beladen werden müssen?

Wie läuft denn eigentlich der Flashzugriff bei den bisherigen AVRs mit beispielsweise 256kByte Programmspeicher ab? Dafür ist ein 16Bit Adressraum doch auch schon zu wenig.
Vor allem interessiert mich wie Programmsprünge mit diesen größeren Programmspeichern funktionieren.


Die aufklärende Seite in den Datenblättern hab ich zumindest noch nicht gefunden.
Edit: Gut, habs gefunden. Der Programcounter ist jetzt auch 3Bytes groß und ein Programmsprung dauert wegen den 3Bytes die auf den Stack gerettet werden müssen länger. Die GCC-Frage ist aber immer noch nicht geklärt.

 

[Dirk]

Hi Nomis,

Die XMEGA können ja durch die X/Y/Z-Pointer-Erweiterungsregister RAMPX/Y/Z 16Mb adressieren.
Aber weiß jemand von euch inwieweit das der GCC schon unterstützt?
Würden dann nicht alle Speicherzugriffe über Pointer langsamer ablaufen, weil jetzt drei statt zwei Pointerregister beladen werden müssen?

Da bin ich im Moment auch überfragt, ich müsste mal ins Datenblatt schauen. Wie das der GCC macht, weiss ich leider nicht.

Wie läuft denn eigentlich der Flashzugriff bei den bisherigen AVRs mit beispielsweise 256kByte Programmspeicher ab? Dafür ist ein 16Bit Adressraum doch auch schon zu wenig.
Vor allem interessiert mich wie Programmsprünge mit diesen größeren Programmspeichern funktionieren.

Der ProgramCounter pc hat bei den AVRs immer eine bestimmte Breite, die von der Größe des Programmspeichers abhängt, also zum Beispiel bei 256kByte AVRs (128kWord) sind das 17Bit.

Für die Adressierung eines Flashspeicherbereiches größer als 64k wird ja anstelle des LPM Instructions der ELPM verwendet, dieser nutzt das Z-Register (16Bit breit) und das Register RAMPZ, was die höherwertigen Adressbits beinhaltet. Theoretisch ist so ein 24bit Speicherbreich adressierbar. Die Anzahl der Bits in RAMPZ sind abhängig von der Größe des verwendeten Flashspeichers.

Analog zu ELPM erfolgen Sprünge im oberen Speicherbereich durch EICALL und EIJMP. Die Adressregister für die indirekte Adressierung sind hier Z (ZH, ZL) und EIND (Extended Index Register). Das Register EIND hat wieder die höherwertigen Adressbits und die sind wieder abhängig von der Flashgröße.

Grüße,
Dirk

 

[Nomis3000]

Für die Adressierung eines Flashspeicherbereiches größer als 64k wird ja anstelle des LPM Instructions der ELPM verwendet, dieser nutzt das Z-Register (16Bit breit) und das Register RAMPZ, was die höherwertigen Adressbits beinhaltet. Theoretisch ist so ein 24bit Speicherbreich adressierbar. Die Anzahl der Bits in RAMPZ sind abhängig von der Größe des verwendeten Flashspeichers.

Analog zu ELPM erfolgen Sprünge im oberen Speicherbereich durch EICALL und EIJMP. Die Adressregister für die indirekte Adressierung sind hier Z (ZH, ZL) und EIND (Extended Index Register). Das Register EIND hat wieder die höherwertigen Adressbits und die sind wieder abhängig von der Flashgröße.

Danke Dirk

Aber du kommst etwas zu spät, hab es schon in einem Datenblatt gefunden.
(siehe Edit von weiter oben)

Irgendwie hat mich die Frage wie ein Blitz getroffen. Ungeduldig wie ich bin, hab ich dann einen Thread erstellt ohne vorher richtig zu recherchieren.

Naja, so haben wenigstens alle etwas von deinem Wissen.

Das mit dem GCC würde mich schon interessieren. Ich meine, die pgm - Routinen unterstützen den erweiterten Adresszeiger. Aber wie sieht es mit dem sram aus?

 

[Dirk]

Da wir gerade bei Programmspeicheradressierung sind ...

Wenn ich Tebellen, Grafikdaten oder sonstige Daten im oberen Flashbereich habe, nutze ich ja in GCC die Far-Adressierung, also zum Beispiel pgm_read_byte_far. Kann man denn bei GCC irgendwie einstellen, dass Daten im Flash nur zum Beispiel im unteren Bereich liegen sollen. Das Problem ist einfach, wenn man ein Programm schreibt, ist es ja zu Begin noch klein, die Daten liegen dann ja eigentlich im unteren Bereich, irgendwann rutschen die aber über 64k und dann adressiert ja meine pgm_read_byte Routine falsch. Ich muss dann alles umschreiben Oder gibt es hier vielleicht ganz andere Lösungsmöglichkeiten?

Dirk

 

[Nomis3000]

Hi Dirk

Zu deinem Problem:
Ich habs dir sowieso schon ge-PM t aber hier nochmal für alle:
Man kann dem GCC mitteilen dass er Funktionen oder Daten in bestimmte Sektionen(speicherabschnitte), wie zum Beispiel die .initN (N=0..9) sections, schreibt.
Das geht indem man das Attribut section anwendet. Geschrieben etwa so:
__attribute__ ((section (".init3")));
Oder an einem Beispiel:
static char string2[] __attribute__ ((section (".init3"))) = "Dieser String würde noch vor der main-Funktion als Programmcode ausgeführt werden(nicht gut)";
Und ja! Ich weiß es ist Schwachsinn Daten in die init sections reinzuschreiben.

Man kann sich aber auch eigene Sections an beliebigen Speicherorten definieren, welche aber die vorhandenen sections nicht in ihrem Speicherbedarf verletzen dürfen.
Das heißt sie müssten hinten(vorne und zwischendrinn geht nicht) drann was du aber nicht gebrauchen kannst.
Trotzdem hier die Erklärung:
Man gibt dem Linker einfach folgende Zeile zu schlucken:
-Wl,--section-start=.nameVonSection=0xFFFF
Die Hex Zahl zum Schluss ist die Adresse wo der Code dann reincompiliert wird und .nameVonSection ist dann genauso wie im obrigen Besipiel mit ".init3" für Funktionen und Daten abrufbar.

Meine tests mit dem GCC unter Zuhilfenahme deines Hex-Editors(der vom mega128-USB-Board) haben aber gezeigt dass die mit PROGMEM(eigentlich auch nur eine section) deklarierten Variablen noch vor den init sectionen, direkt nach den Interrupttabellen im Flash abgelegt werden.

Also entweder du reißt dich zusammen und nimmst die längeren Pointer.
Oder du lässt dir von richtigen GCC-Gurus helfen(ich bin nur ein stümper).

 

[Dirk]

Hi Nomis,

Also entweder du reißt dich zusammen und nimmst die längeren Pointer.
Oder du lässt dir von richtigen GCC-Gurus helfen...

danke für deine Tipps. Also für mich ist es jetzt nicht soooo wichtig, ich werde mich erst einmal zusammenreißen und wenn nötig längere Pointer verwenden, bzw. über far adressieren.

Also Dnake nochmal für die Hilfe

Grüße,
Dirk