STM32F4 GCC Linker section nur global?

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Howdy!

Ich habe an meinem F4 einen SDRAM angeschlossen und möchte nun, der 
Übersichtlichkeit wegen, auf Arrays darin direkt über definierte 
Variablen zugreifen. Dazu sehe ich (Anfänger) momentan zwei 
Möglichkeiten:

1. Pointer auf eine Adresse im SDRam erstellen und (für mich) 
unangenehme Akrobatik betreiben.

2. Folgendermaßen:
Im Linkerscript:

SDRAM (RWX)       : ORIGIN = 0xD0000000, LENGTH = 8M

und

  .sdram (NOLOAD) :
  {
      . = ALIGN(4);

    *(.sdram)
    *(.sdram.*)

    . = ALIGN(4);
  } > SDRAM

Ein Define:

#define SDRAM (__attribute__((section(".sdram"))))

Und dann Variable initialisieren und damit spielen:

SDRAM char bufbuf[100] = { 0 };
for (volatile int i = 0; i < 100; i++)
{
    bufbuf[i] = i;
    if(bufbuf[i] != i)
        i = 42;
}

Das einzig doofe ist, dass "attribute section" anscheinend nur global 
benutzt werden darf, "because of the way linkers work".
Habt ihr einen Trick auf Lager?


Danke schonmal!
Grüße
Reggie

[Tassilo H. (tassilo_h)]

Reginald L. schrieb:
>
> Das einzig doofe ist, dass "attribute section" anscheinend nur global
> benutzt werden darf, "because of the way linkers work".
> Habt ihr einen Trick auf Lager?
>

Naja, lokale Variablen sind per default automatisch und landen auf dem 
Stack. Den kannst du per Linkerscript und/oder startup-code hinlegen wo 
du willst, aber halt nur komplett, C kennt halt nur einen Stack.

Du kannst aber wohl innerhalb von Funktionen static-Variablen anlegen, 
fuer die geht dann auch ein "attribute section" (aber sie leben halt 
dauerhaft und belegen auch dauerhaft Speicher).

static SDRAM char localbuf[42];

[Manuel W. (multisync)]

Warum legst du nicht einfach die ganze .data section über das linker 
script in deinen SDRAM?

*(.data*)

  .sdram (NOLOAD) :
  {
    . = ALIGN(4);
    *(.data*)
    . = ALIGN(4);
  } > SDRAM

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Tassilo H. schrieb:
> Du kannst aber wohl innerhalb von Funktionen static-Variablen anlegen,
> fuer die geht dann auch ein "attribute section" (aber sie leben halt
> dauerhaft und belegen auch dauerhaft Speicher).
Das hilft mir eigentlich schon weiter, werde morgen gleich ausprobieren, 
danke!

Manuel W. schrieb:
> Warum legst du nicht einfach die ganze .data section über das linker
> script in deinen SDRAM?
Da dürfen in meinem Fall nur bestimmte Puffer rein. Andere Variablen und 
Puffer liegen im ccm und Backup.

[Nop (Gast)]

Du kannst auch globale Variablen mit static anlegen. Die "leben" dann 
nur innerhalb der C-Datei, in denen sie deklariert werden. Also wenn 
function static nicht ausreicht.

Das mit den Pointern laß mal lieber, denn dann müßtest Du das gesamte 
SDRAM so behandeln, könntest also den C-Linker dort überhaupt nichts 
hinlinken lassen. Wahrscheinlich gerietest Du damit dann auch früher 
oder später in Probleme mit pointer aliasing.

Das mit den Sektions-Attributen per define mache ich auf Cortex M4 auch 
so, weil CCM und restliches SRAM nicht am Stück sind, ich also selber 
entscheiden muß, was wohin gehen soll.

Paß übrigens auf mit der Initialisierung. Wenn Du vorinitialisierte 
Arrays willst, dann gibt es zwei Optionen:

a) sie sollen mit 0 initialisiert sein. Das ist noch einfach, dazu mußt 
Du bloß Dein SDRAM ausnullen. Geht natürlich erst nach der 
System-Initialisierung, weil der FSMC dafür ja schon konfiguriert sein 
muß.

Das kannst Du auch gleich mit einem Speichertest verbinden, der 
besonders bei externem RAM anzuraten ist. Ist aber nicht ganz trivial, 
wenn Du das richtig haben willst.

b) sie sollen mit anderen Werten initialisiert sein. Das kannst Du am 
einfachsten in einer C-Routine machen.

Und bedenke, daß Zugriffe auf das SDRAM um einen Faktor von ungefähr 8 
langsamer sind als das interne SRAM oder CCM. Leg also keine Variablen 
ins SDRAM, die Du extrem oft brauchst.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Nop schrieb:
> Das mit den Pointern laß mal lieber, denn dann müßtest Du das gesamte
> SDRAM so behandeln, könntest also den C-Linker dort überhaupt nichts
> hinlinken lassen. Wahrscheinlich gerietest Du damit dann auch früher
> oder später in Probleme mit pointer aliasing.
Ja, so hatte ich das bisher. So macht das coden nicht wirklich Spaß.

Nop schrieb:
> Paß übrigens auf mit der Initialisierung.
Das habe ich gerade gemerkt. Mit der obigen "Initialisierung" wird wohl 
nur die Variable deklariert, initialisiert wird da laut Memory-Viewer 
nicht mit 0.

