STm32F103 und F407: Konstanten sicher ins Flash legen?

Gast #5672471
Lesenswert?

Hallo,

ich überlege grad, wie ich es sicher anstellen kann, dass der Linker 
Konstrukte wie

function(foo,"Ich bin ein Parameter");

oder

const* text = "Blablablab...... lange Geschichte"

sicher ins Flash packt und daraus nicht einen Initializer baut, der das 
dann alles im Ram kopiert beim Startup.

Ich habe mal mein Linker Script angepappt. Gibt es da sichere Methoden, 
dass der GCC Linker da RAM sparend arbeitet? Dem Compiler ist das ja 
egal der weiss ja nicht mal dass es Flash gibt.

Bei Variablen zwinge ich diese mit

#define CCRAM  __attribute__((section(".ccram")))
#define BKRAM  __attribute__((section(".bkram")))
#define RAM    __attribute__((section(".ram")))

Work_t   Work_Bk BKRAM;             // Instanz der Haupt Datenbasis im 
Backup RAM
Work_t   Work CCRAM;                // Arbeitskopie der Datenbasis im 
CCRAM

in ihren Bereich hinein, das map File zeigt mir auch an, dass das 
erfolgreich ist.

Aber wie zwingt man diesen String in den Flash hinein?
function(foo,"Ich bin ein Parameter");

Gruss,
Christian
Angehängte Dateien:
Gast #5672488
Lesenswert?

A. S. schrieb:
> Eine Toolchain, die stringliterale nicht ins flash packt, ist kaputt
> oder kann nicht aus flash lesen.

Ähm.... es liegt irgendwo alles im Flash ohne Strom. Aber dann kommt 
auch so ein böser Initilizer, der im Startup steht und packt schonmal 
alles ins RAM, wie zb die Initwerte statischer oder globaler Variablen. 
Und warum nicht auch Literale? Das weiss ich eben nicht.....
Gast #5672513
Lesenswert?

Ein kleines Testprogramm zeigt dass ein Textstring sehr wohl
im Flash (ab 0x8000_0000) liegt, siehe Adressraum des F103.

Das RAM wäre ja ab 0x2000_0000.
1
#include "stm32f10x_conf.h"
2
#include <stdio.h>
3

4
const char mytext[] = "bla bla bla bla bla bla bla bla bla bla bla bla ";
5
char  tmpstr[120];
6

7
int main(void)
8
{
9
  char *myptr;
10

11
  while(1)
12
  {
13
    myptr = (char *)&mytext[0];
14
    sprintf (tmpstr, "address of mytext is %08lx", (uint32_t)myptr);
15
  }
16
}
(Firma: fritzler-avr.de) #5672519
Lesenswert?

Haste denn Probleme oder ist das jetzt theoretischer natur?

Im Linkerscript wird .rodata wird zu .text zusammengefasst und ins ROM 
gepackt.
Einen temporären umkopierer seh ich da auch nicht.
Also alles gut.

Guck dir mal bei . data das AT() dahinter  an.
Das sorgt dafür, dass für den RAM gelinkt wird, aber es beim Image im 
ROM liegt.
"the AT keyword specifies the load address of the section"
Bei .text ist das nicht.
Gast #5672523
Lesenswert?

Mw E. schrieb:
> Haste denn Probleme oder ist das jetzt theoretischer natur?

Nur informieren bei jenen, die es wissen bevor ich anfange nachher 
wieder alles ändern zu müssen, da ich kiloweise Text reinpacken will in 
die Bastelei. Die IDE verbirgt vieles vor dem User, es läuft aber eben 
so, wie die Bauer von EmBitz es vorsehen.

"the AT keyword specifies the load address of the section"
Bei .text ist das nicht.

Bin da nur rudimentär gebildet in Linker Scripten :-) Hauptsache sie 
funktionieren.....

>> sprintf (tmpstr, "address of mytext is %08lx", (uint32_t)myptr);

Und wo liegt "address of mytext" zur Laufzeit? Ich habe keine IDE offen 
grad..... haste mal das map File?
Gast #5672538
Lesenswert?

Grummel Grummel schrieb:
> In meinem Fall bei 0x0800_0d24.

Ich setze gleich auch mal einen Test auf, denn genau das ist meine 
Frage: Ist das wirklich so? Natürlich liegt das im Flash, wo sonst. Aber 
sobald das Programm läuft kopiert der Startup viel Zeugs ins RAM, wo es 
dann dieses reduziert. Beim Arduino habe ich damit das RAM total 
zugeballert, bis mir jemand erklärte wie es richtig geht. Nur ist ein 
AVR eben Harvard Struktur und der Cortex eine Von-Neumann Maschine. Da 
scheint dann wohl der Unterschied zu liegen....

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren