ext. SRAM benutzen

[Uwe Seidel (Gast)]

Hi

nachdem ich das nun nicht auf die Reihe krieg , frag ich mal um Hilfe.
so siehts aus:
ext SRAM Samsung K6T1008c2e; Addr. Latch 74HC373;
beides angeschlossen und elektr. geprüft.

Code:
#define SRAM __attribute__((section(".noinit")))
.
uint16_t la[4000] SRAM;
.
MCUCR |=(1<<SRE);
.
for(uint16_t i=0;i<4000;i++){la[i]=i;}
.
for(uint16_t i=0;i<4000;i++)
       printf("Platz : %5d Wert : %5d \n\r",i,la[i]);

Probleme:
-geht nicht :-) d.h. geht schon aber.....
-geht das auch anders ?
-der versuch :
EXTMEMOPTS = -Wl,-Tdata=0x801000,--defsym=__heap_end=0x80ffff
,-Wl,--change-section-address=.noinit=0x801100

führt ja zu:

Size after:
lader.elf  :
section     size      addr
.data          6   8392704
.text       4946         0
.bss           6   8392710
.noinit     8000   8392716
.eeprom        0   8454144
.stab       1572         0
.stabstr    2340         0
Total      16870

Errors: none
-------- end --------

sollte da nicht
.noinit     8000   8392960
stehen ? ist das nun im ext. ram oder wie versteh ich das?
Und wenn ja , wo genau. bei 0x801100 oder bei 0x80100C.

Kann mich bitte mal jemand aufklären.

Danke
Uwe Seidel

[Jörg Wunsch (Gast)]

1.) Ist die .noinit-Section denn wirklich, was Du willst?

2.) Klar geht das auch anders.  Einfach den externen RAM am
    Compiler vorbei gehen lassen und dann

    uint16_t *la = (uint16_t *)0x1000;

    setzen.

3.) Hast Du Dir das Kapitel über malloc() in der Doku
    durchgelesen?  Dort steht ein bißchen was über die
    Anordnung im Speicher drin.

Warum verschiebst Du eigentlich den Anfang von .data?  Wenn überhaupt,
siet mir 0x801000 ein bißchen daneben aus.  Das müßte doch (je nach
MCU) 0x800100 oder 0x800060 sein.

[Uwe Seidel (Gast)]

Hi,
danke erstmal.

zu 1.
ja , ist ein persönlicher Wunsch , die großen Datenarray´s im ext. RAM
abzulegen. Es sollten auch nur diese sein.
In der Doku steht noch , dass der Heap dort auch hin sollte, wenn ext.
RAM vorhanden , warum eigentlich ?

zu 2.
ja genau. aber noch was anderes nicht?

zu 3.
ja.

woher das .data verschieben kommt , ist mir jetzt echt ein Rätsel. Ist
mir garnicht aufgefallen. Hab das manuell gerichtet. Die "komische"
Adresse 0x801000 war mein Tippfehler, ist eine "0" weniger.

Jetzt:

.
.
Linking: lader.elf
avr-gcc -mmcu=atmega128 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=lader.o  -std=gnu99
-Wp,-M,-MP,-MT,lader.o,-MF,.dep/lader.elf.d lader.o    --output
lader.elf -Wl,-Map=lader.map,--cref
-Wl,--section-start=.noinit=0x801100    -lm

.
.
Size after:
lader.elf  :
section     size      addr
.data          0   8388864
.text        380         0
.noinit     8000   8392960  <--- AHA !
.bss           2   8388864
.eeprom        0   8454144
.stab       1572         0
.stabstr    2340         0
Total      12294

Errors: none
-------- end --------

Also ist die Adresse jetzt richtig.
Sieht wohl so aus, also ob ich den Wald vor lauter Bäumen nicht gesehen
hab.
Deswegen hab ich mich ja hierher gewandt...

Also dann mal DANKE
Uwe

[Jörg Wunsch (Gast)]

> ja , ist ein persönlicher Wunsch , die großen Datenarray´s im
> ext. RAM abzulegen. Es sollten auch nur diese sein.

OK.  .noinit ist ein Weg dafür, sicher gar nicht mal ein schlechter
(weil dafür schon alles ,,vorgekocht'' ist).

> aber noch was anderes nicht?

Es führen immer sehr viele Wege nach Rom, aber diese beiden sind
sicher die praktikabelsten, insofern würde ich jetzt keinen
Gehirnschmalz in was anderes stecken.