Var-Position im ext. SRAM

[Uwe Seidel (Gast)]

Hallo,

Ich hab nen ATmega128 und werde 64kb ext. SRAM anschließen.
Im externen SRAM will ich recht große Tabellen abspeichern und halten,
auch wenn der AVR nen /RESET macht. Alle anderen Variablen sollten
schon um int.SRAM stehen.
Ich weiß, dass ich mit -Wl,-Tdata,addr dem Compiler die Startadr.
übergeben kann.
Aber ich will ja nur einzelne Variablen , wenn auch recht große, im
ext. SRAM speichern.

geht das irgendwie mit etwas ähnlichem wie:
<idee>
.org 0x1000
uint16_t kurve1[500];
uint16_t kurve2[500];
</idee>

Danke schon mal.
Uwe

[Joerg Wunsch (Gast)]

Nein.

.org ist tabu, wenn man mit verschieblichen Objekten und einem Linker
arbeitet.  Die Absolutpositionen sollen ja erst vom Linker errechnet
werden.

Die .noinit section ist das, was Du suchst.  Ist in der Doku ein wenig
beschrieben, deren Adresse kannst Du mit

-Wl,--change-section-address=.noinit=0x801100

(oder so ähnlich ;-) setzen.

Denk aber dran, daß Du den RAM irgendwann mal initialisieren mußt, bei
.noinit macht das niemand mehr für Dich.  Dazu mußt Du die Flags in
MCUCSR auswerten.  Die muß man übrigens manuell rücksetzen.

Außerdem darfst Du dann natürlich keine Beschaltung an /RESET haben,
die beim Power-On zusätzlich zum Power-On-Reset noch einen externen
Reset macht, ansonsten kannst Du beide nicht mehr unterscheiden.

[Matthias (Gast)]

Hi

ich mach was ähnliches mit einem Mega8515. Da erfolgt der Zugriff nur
über Pointer. Geht auch.

Matthias

[Uwe Seidel (Gast)]

@Joerg
das .org tabu ist, weiß ich auch :-)
habs nur geschrieben , weil es genau das macht, was ich will, nur halt
in asm.

> -Wl,--change-section-address=.noinit=0x801100
hab ich auch gelesen (mittlerweile lese ich ja auch die Dateien auf
meiner Festplatte ;-) ), ich hab das aber so interpretiert, dass dann
ALLE Variablen ab der angegebenen Adresse liegen. Dies wäre ja  doof.
Bin ich da irre ?
Kann der Linker selbstständig die Position von großen Variablen in den
ext. Ram entscheiden, oder nach welchen Kriterien geht das? Dann wäre
ja die Frage, ab welcher Größe und wieviel Platz für den Stack gelassen
wird.
ist mir irgendwie nicht recht klar, was da passiert.

@Matthias

Zugriff über Pointer ist sowieso die einzig vernünftige Möglichkeit für
große Datenmengen.
Aber wie hast du die Daten explizit im externen RAM angelegt?

Ach übrigens, ich war auf deiner Seite und hab mir mal eagle3D gezogen.
hat auch gefunzt. Allergings suche ich die lib für DEN
USB<>RS232-Konverter FT232BM. Kann ich dafür irgendwas anderes
einsetzen?

Danke erstmal an euch beide

Uwe

[Matthias (Gast)]

Hi

>Zugriff über Pointer ist sowieso die einzig
>vernünftige Möglichkeit für große Datenmengen.

Arrays sind mir aber manchmal lieber. Ist aber ja eingentlich nichts
anderes als eine andere Schreibweise für Pointer.

>Aber wie hast du die Daten explizit im externen RAM angelegt?

So:

unsigned int * sample;
sample=(unsigned int *)0x8000;

Dann zeigt der Pointer auf die Adresse 0x8000 (A15=1 [A14..A0]=0)

Den Rest findest du dann in jedem guten Buch welches die
Programmiersprache C behandelt.

>Allergings suche ich die lib für DEN
>USB<>RS232-Konverter FT232BM. Kann ich dafür
>irgendwas anderes einsetzen?

verwende QFP_TQFP_32_080MM. Zuzuordnen über die manuelle Zuordnung oder
dauerhaft über die 3dusrpac.dat

Matthias

[Uwe Seidel (Gast)]

Aha,

das mit dem FT232BM hat mal funktioniert. Gibts auch ne passende
USB-printbuchse? :-)

Die Sache mit dem Pointer hätte ich sooo einfach garnicht erwartet.
Manchmal denkt man echt zu "krumm".
Aber mein Problem löst das noch nicht so richtig. Die Sache mit dem
array wäre ja auch noch ne möglichkeit, aber das krieg ich ja immernoch
nicht nach ext.SRAM weil ich nicht weiß wie es geht.

hmmmm. mal weitersuchen.

Danke erstmal.
Uwe

[Matthias (Gast)]

Hi

>das mit dem FT232BM hat mal funktioniert. Gibts auch
>ne passende USB-printbuchse? :-)

Nein. Aber lass dich nicht aufhalten eine zu erstellen.

Wieso lößt das dein Problem nicht. Wie ich schrieb ist ein Array nur
eine andere Schreibweise für Pointerzugriffe.

sample[400]=0x1234;

ist equvivalent zu

*(sample+400)=0x1234;

Matthias

[Joerg Wunsch (Gast)]

> das .org tabu ist, weiß ich auch :-) habs nur geschrieben , weil es
> genau das macht, was ich will, nur halt in asm.

Ist auch in Assembler tabu, wenn man anschließend einen Linker
benutzt.  Hat nur für Absolutassembler Sinn, und die hat man selbst
vor 15 Jahren zum Linken eine CP/M-BIOS schon nicht mehr benutzt. ;-)
Der Ansatz verschieblicher Objektmodule, die erst vom Linker
zusammengefügt werden (so daß erst dieser die Absolutpositionen
kennt), ist halt flexibler.

>> -Wl,--change-section-address=.noinit=0x801100

> hab ich auch gelesen (mittlerweile lese ich ja auch die Dateien auf
> meiner Festplatte ;-) ), ich hab das aber so interpretiert, dass
> dann ALLE Variablen ab der angegebenen Adresse liegen.

Nein, nur die Variablen der section ".noinit".  In diese section
mußt
Du Deine Variablen explizit hineinbefördern:

uint8_t largearray[32768] __attribute__((section(".noinit")));

Daher ja auch die etwas kompliziertere Schreibweise in den
Linkeroptionen.  Alle normalen Variablen bleiben in den sections .data
bzw. .bss.  Die Schreibweise

-Wl,-Tdata=0x8011000

ist nur eine Kurzform für

-Wl,--change-section-address=.data=0x8011000

Die letztgenannte Form läßt sich dafür für beliebige sections
benutzen, während die -T Variante nur für die drei Standard-sections
(.text, .data, .bss) geht.

[Uwe Seidel (Gast)]

HA

jetzt hab ich es verstanden....
glaub ich .

DAAAANKEEEEE

damit werd ich jetzt mal ein wenig experimentieren.

@Matthias
zum Thema USB-Buchse. ich werd mir das mal ansehen.
Wenn meine Probleme beseitigt sind, schau ich mir diese 3D-Sache mal
genauer an.

auch Dir natürlich DAAAANKEEE
für die Hilfe.
Uwe