Nop schrieb:
> Das kannst Du auch gleich mit einem Speichertest verbinden, der
> besonders bei externem RAM anzuraten ist. Ist aber nicht ganz trivial,
> wenn Du das richtig haben willst.
Genau, das habe ich bisher auch so gemacht, erst den Speicher komplett 
mit i + 1 beschreiben und dann komplett mit i + 1 lesen. Wie man so 
einen RAM "normgerecht" prüft, bin ich gerade dabei mich einzulesen.

Nop schrieb:
> Und bedenke, daß Zugriffe auf das SDRAM um einen Faktor von ungefähr 8
> langsamer sind als das interne SRAM oder CCM. Leg also keine Variablen
> ins SDRAM, die Du extrem oft brauchst.
OK, also, dass der SDRAM langsamer als der SRAM ist, leuchtet mir ein. 
Erstens läuft er beim STM32 mit maximal HCLK / 2 und zweitens ist es bei 
mir auch noch ein 16bit Speicher.
Aber warum soll der CCM langsamer sein? In welchem Datasheet finde ich 
das entsprechende Kapitel? Habe mir gerade das Datasheet, Programming 
und Reference Manual durchgeschaut und nichts dazu gefunden. Ich konnte 
lediglich herauslesen, dass der SRAM mit 0 waitstates angesprochen wird.
Hast du auch einen Verweis zu den D- und I-Bussen in peto?


Danke!

EDIT:
Achja und sehe ich das richtig, dass es ansonsten keine Möglichkeit gibt 
Variablen benutzerfreundlicher auf den verschiedenen Memorys zu 
verteilen? Ich muss mit den oben erwähnten Einschränkungen leben?

[rmu (Gast)]

Reginald L. schrieb:
> Achja und sehe ich das richtig, dass es ansonsten keine Möglichkeit gibt
> Variablen benutzerfreundlicher auf den verschiedenen Memorys zu
> verteilen? Ich muss mit den oben erwähnten Einschränkungen leben?

Für dynamisches Zeug gäbs das Konzept eines Zonen-Allokators. Da könnte 
man dann eine "schnelle" Zone dem internen SRAM zordnen, und eine 
"langsame" dem externen.

Ob das in Summe benutzerfreundlicher als das Präprozessor-Makro ist 
liegt im Auge des Benutzers :-).

[Niklas G. (erlkoenig)]

Du könntest deine malloc (_sbrk) Implementierung so bauen, dass sie 
Pointer auf den SDRAM zurückliefert. Dann kannst du malloc/new normal 
benutzen. Große lokale Variablen sind selbst auf dem PC gefährlich, 
daher lässt sich so doch recht "normal" programmieren.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Mhhh schade. Von dynamischen variable verabschiede ich mich gerade

[Tassilo H. (tassilo_h)]

Reginald L. schrieb:
> Achja und sehe ich das richtig, dass es ansonsten keine Möglichkeit gibt
> Variablen benutzerfreundlicher auf den verschiedenen Memorys zu
> verteilen? Ich muss mit den oben erwähnten Einschränkungen leben?

Nein, du kannst auch Variablen in deiner SDRAM section initialisieren.
Im Linkerfile brauchst du zwei sections fuers SDRAM. Eine muss mit 
NOLOAD gekennzeichnet werden. Hierhin kommen alle Variablen, die 
nicht/mit 0 initialisiert werden sollen. Die andere ist dann fuer 
Variablen, die ungleich 0 initialisiert werden (d.h. wo der Linker einen 
Speicherbereich im ROM mit den Initialisierungsdaten anlegen soll).

Im Startup-code, sobald das SDRAM-Interface konfiguriert ist, musst Du 
dann entsprechend eine Routine hinzufuegen, die den NOLOAD-SDRAM-Bereich 
ausnullt, und eine zweite, die die Initialisierungsdaten in den zweiten 
SDRAM-Bereich kopiert.

Dann ist es fast so komfortabel wie mit Variablen im normalen RAM, nur 
mit dem Unterschied, daß der Linker die initialisierten und nicht 
initialiserten/genullten Variablen im SDRAM nicht automatisch auf die 
beiden Bereiche aufteilt, sondern daß man das selber mit passenden 
section attributes machen muß.

[Tassilo H. (tassilo_h)]

