Flash und "const"

R. B. schrieb:
> Wenn ich in C vor eine Variable "const" schreibe bedeutet das ja, dass
> diese nicht verändert werden darf/kann (wird quasi zu einer Konstanten).
> Wenn ich das bei der uC-Programmierung mache, so habe ich gehört, packt
> der Compiler diese Konstante in den Flash. Ist richtig?

Kommt auf den Compiler an.
Kann man so nicht allgemein sagen.

Näheres weiß die Doku zu deinem Compiler.

> Warum?
Weil C eine genormte Sprache ist, die vom µC bis zum Grossrechner mit 
seinem genormten Teilen überall gleich funktioniert. Und die ISO-Norm 
hat zum Thema Flash nichts zu sagen, weil sie nicht davon ausgehen kann, 
dass JEDER Computer über ein Flash verfügt.
Daher obliegt das deinem Compilerbauer, die Freiheiten, die ihm die Norm 
lässt, in der jeweiligen Situation auszunutzen bzw. sinnvoll 
einzusetzen. Und für den einen bedeutet das eben "const kommt ins Flash" 
und für den anderen bedeutet es das nicht.
Die Norm beschreibt lediglich, wie sich das Programm bei Verwendung des 
Schlüsselwortes 'const' zu verhalten hat, aber nicht wie das zu 
implementieren ist.

const ist eigentlich nur dazu da, dass der Compiler ne Warnung ausgibt 
wenne doch mal schreibend darauf zugreifst.
Wie bereits gemerkt, wirds unterschiedlich behandelt.

Beim AVR-GCC zB muss man noch PROGMEM dahinter schreiben.

-> Also mal in der Doku gucken.

Ich verwende den GCC 4.6 (nur zur Info, ich such schon die Doku ;))

Martin Wende schrieb:
> Beim AVR-GCC zB muss man noch PROGMEM dahinter schreiben.

Das ist eine Spezialität, die der Harvard-Architektur des AVR geschuldet 
ist. Normale von-Neumann-Systeme brauchen so etwas nicht (und 
entsprechend auch nicht die progmem.h-Klimmzüge).

Rufus Τ. Firefly schrieb:
> Normale von-Neumann-Systeme brauchen so etwas nicht

Weißt du denn, wie es dann gehen könnte? Also ich möchte gern dem 
Compiler überlassen wohin er es in den Flash schreibt.

Martin Wende schrieb:
> const ist eigentlich nur dazu da, dass der Compiler ne Warnung ausgibt
> wenne doch mal schreibend darauf zugreifst.
käse.
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes

R. B. schrieb:
> Weißt du denn, wie es dann gehen könnte? Also ich möchte gern dem
> Compiler überlassen wohin er es in den Flash schreibt.
Poste doch mal ein Beispiel, wann eine const-Variable (auf deiner 
Maschine) nicht im Flash landet.

Probier mal

typedef const struct{
   const char sms_sent[100];
}log_file_t;

Mit Deiner Definition sagst Du nur, das der Pointer nihct beschrieben 
werden darf...

Man kann es ja einfach ausprobieren mit einem simplen "const" und dann 
im erzeugten memory map (evtl. *.map) nachschauen, wo die Konstante 
hingelegt wird.

R. B. schrieb:
> Rufus Τ. Firefly schrieb:
>> Normale von-Neumann-Systeme brauchen so etwas nicht
>
> Weißt du denn, wie es dann gehen könnte? Also ich möchte gern dem
> Compiler überlassen wohin er es in den Flash schreibt.

Na dann überlass es dem Compiler :-)

mit const i = 3;

wird er i nach .rodata legen, zumindest bei ELF Targets, und die 
Implementierung wird .rodata in den Flash lokatieren, wenn das 
praktikabel ist.

Ausnahmen bei GCC ist const volatile, das per Default nicht nach .rodata 
gelegt wird, wo es aber je nach Anwendung hingehört.

Das Problem ist gelöst! Der Compiler mochte es anscheinend nicht, wenn 
bei der Definition der Konstanten kein Wert festgelegt wurde.

Also so läuft es jetzt bei mir:

1

typedef const struct{

2

   const char sms_sent[100];

3

}log_file_t;

4

5

const   log_file_t  log_file={{'\0'}};

R. B. schrieb:
> Also so läuft es jetzt bei mir:

Und welchen Sinn hat eine Konstante mit diesem Inhalt?

Ist ja nicht so, daß Du diese Konstante ohne größeren Aufwand zur 
Laufzeit ändern könntest, ist schließlich 'ne Konstante.

