Duży kod wynikowy przy pustej funkcji main w STM32F103 na Linuxie - czy to normalne?

Question

Witam Zaczynam moje starcia z stm32f103 na linuxie. Poprzednio pracowałem a avr. Zainstalowałem środowisko AC6 głównie z powodu że jest na eclipsie. Mimo że używam AC6 bazuje na rejestrach bez używania bibliotek. Jedyne co mnie zaciekawiło to duży kod wynikowy na samym początku. Sama funkcja...

Freddie Chopin · Answer

Ten kto zobaczy Twój projekt oraz pełen log kompilacji.

Badmaneq · Answer

Strzelam - startup inicjuje pamięć ustawia wektory, itd., itp.

amostom · Answer

Oto projekt: #Kod: C / C++Zaloguj się, aby zobaczyć kod A tutaj log: Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka 21:57:39 **** Incremental Build of configuration Debug for project HelloStm32 **** make all  Building file: ../src/main.c Invoking: MCU GCC Compiler /home/cybertom/ARM_workspace/HelloStm32/Debug arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -DSTM32F1 -DNUCLEO_F103RB -DSTM32F103RBTx -DSTM32 -DDEBUG -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -I/home/cybertom/ARM_workspace/HelloStm32/inc -I/home/cybertom/ARM_workspace/HelloStm32/CMSIS/device -I/home/cybertom/ARM_workspace/HelloStm32/CMSIS/core -I/home/cybertom/ARM_workspace/HelloStm32/StdPeriph_Driver/inc -I/home/cybertom/ARM_workspace/HelloStm32/Utilities/STM32F1xx-Nucleo -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MFsrc/main.d -MTsrc/main.o -o src/main.o ../src/main.c Finished building: ../src/main.c Building target: HelloStm32.elf Invoking: MCU GCC Linker arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -T/home/cybertom/ARM_workspace/HelloStm32/LinkerScript.ld -Wl,-Map=output.map -Wl,--gc-sections -lm -o HelloStm32.elf @objects.list  Finished building target: HelloStm32.elf make --no-print-directory post-build Generating binary and Printing size information: arm-none-eabi-objcopy -O binary HelloStm32.elf HelloStm32.bin arm-none-eabi-size HelloStm32.elf text  data  bss  dec  hex filename 1076  1076  288  2440  988 HelloStm32.elf 21:57:39 Build Finished (took 211ms) Zapewne coś spaprałem tylko nie wiem co.

Freddie Chopin · Answer

To z pewnością nie jest PEŁNY log kompilacji. Tak jak już Badmaneq napisał, pewnie dokompilowywuje Ci połowę HALa czy nie wiadomo czego i tak jest efekt.

Zresztą. Wejdź sobie do folderu gdzie jest ten wygenerowany plik elf i wpisz w konsoli:

arm-none-eabi-nm --print-size --size-sort --reverse-sort --demangle HelloStm32.elf

Dostaniesz informację o rozmiarze każdego obiektu (funkcji i zmiennych), posortowaną malejąco po rozmiarze.

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

amostom · Answer

To może tak proszę o info ile mniej więcej powinien zajmować taki kod po kompilacji ? Będę kombinował bo ona razie nie ogarniam tego ARM i kompilatora
A może ktoś zna tutek gdzie znajdę czysty toolchain i jak to powiązać z Eclipse bez żadnych dodatkowych bibliotek ?
Pozdrawiam

Promuję tematy:
10.03.2017 Duży kod wynikowy przy pustej funkcji main w STM32F103 na Linuxie - czy to normalne?
31.01.2016 Kolejny komputer pokladowy ILI9341 TouchScreen

Freddie Chopin · Answer

Gdzieś tyle ( -> stm32_blink_led): Kod: textZaloguj się, aby zobaczyć kod

Konto nie istnieje · Answer