Ach ja, hier der Auszug aus meinem Linkerfile, wo ich das fuers CCM 
gemacht habe. So aehnlich sollte das auch fuers SDRAM gehen (nur die 
Initialisierung muss vmtl. irgendwo in die Main, nachdem das SDRAM 
konfiguriert ist.

OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* Internal Memory Map*/
MEMORY
{
/* Uncomment as needed depending on debug build or build with bootloader */
/*  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x00078000*/
  rom (rx)  : ORIGIN = 0x08008000, LENGTH = 0x00078000
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00020000
  ccm (rwx) : ORIGIN = 0x10000000, LENGTH = 0x00010000
  bkpsram (rw) : ORIGIN = 0x40024000, LENGTH = 0x00001000
}

_eram = 0x20000000 + 0x00020000;
SECTIONS
{
  .text :
  {
  _usedromstart = .;
    KEEP(*(.isr_vector))
    *(.text*)
    *(.rodata*)
  } > rom 
  
  .ARM.exidx : 
  {
    __exidx_start = .;
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    __exidx_end = .;
  } > rom
  
  __etext = .;
  /* _sidata is used in coide startup code */
  _sidata = __etext;
  .data : AT (__etext)
  {
    __data_start__ = .;
    /* _sdata is used in coide startup code */
    _sdata = __data_start__;
    
    *(vtable)
    *(.data*)
    . = ALIGN(4);
    /* All data end */
    __data_end__ = .;
    /* _edata is used in coide startup code */
    _edata = __data_end__;
  } > ram 
  /* _siccmdata is used in startup code to init vars in ccm */
  _siccmdata = __etext + SIZEOF (.data);
  .ccmdata : AT ( _siccmdata )
  {
    _sccmdata = .;
    *(.ccmdata*)
    . = ALIGN(4);
    /* All data end */
    _eccmdata = .;
  } > ccm
  _usedromend = _siccmdata + SIZEOF (.ccmdata);
  .bss :
  {
    . = ALIGN(4);
    __bss_start__ = .;
    _sbss = __bss_start__;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
    _ebss = __bss_end__;
    __ram_end__ = ABSOLUTE(.);
  } > ram 
  .ccmbss (NOLOAD) :
  {
    . = ALIGN(4);
    _sccmbss = .;
    *(.ccmbss*)
    . = ALIGN(4);
    _eccmbss = .;
  } > ccm
  .bkpsram (NOLOAD) :
  {
    *(.bkpsram*)
  } > bkpsram
    
/*  .heap (COPY):
  {
    __end__ = .;
    _end = __end__;
    end = __end__;
    *(.heap*)
    __HeapLimit = .;
  } > ram 
  */
  /* .stack_dummy section doesn't contains any symbols. It is only
  * used for linker to calculate size of stack sections, and assign
  * values to stack symbols later */
  .co_stack (NOLOAD):
  {
    . = ALIGN(8);
    __StackBottom = ABSOLUTE(.);
    *(.co_stack .co_stack.*)
  } > ccm 
  
  /* Set stack top to end of ram , and stack limit move down by
  * size of stack_dummy section */
  __StackTop = ORIGIN(ccm ) + LENGTH(ccm );
  /*__StackLimit = __StackTop - SIZEOF(.co_stack);*/
  PROVIDE(__Stack = __StackTop);
  
  /* Check if data + heap + stack exceeds ram  limit */
  /*ASSERT(__StackLimit >= __HeapLimit, "region ram  overflowed with stack")*/
  ASSERT(__StackTop - __StackBottom >= __StackSize, "Not enough room for stack in CCM")
}

und der Startupcode dazu:

/*----------Symbols defined in linker script----------------------------------*/
extern unsigned long _sidata;    /*!< Start address for the initialization
                                      values of the .data section.            */
extern unsigned long _sdata;     /*!< Start address for the .data section     */
extern unsigned long _edata;     /*!< End address for the .data section       */
extern unsigned long _sbss;      /*!< Start address for the .bss section      */
extern unsigned long _ebss;      /*!< End address for the .bss section        */
extern void _eram;               /*!< End address for ram                     */

extern unsigned long _siccmdata;    /*!< Start address for the initialization
                                      values of the .data section.            */
extern unsigned long _sccmdata;     /*!< Start address for the .data section     */
extern unsigned long _eccmdata;     /*!< End address for the .data section       */
extern unsigned long _sccmbss;      /*!< Start address for the .bss section      */
extern unsigned long _eccmbss;      /*!< End address for the .bss section        */



/*----------Function prototypes-----------------------------------------------*/
extern int main(void);           /*!< The entry point for the application.    */
//extern void SystemInit(void);    /*!< Setup the microcontroller system(CMSIS) */
void Default_Reset_Handler(void);   /*!< Default reset handler                */
static void Default_Handler(void);  /*!< Default exception handler            */

extern unsigned int __Stack;

// vector table removed
//...
//


/**
  * @brief  This is the code that gets called when the processor first
  *         starts execution following a reset event. Only the absolutely
  *         necessary set is performed, after which the application
  *         supplied main() routine is called.
  * @param  None
  * @retval None
  */
void Default_Reset_Handler(void)
{
  /* Initialize data and bss */
  unsigned long *pulSrc, *pulDest;

  /* Copy the data segment initializers from flash to SRAM */
  pulSrc = &_sidata;

  for(pulDest = &_sdata; pulDest < &_edata; )
  {
    *(pulDest++) = *(pulSrc++);
  }

  /* Copy the .ccmdata segment initializers from flash to SRAM */
  pulSrc = &_siccmdata;

  for(pulDest = &_sccmdata; pulDest < &_eccmdata; )
  {
    *(pulDest++) = *(pulSrc++);
  }
  
  /* Zero fill the bss segment.  This is done with inline assembly since this
     will clear the value of pulDest if it is not kept in a register. */
  __asm("  ldr     r0, =_sbss\n"
        "  ldr     r1, =_ebss\n"
        "  mov     r2, #0\n"
        "  .thumb_func\n"
        "zero_loop:\n"
        "    cmp     r0, r1\n"
        "    it      lt\n"
        "    strlt   r2, [r0], #4\n"
        "    blt     zero_loop"::: "r0","r1","r2","cc","memory");
  /* Zero fill the .ccmbss segment.  */
  __asm("  ldr     r0, =_sccmbss\n"
        "  ldr     r1, =_eccmbss\n"
        "  mov     r2, #0\n"
        "  .thumb_func\n"
        "zero_loop2:\n"
        "    cmp     r0, r1\n"
        "    it      lt\n"
        "    strlt   r2, [r0], #4\n"
        "    blt     zero_loop2"::: "r0","r1","r2","cc","memory");
#ifdef __FPU_USED
  /* Enable FPU.*/ 
  __asm("  LDR.W R0, =0xE000ED88\n"
        "  LDR R1, [R0]\n"
        "  ORR R1, R1, #(0xF << 20)\n"
        "  STR R1, [R0]");
#endif  

  /* Call the application's entry point.*/
  main();
}

und schliesslich noch die Makros dazu

// defines to move global variables to core coupled memory
// use _CCM for uninitialized variables
#define _CCM  __attribute__((section (".ccmbss")))
// use _CCMDATA for initialized variables
#define _CCMDATA  __attribute__((section (".ccmdata")))
// use this for uninitialized variables in backup sram
#define _BKPSRAM  __attribute__((section (".bkpsram")))

Und als Beispiel:

static _CCM char c;
static _CCMDATA int[3] = {1,2,3};

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Was ich nicht so recht blicke, warum der linker hier nur statics 
akzeptiert. Im Prinzip sind das doch alles irgendwelche Speicheradressen 
die der Linker sieht. Wenn ich bestimmte Variablen in bestimmte 
Speicherbereiche schieben möchte, ist mir klar, dass ich ihm das 
gesondert sagen muss, da er sonst den voreingestellten Speicherbereich 
nimmt und die Variablen dort anordnert.
Warum kann ich dem Linker nicht mitteilen: Nimm Variable x und y und 
platziere sie so wie du sie auch sonst platzieren würdest, mit der 
Ausnahme, dass du diesmal nicht zwischen 0x00 und 0xAA sondern zwischen 
0xAB und 0xFF platzierst.

Ich schaffe erst seit kurzem mit dem linker script, bin also noch grün 
hinter den Ohren :>

[Tassilo H. (tassilo_h)]

Also, du kannst
* globale Variablen (also ausserhalb einer Funktion, die Angabe von 
static beeinflusst hier nur die Sichbarkeit in anderen Quellcodedateien) 
sowie
* static-Variablen innerhalb von Funktionen (die static-Angabe aendert 
hier nicht die Sichtbarkeit, sondern erzeugt eine Variable, die 
daherhaft existiert)
mit einem section-Attribut versehen, aber NICHT automatische Variablen 
innerhalb von Funktionen.

Das liegt daran, dass Speicher für die automatischen Variablen beim 
Funktionsaufruf auf dem Stack reserviert und beim Ruecksprung wieder 
freigegeben werden. Die Adresse wird also erst beim Funktionsaufruf 
festegelegt. Es kann die gleiche Variable auch mehrfach auf dem Stack 
geben, wenn sich die Funktion rekursiv selber aufruft - jeder Aufruf 
erzeugt einen neuen Satz der automatischen Variablen der Funktion (NICHt 
aber der static-Variablen, das sind dieselben fuer alle Aufrufe). Die 
Variablen belegen nur solange Speicher, solange die Funktion laueft.

Nun gibt es aber in C nur einen Stack (und die meisten Prozessoren haben 
auch nur einen Stackpointer). Wo der liegt, kannst Du aendern, 
allerdings waere das SDRAM ein schlechter Platz, da es langsamer ist als 
die anderen RAM-Bereiche. Insofern liegt bei automatischen Variablen 
ganz von selber fest, in welchem RAM-Bereich sie landen, naemlich dort 
wo der STack ist.

Leider ist es auch so, dass mit einem section-Attribut die Automatik, 
die entscheidet, ob eine Variable initialisiert ist oder nicht und 
danach die section aussucht (bss oder data) ausser Gefecht gesetzt wird, 
so dass man dafuer von Hand die richtige section setzen muss.

Wenn Du die Variablen im SDRAM, aber nicht global oder static haben 
willst, koenntest Du den Heap ins SDRAM legen und die Variablen dann 
dynamisch reservieren. Allerdings ist ein Heap oft auf einem 
embedded-System ueberfluessig; die größten Speicherbrocken, die man 
braucht, sind irgendwelche Buffer, die entweder sowieso dauerhaft 
existieren muessen oder bei denen man garantieren muss, dass genug 
Speicher dafuer vorhanden ist. Das laeuft darauf hinaus, dass man den 
SPeicher auch gleich dauerhaft in einer globalen oder static-Variablen 
reservieren kann.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Hier auch nochmal etwas Senf dazu wie man die Sections außerhalb des ROM 
initialisiert:
http://www.fritzler-avr.de/spaceage2/soft_start.php

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Vielen Dank für die Ausführung und deine Codeschnipsel! Top 
Hilfestellung und Erläuterungen!

Tassilo H. schrieb:
> Die Adresse wird also erst beim Funktionsaufruf
> festegelegt.
Tassilo H. schrieb:
> Nun gibt es aber in C nur einen Stack (und die meisten Prozessoren haben
> auch nur einen Stackpointer).
Wenn ich das jetzt alles richtig verstanden habe 
(https://de.wikibooks.org/wiki/C%2B%2B-Programmierung/_Speicherverwaltung/_Stack_und_Heap), 
ist in unserem Fall der Stack im SRAM, wo wir ihn ja auch hin haben 
wollen, zwecks Performance. Der normale Programmablauf soll ja möglichst 
schnell sein.
Lokale ("automatische"?) Variablen benutzen den Stack. Natürlich kann 
ich lokale Variablen dann nur in der section initialisieren, wo der 
Stack liegt.

Hab ich das einigermaßen kapiert?

Laut diversen Forenbeiträgen, werden lokale Variablen immer auf dem 
Stack erstellt, weil das am "schnellsten" bzw. am "einfachsten" geht. 
Irgendwas mit push und pop :) Hast du da auch noch einen Wink, warum das 
so ist?

EDIT: Ach, und ich werde deinem Beispiel folgen, du hast absolut recht, 
im SDRAM (sollen!) ausschließlich ein paar größere Buffer liegen die 
sowieso dauerhaft existieren müssen.
Und mir ist aufgefallen, dass ich so ziemlich das wiederholt habe, was 
du geschrieben hast :)

