Unrealistische Recourcenauslastung bei leerem Projekt

[F. K. (superpcfan)]

Ich habe mir vom Microchip Studio 7 ein leeres GCC C Projekt für einen 
ATSAMC21E15A anlegen lassen. Dabei war ich irritiert bis geschockt, wie 
viele Systemrecourcen von einem leeren Projekt aufgefressen werden.

Die 2kB Flash könnte ich noch halbwegs verstehen für Reset 
"rumgeplänkel", auch wenn ich das schon arg viel finde alleine für das 
resetten, wenn der Flash eh nur 32kB groß ist.

Aber die 53% SRAM schießen den Vogel ab. Für den Fall, dass das ein 
Anzeigefehler wäre, habe ich einfach mal versucht 3kB RAM zu 
deklarieren. Der compiler hat direkt gemeckert, dass das da nicht rein 
passt....

Was macht GCC da?! Das kann doch nicht sein?! (siehe Anhang)
Muss ich noch irgendwo rumfummeln, damit GCC weiß was es tun soll?

[Oliver S. (oliverso)]

F. K. schrieb:
> Was macht GCC da?!

Vermutlich compiliert und linkt der einfach all das zusammen, was an 
deinem Programm zu compilieren und linken ist. Auch wenn es ja nur 
wenige Zeilen im main () sind, sagt das nichts darüber aus, was sich 
dahinter verbirgt.

Allerdings dürfte eine release-Build mit eingeschalteter Optimierung das 
Problem entschärfen.

Oliver

[F. K. (superpcfan)]

Also das hatte ich bisher noch bei keinem Projekt oder Controller. Ich 
musste weder auf Release umstellen noch an der Optimierung rumfummeln.

Ich habe alle Optimierungsstufen mit Debugbuild und Releasebuild 
durchprobiert. Das Ergebnis ist immer dasselbe wie im Screenshot.
Daran liegt es wohl nicht.

[Harald K. (kirnbichler)]

Man könnte ins Mapfile sehen, um rauszufinden, wo der Speicher bleibt.

[Ingo L. (corrtexx)]

Lass mal die Systeminit weg ;)

[F. K. (superpcfan)]

Ingo L. schrieb:
> Lass mal die Systeminit weg ;)

Hab ich schon, ändert leider auch nix

Das MapFile ist im Anhang. Ich habe leider keine Erfahrung wie man das 
lesen muss.

[Harald K. (kirnbichler)]

F. K. schrieb:
> Aber die 53% SRAM schießen den Vogel ab. Für den Fall, dass das ein
> Anzeigefehler wäre, habe ich einfach mal versucht 3kB RAM zu
> deklarieren.

Wie groß hast Du denn Stack und Heap konfiguriert?

[F. K. (superpcfan)]

F. K. schrieb:
> Muss ich noch irgendwo rumfummeln, damit GCC weiß was es tun soll?

Harald K. schrieb:
> Wie groß hast Du denn Stack und Heap konfiguriert?

Jetzt kommen wir dem Problem näher! Bei diesem Controller muss ich den 
Stack definieren? Danach such ich mal!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

F. K. schrieb:
> Dabei war ich irritiert bis geschockt, wie viele Systemrecourcen von
> einem leeren Projekt aufgefressen werden.
Das Projekt ist ja auch nicht "leer", sondern es hinterlässt ist ein 
komplett initialisiertes System, wenn SystemInit() ausgeführt wurde.

Was kommt raus, wenn du das SystemInit() weglässt?

F. K. schrieb:
> Also das hatte ich bisher noch bei keinem Projekt oder Controller.
Auf welche Controller und welche Toolchains beziehst du dich da?

[Ingo L. (corrtexx)]

Lothar M. schrieb:
> Was kommt raus, wenn du das SystemInit() weglässt?

F. K. schrieb:
> Ingo L. schrieb:
>> Lass mal die Systeminit weg ;)
>
> Hab ich schon, ändert leider auch nix
Kann ich garnich glauben, dass sich nichts ändert...

[F. K. (superpcfan)]

Ingo L. schrieb:
> Kann ich garnich glauben, dass sich nichts ändert...

Siehe Anhang :)

[Oliver S. (oliverso)]