A tu masz przy pustej main wygenerowny przez Cubemx. (bss - to moje dane globalne, nie chciało mi się komentować)
arm-none-eabi-size "Universal_hat_303.elf"
text data bss dec hex filename
832 8 1568 2408 968 Universal_hat_303.elf

832 bajty startup-u

Freddie Chopin · Answer

Przy porównywaniu weź pod uwagę, że powyżej specjalnie zostawiłem zerową optymalizację

Konto nie istnieje · Answer

Szczerze powiedziawszy nie wstawiłem dla porównania (nawet nie przyszło mi to na myśl) tylko żeby dać mu inną wartość - że to koło tych tysiąca może być i nie powinien się martwić. Za dużo jest chyba jadu tutaj, jeżeli podejrzewasz mnie o takie niecne intencje. Tak naprawdę to w 99.99% przypadków nie obchodzi mnie czy to będzie 500 czy 2500 bajtów. Te 0.01 to wtedy jak mam braki pamięci, ale wtedy z reguły 500 bajtów mało mnie ratuje.

amostom · Answer

Dziękuję za odpowiedź. Po prostu przechodzę z avr a tam przy pustej main bylo nieco ponad 100 bajtów. Liczyłem że będzie coś więcej bo to przecież inne próbki ale takiego się nie spodziewałem Ale dziękuję za odpowiedź.

Konto nie istnieje · Answer

A brakuje Ci miejsca?

rb401 · Answer

Bez sensu to Twoje porównanie. To przecież dwa różne światy. Sama tablica wektorów przerwań w F103 to 200bajtów (ok. 50 wektorów * 32 bitowy adres). Plus inicjalizacja rejestrów i samego C, plus ustawienie zegara. Wychodzi 1k, jest bardzo dobrze. Nie ma się co tym przejmować, szkoda życia. Tym bardziej że jak piszesz dopiero wchodzisz w ARM. Takie analizy zostaw sobie na później. To przecież tylko 1k ze 128k które masz do dyspozycji. Jeśli mógłbym coś zasugerować, to właśnie porzucenie pewnych lęków i przyzwyczajeń z 8-bitowców AVR, tego, za przeproszeniem, permanentnego dziadowania i kompromisów. A to dyktatura dwóch różnych pamięci i makro F czy jakieś dziwadło progmem. Ciasnota 16bitowej przestrzeni adresowej. Strach przed używaniem zmiennego przecinka i dłuższych integerów. I tym podobne liczne atrakcje. Tego w STM32 nie ma. Ciesz się przestrzenią i wolnością, nie szukaj problemów gdzie ich nie ma, bo i tak, przy poznawaniu STM32, problemy (tyle że innego rodzaju) znajdą Ciebie .

Freddie Chopin · Answer

Nawet więcej, bo jest 16 wektorów rdzenia, a STM32F1 mają przynajmniej 60 swoich własnych (max 68 w connectivity) - razem więc jest 76-84, co daje przynajmniej 304 bajty. Do tego często dochodzą osobne handlery dla każdego przerwania (sam zacząłem tam jakiś czas temu robić, ponieważ ułatwia to debuggowanie gdy wiadomo które przerwanie się wywołało, a nie Default_Handler), a więc jeszcze MINIMUM 2 bajty na każde (rozmiar wąskiej wersji instrukcji skoku bezwarunkowego [nieskończona pętla]). W każdym razie taka naprawdę PUSTA funkcja main(), bez żadnej inicjalizacji GPIO, zegarów itd, a wiec mamy tylko i wyłącznie startup, wektory i pusty main (optymalizacja -Os, w przykładowym projekcie jest jeden wspólny Default_Handler): Kod: textZaloguj się, aby zobaczyć kod

amostom · Answer

I dziękuje bardzo za odpowiedz Postaram się odrzucić nawyki z avr Pozdrawiam

Duży kod wynikowy przy pustej funkcji main w STM32F103 na Linuxie - czy to normalne?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Podsumowanie tematu