[Gerd E. (robberknight)]

Reginald L. schrieb:
> Laut diversen Forenbeiträgen, werden lokale Variablen immer auf dem
> Stack erstellt, weil das am "schnellsten" bzw. am "einfachsten" geht.
> Irgendwas mit push und pop :) Hast du da auch noch einen Wink, warum das
> so ist?

Denk an Rekursion. Wie willst Du die Variablen platzieren, daß sie trotz 
Rekursion weiterhin funktionieren? Das wäre ohne sie auf den Stack zu 
packen ziemlich aufwendig.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Gerd E. schrieb:
> Denk an Rekursion. Wie willst Du die Variablen platzieren, daß sie trotz
> Rekursion weiterhin funktionieren? Das wäre ohne sie auf den Stack zu
> packen ziemlich aufwendig.
Da setzt mein Gehirn grad aus. Das war zuviel :)

[Tassilo H. (tassilo_h)]

Reginald L. schrieb:
> Laut diversen Forenbeiträgen, werden lokale Variablen immer auf dem
> Stack erstellt, weil das am "schnellsten" bzw. am "einfachsten" geht.
> Irgendwas mit push und pop :) Hast du da auch noch einen Wink, warum das
> so ist?

Naja, ein Stack (Stapelspeicher/Kellerspeicher in der dt. Informatik) 
ist gerade die passende Speicherstruktur. Mit jedem Funktionsaufruf legt 
man die neuen automatisch Variablen und die Ruecksprungadresse auf den 
Stapel. Der Ruecksprung aus den Funktionen erfogt zwangslaeufig immer in 
der ungekehrten Reihenfolge wie der Aufruf, also kann man immer die 
oberen Elemente wieder vom Stapel raeumen.
So bleibt die Speichernutzung gleichzeitig auch schoen ohne Loecher wie 
sie bei einem Heap entstehen koennten (bzw. bei exakt dieser Reihenfolge 
der Reservierung und Freigabe auch nicht entstehen, aber auf dem Heap 
braucht man extra Speicher um sich die freien Bloecke zu merken und ggf. 
zusammenzufassen, ist also mehr Aufwand).