Dann lass das #include "sam.h" auch noch weg.

Olivr

[Ingo L. (corrtexx)]

F. K. schrieb:
> Siehe Anhang :)
Krass, dann kann es ja nur noch an der sam.h liegen...

[Harald K. (kirnbichler)]

F. K. schrieb:
> Jetzt kommen wir dem Problem näher! Bei diesem Controller muss ich den
> Stack definieren?

Bei welchem denn nicht?

[F. K. (superpcfan)]

Nope, auch das ändert nix (siehe Anhang)

[F. K. (superpcfan)]

Harald K. schrieb:
> Bei welchem denn nicht?

Lothar M. schrieb:
> F. K. schrieb:
>> Also das hatte ich bisher noch bei keinem Projekt oder Controller.
> Auf welche Controller und welche Toolchains beziehst du dich da?

Ich habe AtTinys, AtMegas, AtxMegas und AtSams in C und Assembler mit 
GCC programmiert und musste bisher nie am Stack rumspielen. Das war 
immer geeignet voreingestellt.

[Ingo L. (corrtexx)]

F. K. schrieb:
> Nope, auch das ändert nix (siehe Anhang)
Haste mal n Rebuild mit Clean vorher gemacht? Ich kanns eigentlich nicht 
verstehen...

[F. K. (superpcfan)]

Ingo L. schrieb:
> F. K. schrieb:
>> Nope, auch das ändert nix (siehe Anhang)
> Haste mal n Rebuild mit Clean vorher gemacht? Ich kanns eigentlich nicht
> verstehen...

Jup, Clean und Rebuild auf Projekt und Solution Ebene ändert auch 
nichts.

[Harald K. (kirnbichler)]

F. K. schrieb:
> Das war immer geeignet voreingestellt.

Ah, "geeignet". Vielleicht ist hier der Stack/Heap einfach größer 
eingestellt?

Und hast Du zwischenzeitlich mal ins Mapfile gesehen?

[Ingo L. (corrtexx)]

Schau mal in den Assembler, da siehste eigentlich gleich was los ist, 
irgendwo muss der Code ja sein...

[F. K. (superpcfan)]

Im Assembler File ändert sich nichts, egal was ich in der Main 
auskommentiere.
Deswegen habe ich den verdacht, das der Compiler "irgendeine andere 
main.c" verwendet, als die die im Projektexplorer gelistet (und von mir 
geöffnet) ist.
Nur wo die sein soll, weiß ich noch nicht.

Für das MapFile muss ich erstmal zu lesen verstehen. Das dauert noch nen 
Moment.

[Harald K. (kirnbichler)]

Ingo L. schrieb:
> Schau mal in den Assembler

Im Assemblerlisting wird nur der Code des übersetzten C-Moduls 
drinstehen, also nichts relevantes.
Weder der verwendete Startupcode noch der Code der gelinkten Libaries 
wird da zu finden sein.

Mapfile. Notfalls hier als Anhang posten.

[Ingo L. (corrtexx)]

Harald K. schrieb:
> Mapfile. Notfalls hier als Anhang posten.
Hat er ja gemacht

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

F. K. schrieb:
> Nope, auch das ändert nix (siehe Anhang)
Dann liegts am Startup-Code, der zur main() gehört. Dieser Begriff 
taucht im map-File auch sehr oft auf.

Harald K. schrieb:
> Und hast Du zwischenzeitlich mal ins Mapfile gesehen?
Da findet sich schon mal die Erklärung fürs RAM (der Stack nimmt sich 
0x400 = 1024 Bytes). Und dort findet man viele Device_Startup Einträge.

[F. K. (superpcfan)]

Harald K. schrieb:
> Im Assemblerlisting wird nur der Code...

Also ich kann sagen, dass im AssemblerFile die SystemInit() drin bleibt, 
selbst wenn ich "SystemInit" und "sam.h" in der Main auskommentiere.

Als Gegentest habe ich in die Main mal eine Funktion eingefügt, um zu 
schauen ob das überhaupt das AssemblerFile ändert. -> jup!

Wo kommt der StartUp Code denn her, wenn ich aus der Main alles 
auskommentiere?

[Harald K. (kirnbichler)]

Ingo L. schrieb:
> Hat er ja gemacht

Muss ich übersehen haben.

Oh, und das ist ... sehr schön akademisch.

Aber, was vielleicht schon ein Indiz ist, ist dieser Abschnitt hier:

(Pfade der Lesbarbeit halber gekürzt)

Linker script and memory map

LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crti.o
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
LOAD /arm-none-eabi/lib/thumb/v6-m/crt0.o
LOAD Device_Startup/startup_samc21.o
LOAD Device_Startup/system_samc21.o
LOAD main.o
START GROUP
LOAD /arm-none-eabi/lib/thumb/v6-m\libm.a
END GROUP
START GROUP
LOAD /arm-none-eabi/6.3.1/thumb/v6-m\libgcc.a
LOAD /arm-none-eabi/lib/thumb/v6-m\libc.a
END GROUP
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crtend.o
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crtn.o

Neben dem Startupcode (crt*.o) und dem Spezialkram für die 
Initialsierung (startup_samc21/system_samc21) werden hier also noch 
libgcc, libc und libm gelinkt.

Warum um alles in der Welt libm?

[F. K. (superpcfan)]

Harald K. schrieb:
> Warum um alles in der Welt libm?

Ich habe dem Microchip Studio nur gesagt ein GCC C Projekt für den 
ATSAMC21E15A anzulegen.

Was das Studio da treibt versuche ich gerade zu verstehen :)

[Ingo L. (corrtexx)]

Harald K. schrieb:
> Warum um alles in der Welt libm?
Offensichtlich benötigt der Startup die, warum auch immer... Aber dann 
braucht man sich auch nicht wundern, dass schon soviel belegt ist.

F. K. schrieb:
> Also ich kann sagen, dass im AssemblerFile die SystemInit() drin bleibt,
> selbst wenn ich "SystemInit" und "sam.h" in der Main auskommentiere.
Seltsam

[Hugo H. (hugo_hu)]

F. K. schrieb:
> Ich habe dem Microchip Studio nur gesagt ein GCC C Projekt für den
> ATSAMC21E15A anzulegen.

Du spielst doch auch mit dem ASF - oder sehe ich das falsch? Ist da noch 
etwas aktiviert?

[Oliver S. (oliverso)]

Harald K. schrieb:
> Warum um alles in der Welt libm?

Na ja, weil man die vielleicht auch mal braucht, und sich ansonsten 
jemand beschwert, wenn die nicht defaultmässig dazugelinkt wird?

All diese Systemlibs "verbrauchen" aber keinen Speicherplatz, wenn man 
nichts daraus aufruft.

Oliver

[F. K. (superpcfan)]

Hugo H. schrieb:
> Du spielst doch auch mit dem ASF - oder sehe ich das falsch? Ist da noch
> etwas aktiviert?

Ich weiß nicht genau was du meinst. Das Projekt ist als C Projekt 
angelegt. Etwas anderes habe ich nicht angeklickt. Wo soll etwas 
aktiviert sein?

[F. K. (superpcfan)]

Also die Einstellung für die Stackgröße habe ich nun gefunden und 
angepasst...in einer Datei die "Flash" heißt. :P Damit habe ich schon 
15% Ram freibekommen.

Jetzt sind aber immer noch 1,3kB vom Ram belegt. Abzüglich meines Stacks 
sind das immer noch etwa 1kB (25%) die für "nichts" schon belegt sind.
Gibt es noch einen anderen großen Brocken? Ich kann mir nicht 
vorstellen, dass die Libs und Includes schon bevor sie genutzt werden 
den Ram in dieser Größenordnung für nichts belegen?!

[Falk B. (falk)]

F. K. schrieb:
> Jetzt sind aber immer noch 1,3kB vom Ram belegt. Abzüglich meines Stacks
> sind das immer noch etwa 1kB (25%) die für "nichts" schon belegt sind.

Hat das Ding USB? Vielleicht wird das "unsichtbar" initialisiert und das 
1kB wird dafür als Puffer benötigt.

[Hugo H. (hugo_hu)]

F. K. schrieb:
> Ich weiß nicht genau was du meinst.

