STM32 & GCC - Platzprobleme - Herangehensweise - *.lst und *.o Dateien.

[Uwe (Gast)]

Hallo,

ich hab einen STM32 mit 64kb, leider stoße ich aufgrund von
SD Card Libarys und vermutlich der extensiven Nutzung der
Standard Lib von St ich hier an die Speichergrenze.

Gerne möchte ich wissen, welcher Programmteil besonders viel
Flashspeicher verbraucht.

Gcc erzeugt beim compilieren ja ganz viele *.lst und *.o Dateien.
Vielleicht ist das ja ein Anhaltspunkt :) Hoffe ich mal.
Neben dem Hauptprogramm (main.o) sind die "fetten Brocken" im Windows
Dateiordner:

*.o Dateien

 main.o (101kb) - Hauptprogramm
 ff.o (57kb) - SD Karte
 stm32f10x_tim.o (53kb) - Timerfunktionen
 //.... Alles weitere kleiner als (23kb)

Am Hauptprogramm kann ich wenig ändern, SD Karten Lib könnte ich
tauschen (mit viel Aufwand), Timerfunktionen könnte ich
ggf. nur über die Register realisieren, ohne die Std.Lib von ST.

Ist diese Herangehensweise oder Beurteilung richtig?

Gcc optimiert den Code schon hinsichtlich der Codegröße.
Ohne diese Option passt es garnicht auf den STM32.

Vielen Dank
Uwe

[Lasse S. (cowz)]

Du kannst den Compiler nicht genutzte Funktionen (bspw. von der ST-Lib) 
nicht mit compilieren lassen (-ffunction-sections).

Auf die Größe der .o Dateien kommt es aber nicht an, sicher, dass der 
Code nicht passt?

edit: Sollte das wirklich nicht passen: Nimm einfach 'nen größeren 
STM32.

Gruß
Lasse

[Olaf (Gast)]

> Gerne möchte ich wissen, welcher Programmteil besonders viel
> Flashspeicher verbraucht.

Bitte ld dir ein mapfile zu erzeugen und liess es dir durch.

-Map=mapfile.txt

Olaf

[Uwe (Gast)]

Hallo,

vielen Dank für die Info.
In der Makefile ist schon alles drin.

Wie genau ist den die *.map Datei aufgebaut.

- Archive member included because of file (symbol)
- Allocating common symbols
   = Alle globalen Variablen
- Discarded input sections
   = Alle gelöschten Funktionen
- Memory Configuration
- Linker script and memory map z.B.
    = Alle Funktionen

 .text.Delay    0x08000148       0x14 ROM_RUN/main.o
                0x08000148                Delay

    = und alle Variablen

     .data.TxBuffer2
                0x20000090       0x12 ROM_RUN/main.o
                0x20000090                TxBuffer2

- Ganz viele Einträge mit .debug...
    = ??
- .ARM.attributes
    = ??
- Cross Reference Table
    =  Zuweisung Funktionen und Dateien

Wie genau könnte ich denn damit den Code optimieren?

STM kann ich leider nicht wechseln, Kleinserie ist bereits
fertig. Drauf passt es schon noch, aber nur 4kb sind noch
frei. 20kb werden bestimmt noch kommen.

Viele Grüße
Uwe

[holger (Gast)]

>Wie genau könnte ich denn damit den Code optimieren?

Welchen Code? Den, den keiner sehen kann?

Allgemeine Tips:
Unnötig aufgeblähte Strings eindampfen.
Eventuell nicht mehr benötigte Debug Strings entsorgen.
Alle Datentypen nur so gross wie nötig.

Wenn der Optimizer nichts mehr zu optimieren hat,
dann halt den nächstgrößeren uC nehmen oder externen
Speicher in Betracht ziehen (z.B. für Strings).

[Uwe (Gast)]

Hallo,

Vielen Dank, geht mir einfach nur darum, wie ich ahand
der map file erkenne, welcher Teil des Programms welchen
Speicherplatz belegt.

Dann könnte ich zielgerichtet an diesen Teilen arbeiten.
Gibt es hier vielleicht schon eine Analyse Tool für Map
File oder ähnliches?

Bei diesen Infos:

Uwe schrieb:
> - Linker script and memory map z.B.
>     .text.Delay    0x08000148       0x14 ROM_RUN/main.o
>                 0x08000148                Delay
>     .data.TxBuffer2
>                 0x20000090       0x12 ROM_RUN/main.o
>                 0x20000090                TxBuffer2

z.B. 0x14 - Delay Funktion verbraucht 20 bytes (0x14)? und
wir gespeichert in bei der Adresse 0x08000148 ???
Variable TxBuffer2 18kb?

