Variable in speziellem Bereich platzieren

Karl Gast #2965512
Lesenswert?
• ▲
▼ 
Hallo Zusammen,

bei Spielereien mit dem STM32F4 und FreeRTOS frage ich mich, was ich mit 
dem CCM anfangen soll. Nach kurzer Überlegung habe ich mich entschieden, 
den (FreeRTOS-)Heap da reinzupacken (und damit auch die Task-Stacks). 
Der Speicher wird in den c-Dateien heap(1-4).c angelegt, wobei damit 
verschiedene Implementierungen von malloc und free realisiert werden 
können. Habe das bis jetzt über das Linker-Skript realisiert:

1
  CCM (rw)        : ORIGIN = 0x10000000, LENGTH = 64K

2
[...]

3
  .bss_ccm :

4
  {

5
    _sbss_ccm = .;

6
    *heap_*.o ( .bss, .bss* )

7
    . = ALIGN(4);

8
    _ebss_ccm = .;

9
  } >CCM


Funktioniert soweit auch.  :-)

Trotzdem frage ich mich, was ein erfahrener Programmierer an dieser 
Stelle tun würde. Mir fallen eigentlich nur zwei Möglichkeiten ein:
- Platzierung der heap-bss Section über das Linker-Skript abhängig vom 
Namen der Objekdatei
- Erstellen einer "neutralen" Section im CCM und platzieren des Heaps 
mittels __attribute__(...)

Letztere Variante hat das Problem, dass ich den eigentlich 
plattformunabhängigen Code von FreeRTOS anpassen müsste, um das 
_attribute_ unterzubringen.

Also, was meint Ihr?

Vielen Grüße
Kar
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Roland H. #2965706
Lesenswert?
• ▲
▼ 
Karl schrieb:
> Der Speicher wird in den c-Dateien heap(1-4).c angelegt, wobei damit
> verschiedene Implementierungen von malloc und free realisiert werden
> können.

Verstehe ich das richtig: Du hast vier Implementierungen, eine davon 
wird verwendet. Deren .bss-Teile landen durch das obige linker script im 
CCM.

Und alle heap1..4.c sind von Dir? Oder von FreeRTOS?
Wer verwendet _sbss_ccm/_ebss_ccm?

> - Platzierung der heap-bss Section über das Linker-Skript abhängig vom
> Namen der Objekdatei

Das entspricht dann wohl dem angeführten linker script. Im Sinne eines 
applikationsspezifischen linker scripts bzw. als Ergänzung zu einem 
allgemeinen finde ich das in diesem Fall etwas besser als die Variante 
mit dem attribute.

Ich würde eine heap.c verwenden, welche #define gesteuert die gewünschte 
Implementierung mittels #include aufnimmt. Dann ergibt sich in jedem 
Fall eine heap.o, wodurch das linker script m. E. übersichtlicher und 
"grep-able" wird:

1
heap.o ( .bss, .bss* )


Die obige Sektion .bss_ccm in einem separaten SECTIONS { ... } - Bereich 
in einem separaten Teil-Linker-Skript, und dieses zusammen mit dem 
Standard-Linker-Script verwenden.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl Gast #2965718
Lesenswert?
• ▲
▼ 
Roland H. schrieb:
> Verstehe ich das richtig: Du hast vier Implementierungen, eine davon
> wird verwendet. Deren .bss-Teile landen durch das obige linker script im
> CCM.
>
Ja, richtig.

> Und alle heap1..4.c sind von Dir? Oder von FreeRTOS?
> Wer verwendet _sbss_ccm/_ebss_ccm?
Die Implementierungen sind von FreeRTOS und unterscheiden sich in den 
Features. Eben weil die zum OS gehören, möchte ich da drin nichts 
ändern.

_sbss_ccm und _ebss_ccm verwende ich im Startup-Code zum 0-en der 
.bss_ccm Section.

>> - Platzierung der heap-bss Section über das Linker-Skript abhängig vom
>> Namen der Objekdatei
>
> Das entspricht dann wohl dem angeführten linker script. Im Sinne eines
> applikationsspezifischen linker scripts bzw. als Ergänzung zu einem
> allgemeinen finde ich das in diesem Fall etwas besser als die Variante
> mit dem attribute.
>
> Ich würde eine heap.c verwenden, welche #define gesteuert die gewünschte
> Implementierung mittels #include aufnimmt. Dann ergibt sich in jedem
> Fall eine heap.o, wodurch das linker script m. E. übersichtlicher und
> "grep-able" wird:
> heap.o ( .bss, .bss* )
"grep-able" :) Guter Punkt. Meinst Du so?
1
#ifdef USE_HEAP1

2
  #include "heap_1.c"

3
#else

4
 ...

Habe bis jetz immer Skrupel gehabt, c-Dateien zu includen.
Alternativ könnte man auch einfach im Makefile einen Kommentar angeben, 
dass das Linker-Skript anzupassen ist, wenn man an der 
Speicherverwaltung was ändert.

> Die obige Sektion .bss_ccm in einem separaten SECTIONS { ... } - Bereich
> in einem separaten Teil-Linker-Skript, und dieses zusammen mit dem
> Standard-Linker-Script verwenden.

Wo siehst Du den Vorteil zur festen Verwendung des Namens in einem 
Skript?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Roland H. #2967082
Lesenswert?
• ▲
▼ 
Karl schrieb:
> Habe bis jetz immer Skrupel gehabt, c-Dateien zu includen.

Weg damit :-)

Verwende ich sehr oft für die Hardware-Abstraktion. Da bleibt das 
HW-spezifische unter sich in einer separaten Datei: Also nicht zwanzig 
#ifdefs sondern eines mit #include - so wie Du es skizziert hast.

Gerne aber auch für genau den allgemeineren/beschriebenen Zweck: Ein 
Name als "public API", hinter dem sich verschiedene Implementierungen 
verbergen, gesteuert durch eine Konfiguration.

> Alternativ könnte man auch einfach im Makefile einen Kommentar angeben,
> dass das Linker-Skript anzupassen ist, wenn man an der
> Speicherverwaltung was ändert.

Papier und Kommentare sind geduldig. Das Makefile sollte m. A. nach 
abbrechen, wenn irgendetwas nicht mehr zusammenpasst. Oder aber gemäß 
der Konfiguration heap-Variante 1/2/3 genau noch den spezifischen 
Scnippsel zum Haupt-Linker-Script dazunehmen. Das betrifft auch den 
Startup, welcher sich ggf. ebenso anpassen muss.

> Wo siehst Du den Vorteil zur festen Verwendung des Namens in einem
> Skript?

Es trennt das Standard-Linker-Script von einem applikationsspezifischem 
Zusatz. Dem Grundsatz folgend, evtl. Konflikten großräumig aus dem Weg 
zu gehen. Oder dass Speziallfälle explizit/bewusst aktiviert werden 
sollen.

Das Problem könnte ein Namenskonflikt sein: Irgendein anderes Programm 
hat zufällig auch eine heap.c, und dessen Variablen landen im CCM. Der 
Startup wiederum kennt die zweite Region nicht, führt keine 
Initialisierung durch etc.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren