Hallo STM32 Benutzerkollegen, ich versuche gerade das nette Board NUCLEO-L432KC mit Code::Blocks in Betrieb zu nehmen und soweit funktioniert alles (Flashen, Debuggen, usw..). Siehe Projekt im Anhang. Mein Problem: Ein einfaches Blink-Programm braucht bereits 11kB Flash mit Optimierung -O0 (siehe Ausgabe unten) und ca. 8kB mit -Os Ein nacktes main() erzeugt ca. 1kB. Meine Frage: warum steigen die kB so massiv an bei jeder kleinen Initialisierung (SystemClock, GPIO). Ist die HAL Bibliothek so flashhungrig? 2. Frage: kennt wer kleinere LIBS für den STM32L4? Ich verwende HAL hier generiert vom STM32CubeMX. Ich habe bereits Erfahrungen mit F0, F1 und F4 und Projekte in Code::Blocks damit gemacht (abgesehen von AVR, MSP430 und 8051). Nur bei jedem neuen Controller wird diese Aufgabe immer uninteressanter wieder von neuem mit den Optimierungen zu beginnen. Mein aktueller Eindruck ist der: die LIBs brauchen soviel Speicher. Ich hoffe, ich irre mich. Lg Compiling: Src/stm32l4xx_it.c Compiling: Src/system_stm32l4xx.c Linking native: proj.elf Output file is proj.elf with size 205,41 KB Running project post-build steps arm-none-eabi-objcopy -O ihex proj.elf proj.hex arm-none-eabi-objcopy -O binary proj.elf proj.bin arm-none-eabi-size proj.elf text data bss dec hex filename 8392 1088 1568 11048 2b28 proj.elf Process terminated with status 0 (0 minute(s), 1 second(s)) 0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
Nachtrag: mit der mbed Plattform brauch in Blinky 19.8kB :-(
Gast
#4866360
>Ein einfaches Blink-Programm braucht bereits 11kB Flash
Ja, und? Bei 256 Kbytes Flash ist das doch noch kein Beinbruch.
Wenn du wissen willst wer was verbraucht schau in die *.map Datei.
Ich habe mir mit arm-none-eabi-objdump -h -S proj.elf > asm.txt den Assembler angeschaut... da sind die grundlegenden Funktionen angeführt. Das braucht alles in Summe soviel... Siehe Anhang. Ich bin zu anspruchsvoll anscheinend. Scheduler+IO Abstraktion + Hausbus Stack mit Software Pin-Wackeln, Broadcast und Punkt zu Punkt geht anscheinend nur auf 8biter unter 6kB. Andererseits kann ein Tetris in Farbe auch mit 446 Bytes programmiert werden ( http://hackaday.com/2016/10/06/tetris-in-446-bytes/ ) Sehr ernüchternd... Lg.
Du hast vermutlich das Debug Target gebaut. Das ist natürlich ziemlich aufgebläht.
Gast
#4866454
Das ist auch der Debug-Build, da sind zusätzlich die ganzen Debuginformationen drin, deshlab ist der Build dementsprechend groß. Und natürlich sind auch ein paar HAL Funktionen drin, die du nicht benutzt.
Optimierung -Os Striping Symbols -s -Wl,--gc-sections und -ffunction-sections -fdata-sections -flto Bin ich auf 5704 statt 11048bytes Keil Compiler vom Kollegen liefert 4008bytes
Gast
#4866664
Wenn du willst, kannst du noch die HAL rauswerfen (Achtung nur die HAL nicht CMSIS) und beschreibe die GPIO Register händisch (siehe Reference Manual).
libopencm3
TriHexagon schrieb: > Wenn du willst, kannst du noch die HAL rauswerfen (Achtung nur die HAL > nicht CMSIS) und beschreibe die GPIO Register händisch (siehe Reference > Manual). Bei der Initialisierung des Taktbaums (mit PLLs etc.) schießt man sich aber gerne mal in den Fuß. Und das ist dann schlecht zu debuggen, denn auch der Debug Port braucht funktionierenden Takt. Ich würde HAL nur dann ersetzen wenn ich damit sattelfest bin UND den Flash dringenst brauche. Bei den Flash Speichergößen moderner µC erscheint mir das unnötig.
Ich arbeite gerade an einem Projekt mit dem L476. Da ist ne ganze Menge drinne: AD, DA, 2xTimer mit Interrupt, 3 Uarts, USB-FS, Debug über ITM, Ausgabe immer mit printf, iir-Filter in float, qsort, Parameterspeicher im Flash usw. usw. Verwendet wird als Grundlage CubeMX/HAL für Initialisierung und USB. Das Ganze ist grade mal 56k groß mit Keil ohne Optimierung für einfachen Debug. Da denke ich schon, dass man das akzeptieren kann. Prozessoren mit 512 Byte Eprom gab es früher mal, aber die Zeiten sind definitiv (zum Glück) vorbei. Am Anfang wird nun erstmal der größte Brocken der Libraries dazu gepackt. GCC ist ein bisschen größer, aber trotzdem noch in Ordnung. Bisher war das um die 30% mehr Speicher.
Gast
#4868107
Jim M. schrieb: > Bei der Initialisierung des Taktbaums (mit PLLs etc.) schießt man sich > aber gerne mal in den Fuß. Reference manual lesen. Ist überhaupt kein Problem. Zudem erlaubt die HAL ja auch nur das Raufsetzen des Taktes auf Maximum, was ohnehin blöd ist, wenn man zwecks Energieersparnis je nach Situation unterschiedliche Taktraten will. > Ich würde HAL nur dann ersetzen wenn ich damit sattelfest bin UND den > Flash dringenst brauche. Ich würde die HAL ersetzen, um sattelfest zu werden und vor allem diese obfuscation loszuwerden. Dann schreibt man eine wirkliche HAL (und nicht nur einen Register-Wrapper), so daß die Anwendung auch übersichtlich und sogar portabel wird. Konjunktiv, weil ich diesen Schritt gemacht habe, bevor ich die HAL überhaupt eingesetzt habe. Als Samplecode zur Begleitung des reference manuals geht sie aber stellenweise.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.