Ich habe gesehen, dass Du Dich in anderen Threads mit dem ASF 
beschäftigt hast und dachte, Du könntest das auch hier aktiv haben. Ist 
wohl nicht so ... und hat wohl mit SAM-speziellen Voreinstellungen 
(Startup etc.) zu tun.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

F. K. schrieb:
> Jetzt sind aber immer noch 1,3kB vom Ram belegt
Mir ist da die Zeile aufgefallen:

.data.impure_data
                0x20000008      0x428 c:/ ... libc.a(lib_a-impure.o)

Und ich habe damit den Beitrag "Speicherverbrauch der libc optimieren?" 
gefunden.

[F. K. (superpcfan)]

Falk B. schrieb:
> Hat das Ding USB? Vielleicht wird das "unsichtbar" initialisiert und das
> 1kB wird dafür als Puffer benötigt.

Nein, USB hat er nicht. Ich habe stattdessen versucht die includes für 
Can auszukommentieren. Hat nichts gebracht.

Lothar M. schrieb:
> Und ich habe damit den Beitrag "Speicherverbrauch der libc optimieren?"
> gefunden.

Der Tip sieht vielversprechend aus. Das schient hier das gleiche Problem 
zu sein. Jetzt muss ich mal schauen wie ich die libc dazu überreden 
kann, mir den Speicher zurückzugeben. :)

[Adam P. (adamap)]

F. K. schrieb:
> Lothar M. schrieb:
>> Und ich habe damit den Beitrag "Speicherverbrauch der libc optimieren?"
>> gefunden.
>
> Der Tip sieht vielversprechend aus. Das schient hier das gleiche Problem
> zu sein. Jetzt muss ich mal schauen wie ich die libc dazu überreden
> kann, mir den Speicher zurückzugeben. :)

Also laut dem Beitrag in den Linker Flags einfach hinzufügen:
--specs=nano.specs

Dann komme ich auf 32 bytes (0,8%). Testweise mit Stack = 0 Byte.

[F. K. (superpcfan)]

Ich suche gerade die richtige Stelle. Unter "Linker - Miscellaneous", 
hat GCC die Option "--specs=nano.specs" nicht haben wollen. :)

[F. K. (superpcfan)]

Hab Sie, ist unter Linker - Generals sogar eine Checkbox, die im 
hintergrund "--specs=nano.specs" aktiviert.

Flash 1,5% und RAM 7%...das klingt logisch. :)

Danke euch allen.

[Adam P. (adamap)]

F. K. schrieb:
> Ich suche gerade die richtige Stelle. Unter "Linker - Miscellaneous",
> hat GCC die Option "--specs=nano.specs" nicht haben wollen. :)

Bei mir tuts.

F. K. schrieb:
> Hab Sie, ist unter Linker - Generals sogar eine Checkbox, die im
> hintergrund "--specs=nano.specs" aktiviert.

Tatsache, das hatte ich gar net gesehen.

[Ingo L. (corrtexx)]

F. K. schrieb:
> Flash 1,5% und RAM 7%...das klingt logisch
Damit kann man doch gut leben...

[Rbx (rcx)]

Zwei Probleme hier:

1) Erreichbarkeit? -> wohl eher null
2) Thema selbst aber spannend
3) nun folgt aus 1) dass 2 diskutieren eher schlecht geht (+ 
Kollateralschäden)

Vom technischen her:
Wenn man Code einsparen möchte, war bei C schon immer ein Hexeditor die 
erste Wahl. Das ist aber schon lange her, und da könnte man auch mal 
fragen, wieso kann der Compiler den unnützen Hintergrund nicht selber 
wegknipsen?

Und bei ARM: Assembler da ist wohl eher für eingeschlafene Füsse, 
abtörnend langweilig, wirklich sehr uninspirierend, und dann noch andere 
Sachen, teils undokumentierter Hintergrund, teils Produktvielfalt: 
Welcher ARM, welches Betriebssystem, welcher Workflow?

Was dann auf die eigentliche Frage hinausfläuft:
Welches sind die gängigen Workflows?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Moby, ich rate dir nochmals dringend, zum Arzt zu gehen. Du machst dich 
kaputt. Nicht, dass mich das irgendwie stören würde. Aber wenn dir wer 
bei deinem Problem hilft, dann ist hier endlich Ruhe.