Was hast Du damit vor?

Rufus Τ. Firefly schrieb:
> Was hast Du damit vor?

Also im Prinzip möchte ich damit Speicherplatz auf dem Flash reservieren 
um später mit einer CopyRAMToFlash-Fkt. darauf zu schreiben und den mit 
dem Namen ansprechen zu können. Vorher war es zum teil so, dass der 
Compiler etwas auf den Flash gelegt hat und ich über direkte 
Addressierung ebenfalls. Fand ich aber keine saubere Lösung und so 
(hoffe ich) entscheidet der Compiler wo er was hinlegt.

Hmm. Naja, das kann man dann tatsächlich so machen.

Allerdings hast Du dann keine Kontrolle darüber, wo im Flash das so 
erzeugte Objekt liegt, und ob es beispielsweise über eine Grenze 
zwischen zwei Flash-Segmente hinausreicht, was beim Beschreiben wiederum 
zu Problemen bzw. Mehraufwand führt.

Rufus Τ. Firefly schrieb:
> Hmm. Naja,...

Bin offen für andere Vorschläge =)

Rufus Τ. Firefly schrieb:
> Allerdings hast Du dann keine Kontrolle darüber, wo im Flash das so
> erzeugte Objekt liegt,

Brauche ich doch nicht, solange ich es über den Namen ansprechen kann.

>ob es beispielsweise über eine Grenze zwischen zwei Flash-Segmente hinausreicht,
>was beim Beschreiben wiederum zu Problemen bzw. Mehraufwand führt.

Auf dieses Problem bin ich gerade gestoßen... :-/

Ich würde die letzte(n) Page(s) für sowas nutzen.  Du musst dann
halt nur drauf achten, dass deine Speicherbelegung durch das reguläre
Programm nicht größer wird als bis dahin.

Hm... Wieso sollte man das so im Flash ablegen wollen?

Wenn du für den Prototypen keinen Platz hergeben willst, initalisier ihn 
als Pointer mit Array-Größe 0 und hol dir dann den Platz, den du 
wirklich brauchst mit einem malloc.

Oder wenn du Daten aus dem Flash holen willst, legst du einen Pointer 
auf die Struktur an, dessen Startadresse im Flash liegt und springst 
dann jeweils um eine Struktur-Größe weiter.
Du musst dir dann nur noch hinterlegen, wie viele Sätze du im Flash 
liegen hast.

Mittels des Linker-Scripts kann man angeben welche Teile wo landen 
sollen. Auch wird dort angegeben welche RAM und Flash Bereiche es gibt. 
So könnte man das vorhandene Flash im Linker Script dann einfach 
aufteilen in zwei Sektionen. Den zweiten Bereich verwendet man dann eben 
für diese Daten. Dadurch lässt sich genau festlegen an welcher Adresse 
dieser Bereich liegt.

Einfach mal die Doku zum Gnu ld ansehen, und in das vorhandene 
Linker-Script des eigene Projektes schauen. So müsste z.B. eine MEMORY 
Definition dort sein. Hier mal ein Beispiel:

MEMORY
{
  ram    : ORIGIN = 0x40000000, LENGTH = 64K
  flash  : ORIGIN = 0x80000000, LENGTH = 1M
}

Nun könnte man "flash" aufteilen:

MEMORY
{
  ram    : ORIGIN = 0x40000000, LENGTH = 64K
  flash  : ORIGIN = 0x80000000, LENGTH = 1000K
  sms    : ORIGIN = 0x800FA000, LENGTH = 24K
}

Unter SECTIONS könnte man dann z.B.:


.sms_data :
{
    *(.text.sms_data)
} >sms
. = ALIGN(4);

Dies sagt dem Linker das die Sachen mit dem Attribut "sms_data" dann im 
MEMORY Bereich mit dem Namen "sms" liegen.

Eigentlich könnte man dann über:

typedef const struct
{
   const char sms_sent[100];
} log_file_t;

const   log_file_t  log_file _attribute_ ((section ("sms_data")));

dem Compiler/Linker sagen das es dann auch in diese Sektion gelegt 
werden soll. Siehe auch: 
http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Variable-Attributes.html

Somit hat man den Bereich dann sauber festgelegt. Mittels der Änderungen 
im Linker-Script wird es immer an der gleichen Adresse platziert, und da 
der Bereich dort auch explizit nur für sms_data ausgewiesen ist wird 
dort auch kein Programcode abgelegt.

Grüße,

Chris



Grüße,

Chris