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?
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.
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.
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.
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.
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.
Aber, was vielleicht schon ein Indiz ist, ist dieser Abschnitt hier:
(Pfade der Lesbarbeit halber gekürzt)
1
Linker script and memory map
2
3
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crti.o
4
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
5
LOAD /arm-none-eabi/lib/thumb/v6-m/crt0.o
6
LOAD Device_Startup/startup_samc21.o
7
LOAD Device_Startup/system_samc21.o
8
LOAD main.o
9
START GROUP
10
LOAD /arm-none-eabi/lib/thumb/v6-m\libm.a
11
END GROUP
12
START GROUP
13
LOAD /arm-none-eabi/6.3.1/thumb/v6-m\libgcc.a
14
LOAD /arm-none-eabi/lib/thumb/v6-m\libc.a
15
END GROUP
16
LOAD /arm-none-eabi/6.3.1/thumb/v6-m/crtend.o
17
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.
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?!
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.
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. :)
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.
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?
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.
LeeresProjekt.png
(60 KB)
