STM32 - wo landen Konstanten

Es ist vom Linkerskript abhängig. Wenn dort z.B. Folgendes eingetragen 
ist (Auszug), landen sie in der Section .text und folglich im Flash:

  .text :
  {
    *(.rodata)
    *(.rodata*)
  } >FLASH

Schau ich mal nach, danke  !

Für den Code gibt es eigene Einträge, ich hatte nur den relevanten 
Ausschnitt für die Konstanten gepostet. Am besten schaust du dir mal die 
Linkerskripte genauer an, die der Firmware Library beiliegen (unter 
CMSIS).

Matthias Sch. schrieb:
> komme von den AVRs. Bei denen musste man ja PROGMEM benutzen

Alle anderen mir bekannten Archtiekturen (MSP430, PIC32 bzw. MIPS, ARMs) 
benötigen das nicht. Ein const genügt (wenn das "linker script" so 
ist, wie es Oliver beschrieben hat). Und das ist auch gut so :-) PROGMEM 
und GCC machen einem das Leben nicht einfach: Schreibarbeit, manche 
Funktionen müssen doppelt ausgelegt werden usw.

Es gibt m. W. andere Compiler, die das PROGMEM implizit machen. Der GCC 
tut sich damit schwer bzw. das ist nicht seine Ausrichtung.

Es gibt - neben der Vereinfachung - beim GCC noch einen Vorteil. Im 
Gegensatz zu PROGMEM Strings kann der GCC die "normalen" const Strings 
optimieren. D. h. gleiche Strings sind nur 1x im Flash, und Teilstrings 
ebenso: "Hallo, Welt" und "Welt" belegt nur den Platz, den "Hallo, Welt" 
benötigt. Hängt vom Optimierungslevel ab.

Das führt bei mir regelmäßig dazu, dass das gleiche Programm locker in 
einen ARM mit 32K passt, während es im AVR zum Überlauf kommt.

fdssd schrieb:

> bei den ARMs  wurde das soweit ich weiß korrigiert ..
> der M3 is glaube immernoch  harvard (?)

Wenn man an dieser Stelle mit Havard und Von Neumann argumentiert, dann 
sollte man sich entscheiden, ob damit Busse oder Adressräume gemeint 
sind. Anno Harvard Mark 1 was das noch gleichbedeutend, aber heutzutage 
ist es das längst nicht mehr. Denn alle ARMs (und x86, wenn man vom 
I/O-Adressraum absieht) haben einen einzigen einheitlichen Adressraum, 
unabhängig davon mit wievielen internen und externen Bussen der Core 
implementiert ist.

PROGMEM hängt damit zusammen, dass AVRs 3 völlig getrennte Adressräume 
haben (Flash, EEPROM, RAM) und GCC nicht wie manche 8051er Compiler 
adressraumübergreifende softwarekontrollierte und damit langsame Pointer 
implementiert. Also muss man die Adressräume explizit angeben und 
erwischt da nicht die stärkste Seite von GCC.

Hat man nur einen einzigen Adressraum, dann löst sich das Problem in 
Luft auf und Konstanten können problemlos im Flash landen, ohne dass man 
irdendwie besonders damit umgehen müsste.

Es ist also völlig irrelevant, ob der ARM Core nur einen Bus hat (ARM7) 
oder gleich drei (ARM9). Ob er also im auf die Busse bezogenen Sinn 
Harvard ist oder Von Neumann.

Wenn man in einer Funktion eine const Variable habt, so erzeugt der GCC 
einen Code für die Initialisierung der const Variable.

Wenn hingegen die const Variable außerhalb der Funktion deklariert, dann 
landet die ohne Umwege im Flash.

Markus Müller schrieb:

> Wenn man in einer Funktion eine const Variable habt, so erzeugt der GCC
> einen Code für die Initialisierung der const Variable.

Ausser man verziert diese Variable mit "static".

Vielen Dank nochmal für die ausführlichen Infos. Ich habe bisher eben 
nur mit 8051, TMS320C25 , AVRs und 8048 gearbeitet, alles MC/DSP mit 
getrennten Adressräumen, wobei ich die TMS,51er und 48er nur in 
Assembler bearbeitet habe. C bisher nur auf Linux, Windows und AVRs. Bei 
Linux und Windows nimmt man ja dann eh 'const' , die haben aber kein 
Flash, hehe.
Schön, das es so einfach ist, was ja auch bedeutet, das Zugriffe auf 
solche Konstanten oder eben Variablen im RAM gar keine Kunstgriffe 
brauchen.

Matthias Sch. schrieb:

> Linux und Windows nimmt man ja dann eh 'const' , die haben aber kein
> Flash, hehe.

Aber sie haben ggf. RAM-Bereiche, die von der Anwendung nicht 
beschrieben werden können. Was ungefähr aufs Gleiche rausläuft.

Beim Beispiel "Hallo, Welt\0" und "Welt\0" geht das ja auch, was nicht 
geht, ist ein separates "Hallo\0".

A. K. schrieb:
> Markus Müller schrieb:
>
>> Wenn man in einer Funktion eine const Variable habt, so erzeugt der GCC
>> einen Code für die Initialisierung der const Variable.
>
> Ausser man verziert diese Variable mit "static".

Nee, ging auch nicht nicht.

Ich hatte ein Array mit 10KB, der Compiller machte daraus 50KB mehr 
Flash-Verbrauch.

Markus Müller schrieb:
> Wenn man in einer Funktion eine const Variable habt, so erzeugt der GCC
> einen Code für die Initialisierung der const Variable.

Das kapier ich ja nun gar nicht. Also entweder hast du sowas hier :

1

void printword(const u16 data)

2

{

3

  printbyte(data >> 8);

4

  printbyte((u8)data);

5

}

Was der Funktion ja nur sagt, das sie an der Variable 'data' nichts 
verändern soll, oder sowas:

1

int hex2int(char * hexcode)

2

{

3

const char hextable[18] = "0123456789ABCDEF";

4

unsigned char i,b;

5

int c;

6

char *k;

7

b = strlen(hexcode);

8

c = 0;

9

for (i = 0; i < b; i++){

10

  k = strchr(hextable,hexcode[i]);

11

  if (!k) return 0;

12

// wild pointer arithmetics . Note that this might only work in GCC

13

  c += (pow16(b-i-1) * (k - hextable));

14

  }

15

return c;

16

}

Wo ich halt nur möchte, das 'hextable' im Flash landet. ( Was es 
übrigens tut, ich hab mir die Atollic Linkerskripts angeschaut).
In beiden Fällen sollte der Compiler nix initialisieren dürfen/müssen.