Und fuer die Speicherung von Ruecksprungadressen hat sowieso (fast) 
jeder Prozessor Hardware-Support fuer einen Stack, also bietet sich der 
auch fuer die automatischen Variablen an. Je nach Prozessor gibt es auch 
Befehle, um direkt bequem auf den Speicher relativ zum Stackpointer 
zugreifen zu koennen.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Mw E. schrieb:
> Hier auch nochmal etwas Senf dazu wie man die Sections außerhalb des ROM
> initialisiert:
> http://www.fritzler-avr.de/spaceage2/soft_start.php
Top!

Ich bin bedient, vielen lieben Dank @all!

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Soo, ich melde mich nochmal mit dem Ergebnis zurück, vor allem, da ich 
so eine Anleitung für den STM32 im Internet leider nicht finden konnte, 
vielleicht hilft es auch anderen Greenhorns wie mir :)

Nochmal kurz zusammengefasst:
Problemstellung: Anstatt mit Pointern auf den SDRAM zuzugreifen, möchte 
man möglichst einfach mit Arrays arbeiten, so wie man es sonst auch 
gewohnt ist:

// Macht keinen Spaß:
for (int i = 0; i < len; i++)
    (*(uint32_t*)(SDRAM_BUFFER + (i * 4))) = (uint32_t)(mybuffbuff[i]);
// Macht total saumäßigen Spaß:
for (int i = 0; i < len; i++)
    sdram_spass_buffer[i] = mybuffbuff[i]

Dazu erst das LinkerScript anpassen:

Memory:
SDRAM (RWX) : ORIGIN = 0xD0000000, LENGTH = 8M

Sections:
. = ALIGN(4);
_sisdraminit = .;
.sdraminit : AT( _sisdraminit )
{
    . = ALIGN(4);
    _ssdraminit = .;
    *(.sdraminit*)
    . = ALIGN(4);
    _esdraminit = .;
} > SDRAM

.sdram (NOLOAD) :
{
    . = ALIGN(4);
    *(.sdram)
    *(.sdram.*)
    . = ALIGN(4);
} > SDRAM

Für den nächsten Schritt muss erst der FMC für den SDRAM initialisiert 
werden. Das kann man am geschicktesten schon im Reset_Handler() in der 
StartUp-File machen, direkt nach dem SystemInit(). Im Prinzip muss dann 
nur noch kopiert werden, das sieht dann etwa so aus:

extern void *_sidata, *_sdata, *_edata;
extern void *_sbss, *_ebss;
extern void *_sisdraminit, *_ssdraminit, *_esdraminit;    // Das hier muss rein!


void __attribute__((naked, noreturn)) Reset_Handler()
{
    void **pSource, **pDest;
    for (pSource = &_sidata, pDest = &_sdata; pDest != &_edata; pSource++, pDest++)
        *pDest = *pSource;

    for (pDest = &_sbss; pDest != &_ebss; pDest++)
  *pDest = 0;

    SystemInit();
    
    SdramInit();    // Hier wird der FMC gestartet, SDRAM ist danach einsatzbereit

    pSource = &_sisdraminit;                             // Das hier muss auch rein,
    for (pDest = &_ssdraminit; pDest < &_esdraminit;)    // hier werden die initialisierten Variablen / Arrays
        *(pDest++) = *(pSource++);                       // ins SDRAM kopiert

    (void)main();
    for (;;);
}

Das wars jetzt eigentlich schon, man legt sich noch zwei defines an um 
Variablen zu definieren und initialisieren. Das kann so aussehen:

#define    DEFINE_IN_SDRAM            __attribute__((section(".sdram")))
#define    INITIALIZE_IN_SDRAM        __attribute__((section(".sdraminit")))

Nun kann der Spaß losgehen:

static DEFINE_IN_SDRAM char spass_buffer_definiert[20];
static INITIALIZE_IN_SDRAM char spass_buffer_initialisiert[100] = { "Meine Fresse, ist das ein Spaß!!!" };

void spass_funktion()
{
    spass_buffer_definiert[5] = 5;
}

Die Geschichte mit static und lokolen Variablen ist weiter oben erklärt. 
Hoffe es haben sich keine Fehler eingeschlichen.


PS: Jetzt habe ich auch ansatzweise eine Ahnung was da im Linker und 
StartupCode drin steht, wollte ich schon immer wissen, aber es hat sich 
nie ergeben. Nochmals vielen lieben Dank an alle! Bussi :> Meine 
Problemstellung wurde innerhalb kürzester Zeit gelöst.

[Nop (Gast)]

Reginald L. schrieb:

> Das habe ich gerade gemerkt. Mit der obigen "Initialisierung" wird wohl
> nur die Variable deklariert, initialisiert wird da laut Memory-Viewer
> nicht mit 0.

Richtig, weil uninitialisierte Variablen in C ganz allgemein keinen 
definierten Inhalt haben. Noch schlimmer, der Compiler erkennt den 
lesenden Zugriff auf uninitialisierte Variablen als undefiniertes 
Verhalten (nach C-Standard) und kann dann Dein ganzes Programm 
wegoptimieren. Weil das Verhalten ja schließlich "irgendwas" sein darf.

Embedded wird im Startupcode der Speicher für die globalen 
uninitialisierten Variablen normalerweise genullt, aber das muß man halt 
auch selber machen, sonst tut es niemand.

> Genau, das habe ich bisher auch so gemacht, erst den Speicher komplett
> mit i + 1 beschreiben und dann komplett mit i + 1 lesen. Wie man so
> einen RAM "normgerecht" prüft, bin ich gerade dabei mich einzulesen.

Das ist ne Wissenschaft für sich. Aber der Ansatz, erstmal komplett zu 
beschreiben und dann komplett zu lesen, ist schon sehr gut. Also nicht 
dasselbe in jede Zelle.

Beim Lesen würde ich übrigens jede Zelle zweimal nacheinander lesen und 
das erste Ergebnis verwerfen. Wenn Du das in C machst, geht sowas mit 
einem Pointer auf volatile uint32_t. Sinn der Sache: "dirty RAM faults" 
erkennt man damit auch.

> Aber warum soll der CCM langsamer sein?

Mißverständnis, ich meinte: SDRAM ist langsamer als SRAM oder CCM, d.h. 
SDRAM ist langsamer als SRAM, und SDRAM ist auch langsamer als CCM. Weil 
SRAM und CCM gleich schnell sind. Die wesentlichen Unterschiede zwischen 
SRAM und CCM ist, daß CCM nicht mit DMA geht, und daß man keinen Code 
aus dem CCM ausführen kann. Letzteres, weil CCM nur über den D-Bus 
angebunden ist. Siehe Reference Manual DM00031020, chapter 2.1.

> Achja und sehe ich das richtig, dass es ansonsten keine Möglichkeit gibt
> Variablen benutzerfreundlicher auf den verschiedenen Memorys zu
> verteilen? Ich muss mit den oben erwähnten Einschränkungen leben?