Danke & Viele Grüße
Uwe

[geb (Gast)]

53kB für die Timerlib kommen mir schon sehr viel vor. Da wär es wohl zu 
überlegen, ob man nicht selbst die Register beschreibt. Generell ist die 
STM32 Lib zwar recht komfortabel, aber doch einigermaßen aufgebläht und 
wenn man sie außerhalb von Initialisierungen betreibt auch meist zu 
langsam.

Grüße

[Uwe (Gast)]

Hallo,

Danke, Timer Funktionen werden ich wohl mal ersetzen.

Was ich noch nicht ganz verstehe, im GCC Tutorial steht

Speicherverbrauch nach Funktionen aufschlüsseln

    * Map File anschauen
          o dort sind alle globalen und statischen Variablen enthalten
          o Aus der Differenz der Anfangsadressen kann man die  Programmgröße der Funktionen berechnen

Ausschnitt meiner *.map File

Funktionen:

                0x20005000                _estack = 0x20005000
                0x08010000                _seeprom_emul = 0x8010000
                0x00000100                _Minimum_Stack_Size = 0x100

.text           0x08000000     0xa340
                0x08000000                . = ALIGN (0x4)
 *(.isr_vectorsrom)
 .isr_vectorsrom
                0x08000000      0x10c ROM_RUN/startup_stm32f10x_md.o
                0x08000000                g_pfnVectors
                0x0800010c                . = ALIGN (0x4)
 *(.text* .stub .gnu.linkonce.t.*)
 .text.__enable_irq
                0x0800010c        0x4 ROM_RUN/main.o
 .text.__disable_irq
                0x08000110        0x4 ROM_RUN/main.o
 .text.NVIC_SetPriority
                0x08000114       0x2c ROM_RUN/main.o
 .text.positiv  0x08000140        0x8 ROM_RUN/main.o
                0x08000140                positiv
 .text.Delay    0x08000148       0x14 ROM_RUN/main.o
                0x08000148                Delay
 .text.TIM3_IRQHandler
                0x0800015c       0x74 ROM_RUN/main.o
                0x0800015c                TIM3_IRQHandler
 .text.TIM4_IRQHandler
                0x080001d0       0xf0 ROM_RUN/main.o
                0x080001d0                TIM4_IRQHandler

Aus der Auflistung der Variablen:

 .bss.tmp1.6175
                0x2000070c        0x4 ROM_RUN/main.o
 .bss.file      0x20000710      0x224 ROM_RUN/log_to_sd.o
 .bss.logdata_schreibvorgang
                0x20000934        0x1 ROM_RUN/log_to_sd.o
 *fill*         0x20000935        0x3 00
 .bss.fatfs     0x20000938      0x230 ROM_RUN/log_to_sd.o
 .bss.fileinfo  0x20000b68       0x18 ROM_RUN/log_to_sd.o
 .bss.dir       0x20000b80       0x1c ROM_RUN/log_to_sd.o
 .bss.logdata_sicherung
                0x20000b9c        0x1 ROM_RUN/log_to_sd.o
 *fill*         0x20000b9d        0x1 00
 .bss.Fsid      0x20000b9e        0x2 ROM_RUN/ff.o
 .bss.FatFs     0x20000ba0        0x4 ROM_RUN/ff.o
 .bss.Timer1    0x20000ba4        0x4 ROM_RUN/sd_spi_stm32.o
 .bss.Timer2    0x20000ba8        0x4 ROM_RUN/sd_spi_stm32.o
 .bss.CardType  0x20000bac        0x1 ROM_RUN/sd_spi_stm32.o
 *fill*         0x20000bad        0x3 00
 .bss.pv.3724   0x20000bb0        0x4 ROM_RUN/sd_spi_stm32.o

Versteh ich das richtig, die Auflistung ist immer
.Name   Speicheradresse(?)      Speichergröße     Dateipfad
?

Alles 32 Bit Integer werden hier zumindest als 0x4 angegeben.
Das erkenne ich schon mal. Nur gibt das keinen Sinn. (4 für 32bit)
Die Differenz der Speicheadresse ergibt hier auch 4.

Danke
Uwe

[Lasse S. (cowz)]

4 Byte für 32Bit sind doch noch innerhalb der Toleranzgrenzen ;)

[Uwe (Gast)]

Hallo,

Gibt es niemanden, der weiß wie man eine *.map File auswerten kann?
Ich finde hierzu auch nichts im Netz.

Viele Grüße
Uwe

[Uwe (Gast)]

Hallo,

hab grad rausgefunden, das math.h (würde ich diese ersetzen) allein
8,6kb bringen würde. (verwendet wird - nur - cos sqrt atan2)

Viele Grüße
Uwe