Also ich finde das mit dem Linkerscript recht komfortabel. (; Klar, daß 
Du für den Stack nur einen Speicherbereich definieren kannst, liegt halt 
an C selber.

> Mhhh schade. Von dynamischen variable verabschiede ich mich gerade

Das ist ohnehin besser für embedded. Speicherfragmentierung und nicht 
deterministische Allokation führen auf Dauer zu Systemen, die erstens 
nicht mehr testbar sind und zweitens auch nicht robust funktionieren. 
Meine Erfahrung aus einem Projekt, wo sowas nach zwei Wochen Betrieb 
dann einfach nicht mehr ging.

void **pSource, **pDest;

Das sollte meiner Meinung nach "uint32_t *" als Datentyp sein. Mit 
void-Pointern kann man nicht rechnen. In C ist die Pointer-Arithmetik 
vom Datentyp abhängig.

Beispiel:

uint8_t *byte_ptr = 0;
uint32_t *word_ptr = 0;

byte_ptr++; /*zeigt jetzt auf Adresse 1*/
word_ptr++; /*zeigt jetzt auf adresse 4*/

Wenn man im C-Code also den Pointer um X erhöht, macht der Compiler 
daraus automatisch eine Addition um X*M, wobei M die Bytegröße des 
zugrundeliegenden Datentyps ist. Geht auch für große Daten wie structs. 
Void hat aber keinen Datentyp. Void-Pointer werden zum Übergeben an 
Routinen benutzt, aber zum Dereferenzieren müssen sie gecastet werden.

Der Grund, wieso der obige C-Code mit "void **" trotzdem funktioniert, 
ist der, daß man dann ja einen Pointer auf einen void-Pointer 
deklariert, und dessen Breite ist die verwendete Pointergröße. Auf STM32 
wird das ein 32bit-Pointer sein. Damit landet man dann auch wieder bei 
4-Byte-Schritten. Aber das ist keine gute Konstruktion, weil eigentlich 
uint32_t gewünscht wird.

[Nop (Gast)]

Ach ja, wichtig noch zum Stackverständnis: C initialisiert lokale 
Vriablen (also die auf dem Stack) nie, aus Geschwindigkeitsgründen. 
Lesender Zugriff daraus ist wieder undefiniertes Verhalten, die ganze 
Routine kann wegoptimiert werden.

Da jede Routine auf dem Stack etwas macht und nach ihrem Ende den 
Bereich wieder freigibt, hängt der Inhalt, den die nächste Routine bei 
ihrem Start auf dem Stack vorfindet, davon ab, welche anderen Routinen 
vorher was mit dem Stack gemacht haben. Es ist also nicht vorhersagbar.

Auch Routinen, die keine lokalen Variablen anlegen, können den Stack 
verändern. Und zwar dann, wenn die Register nicht ausreichen für das, 
was die Routine tut, und der Compiler z.B. Zwischenergebnisse mal auf 
den Stack schiebt.

Das gilt nicht für lokale static-Variablen. Diese sind nicht auf dem 
Stack, sondern es sind von der Handhabung her globale Variablen, die 
aber nur in ihrer eigenen Routine angesprochen werden können. Stichwort 
Datenkapselung.

Aber ansonsten sieht das schon ganz gut aus, was Du da machst. (:

Mich würde mal interessieren, was ein Benchmark Deines SDRAM ergibt. 
Also einfach mal sowas:

volatile uint32_t test_array[10240];
...
for (loops=0; loops < N; loops++)
    for (i=0; i < 10240; i++)
        test_array[i] = i;

Das einmal für ein array im SRAM und SDRAM. N so anpassen, daß man gut 
meßbare Zeiten rauskriegt.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Nop schrieb:
> Das ist ne Wissenschaft für sich. Aber der Ansatz, erstmal komplett zu
> beschreiben und dann komplett zu lesen, ist schon sehr gut. Also nicht
> dasselbe in jede Zelle.
Ich habe mich da jetzt ein wenig eingelesen, und zumindest, wenn man 
einen frischen Ram zum ersten mal physisch angeschlossen hat, könnte man 
so vorgehen, wie auf folgender Seite beschrieben:
http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html

Nop schrieb:
> Mißverständnis, ich meinte: SDRAM ist langsamer als SRAM oder CCM, d.h.
> SDRAM ist langsamer als SRAM, und SDRAM ist auch langsamer als CCM.
Ja, ich Trottel habe deinen Text nicht richtig gelesen.

Nop schrieb:
> Also ich finde das mit dem Linkerscript recht komfortabel. (; Klar, daß
> Du für den Stack nur einen Speicherbereich definieren kannst, liegt halt
> an C selber.
Ja, ich bin jetzt auch recht zufrieden damit. Wobei es halt schon Top 
wäre, wenn man in seiner IDE ein neues Projekt eröffnet, seinen SDRAM in 
die defines einträgt und dann mit

SDRAM lustiger_buffer[10] = { 0 };
SDRAM zweiter_lustiger_buffer[10];

void lustige_funktion()
{
    SDRAM spielverderber_variable = 42;
    lustiger_buffer[5] = 42;
    zweiter_lustiger_buffer[2] = 42;
}

ganz normal, wie mit allen anderen Variablen, arbeiten könnte, ohne sich 
um den Hintergrund zu kümmern. Ich verstehe natürlich, dass das so nicht 
funktioniert. Aber man darf doch Visionen haben :) "I have a dream"

Nop schrieb:
> Das sollte meiner Meinung nach "uint32_t *" als Datentyp sein. Mit
> void-Pointern kann man nicht rechnen. In C ist die Pointer-Arithmetik
> vom Datentyp abhängig.
Da habe ich mich an den in meinem Startupfile schon vorhandenen Pointern 
gehalten. "Never touch a running system"

Nop schrieb:
> Damit landet man dann auch wieder bei
> 4-Byte-Schritten. Aber das ist keine gute Konstruktion, weil eigentlich
> uint32_t gewünscht wird.
Ich benutze VisualGDB und das hat schon so einige Bugs. Habe auch öfter 
Probleme in Verbindung mit Intellisense. Wenn VisualStudio nicht die 
m.M.n. bequemste und ergonomischste Programmierumgebung wäre, hätte ich 
wohl auch schon von VisualGDB losgelassen. Und das für 80 €.

Nop schrieb:
> ich würde mal interessieren, was ein Benchmark Deines SDRAM ergibt.
Das habe ich schon mal ganz zu Anfang gemacht. Da hatte ich mehrere 
Tests angelegt gehabt. Leider hatte ich die dumme Angewohnheit, 
unbenötigte Codeschnipsel wieder zu löschen.
Im Prinzip habe ich Tests gemacht zu:
- for-Schleife mit 8bit, 16bit und 32bit schreiben und lesen
- DMA2D mit 8bit, 16bit und 32bit schreiben und lesen
Schau mal hier rein, da habe ich mal etwas dazu geschrieben:
Beitrag "STM32F4 SDRAM Geschwindigkeit"
Mit DMA2D waren da 170MB/s drin, gott, war ich begeistert was da alles 
geht. Diese krassen Datenmengen.
Wenn du dennoch einen Test möchtest, mach ich ihn dir :)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Jetzt stehe ich doch noch vor einem Problem:

Ich habe, unter anderem, Fonts auf einem SPI-Flash gespeichert. Diese 
möchte ich beim Programmstart in den SDRAM laden und über FontInfo font 
darauf zugreifen.

Die Font-Klasse sieht so aus:

  class CharacterInfo
  {
  public:
    uint8_t widthpixel;    // width, in bits (or pixels), of the character
    uint8_t unused;
    uint8_t datawidth;    // width, in bytes of data bitmap
    const uint8_t* data;  // offset of the character's bitmap, in bytes, into the FONT's data array
  };

  class FontInfo
  {
    // Describes a single font
  public:
    const char* fontName;    // Font name string
    char charHeight;      // height in pixels
    char startChar;        // the first character in the font (e.g. in charInfo and data)
    char endChar;        // the last character in the font
    char spacewidth;      // width, in pixels, of space character
    CharacterInfo* charInfo;  // pointer to array of char information
  };

Je nach Font, zeigt CharacterInfo auf unterschiedlich viele Arrays. Der 
Pointer data in CharacterInfo zeigt, je nach Character, auf einen 
verschieden großen Array.

Gehe ich richtig der Annahme, dass ich hier nur diese Möglichkeiten 
habe:
1. Die Daten wieder per Pointer in den SDRAM laden. Also:
Reginald L. schrieb:
> 1. Pointer auf eine Adresse im SDRam erstellen und (für mich)
> unangenehme Akrobatik betreiben.
-> Damit wäre die ganze Geschichte mit INIT_TO_SDRAM für die Katz.
2. Die unzähligen Arrays abzählen, bzw. abzählen lassen und dann die 
Arrays vom Compiler erstellen lassen. Kommt eigentlich nicht in Frage, 
da immer wieder neue "Objekte" (Fonts, Bitmaps, etc pp) hinzukommen bzw. 
ausgetauscht werden, das ganze soll also ziemlich dynamisch sein.
3. Im Linker die Größe des SDRAMs verkleinern, sodass ich einen Teil mit 
Pointern verwalte und der Rest weiterhin vom Linker verwaltet wird.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Ich glaube ich habe noch eine Möglichkeit gefunden, die mich anmacht:
1. 2 verschieden Font-Klassen. Die eine const, da aus dem STM-Flash in 
den SPI-Flash programmiert wird. Die andere non-const, damit Pointer 
erstellt werden können. Über ein #define wird festgelegt ob gerade 
SPI-Flash programmiert werden soll oder nicht, demnach wechseln auch die 
Klassen. Im Prinzip hatte ich das so schon bisher. Oder gibt es eine 
Möglichkeit dem Compiler zu sagen, er soll alle uint8_t's aus einem 
bestimmten Objekt in den STM-Flash schmeißen?
2. Es wird ein SDRAM Buffer initialisiert, der genauso groß ist wie der 
SPI-Flash.
3. Ein wenig Akrobatik mit dem SDRAM Buffer. So wird eine eigene Klasse 
Pointer beinhalten, die auf die richtigen Stellen im SDRAM zeigen. Von 
dort aus werden später auch die jeweiligen Objekte ausgewählt.

Ich glaube mein Geschreibsel ist ziemlich verwirrend. Ich lade mal ein 
Font hoch, dann kann man sich das auch vorstellen. Und vllt hat ja 
jemand noch nen Tipp oder ne Idee. Oder ne ganz andere Vorgehensweise :>