Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Microchip SAM D5x/E5x Pusta kompilacja a zajmuje 66kB RAMu

funak 12 Lut 2018 12:54 528 15
  • #1 12 Lut 2018 12:54
    funak
    Poziom 19  

    Witam

    Wdrażam się w Cortex'y zatem próbuję coś wstępnie skompilować.

    I co ciekawe:

    ATSAMG55J19 [512kB Flash, 163840 bytes RAM]:

    Code:
                Program Memory Usage    :   2020 bytes   0,4 % Full
    
                Data Memory Usage       :   2680 bytes   1,6 % Full


    ATSAMD51J20 [1024kB Flash, 270338 bytes RAM]:
    Code:
                Program Memory Usage    :   2368 bytes   0,2 % Full
    
                Data Memory Usage       :   66680 bytes   24,7 % Full


    O co tu chodzi? Obie kompilacje posiadają ten sam program:
    [code]
    Kod: c
    Zaloguj się, aby zobaczyć kod

    0 15
  • Pomocny post
    #2 12 Lut 2018 14:19
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nie masz się czym przejmować. To początkowe duże zużycie RAM wynika głównie z rezerwacji miejsca na stos. W zależności od projektu możesz zmienić wielkość stosu, "odzyskując" część pamięci, ale dopóki ci to jakoś szczególnie nie przeszkadza, to zostaw tak jak jest.

    0
  • #3 12 Lut 2018 14:35
    Freddie Chopin
    Specjalista - Mikrokontrolery

    funak napisał:
    Obie kompilacje posiadają ten sam program

    Z pewnościa tak nie jest, bo wtedy ilość pamięci byłaby nie tyle zbliżona, co IDENTYCZNA. To co pokazałeś, to zaledwie część tego co jest kompilowane i wgrywane. W sumie to nawet dosyć mała część...

    0
  • #5 12 Lut 2018 14:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    funak napisał:
    Z punktu widzenia języka C to wyglądają identycznie.

    Mylisz się. Z punktu widzenia jednego pliku może i tak, ale nie sądzisz chyba, że cały Twój projekt składa się z tego jednego pliku, no nie? No bo jeśli wg Ciebie to jest cały projekt, to on się nie kompiluje - nie masz nigdzie zdefiniowanej funkcji SystemInit() (;

    0
  • #6 12 Lut 2018 20:00
    Piotrus_999
    Poziom 40  

    @tmf 65k stosu wystarczyłby chyba dla czterech Dziewic Orleańskich. Czy aż tak rewelacyjny jest startup Atmela? (o skrypty linkera z nieśmiałości i grzeczności już nie zapytam)

    0
  • #7 12 Lut 2018 21:14
    Marek_Skalski
    Poziom 33  

    @funak Z ciekawości zainstalowałem najnowsze AS 7 i potwierdzam obserwację. Wygląda to na jakiś gruby błąd w Atmel Studio.
    @Freddie Chopin Funkcja SystemInit() jest trywialna.

    Kod: C
    Zaloguj się, aby zobaczyć kod

    co jest rozwinięte do:
    Kod: armasm
    Zaloguj się, aby zobaczyć kod

    Jest jeszcze wywołanie __libc_init_array(); Wyłączenie nic nie zmienia.
    W pliku .map, bardzo dużo pamięci jest przypisane do .debug, a do tego pojawia się kilka różnych mutex'ów. Dlaczego?
    Optymalizacja jest domyślnie ustawiona na -Os, a debug jest wyłączony. Mimo to kompilacja jest wywołana z ustawioną flagą -DDEBUG -O1 i -g3. Coś zawiodło.
    @Piotrus_999 Skrypt linkera jest o tyle interesujący, że przy braku innych deklaracji wielkości stosu (przez #define STACK_SIZE) na stos rezerwuje 0x10000, czyli 1MiB. Po umieszczeniu deklaracji wielkości stosu w kodzie nic się nie zmienia. W sumie to nie widzę żadnej reakcji na zmiany ustawień z poziomu aplikacji.

    0
  • #8 12 Lut 2018 21:27
    grko
    Poziom 32  

    A nie lepiej po prostu sprawdzić co zajmuje tak wiele w pliku wynikowym? Przecież to nie jest żadna tajemnica. Można spróbować na początek czegoś takiego:

    Kod: bash
    Zaloguj się, aby zobaczyć kod

    0
  • #9 12 Lut 2018 21:29
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Marek_Skalski napisał:
    0x10000, czyli 1MiB

    raczej 64 kB.

    Marek_Skalski napisał:
    Po umieszczeniu deklaracji wielkości stosu w kodzie nic się nie zmienia. W sumie to nie widzę żadnej reakcji na zmiany ustawień z poziomu aplikacji.

    Skrypt linkera ma generalnie gdzieś to co jest w kodzie, a już szczególnie znajdujące się w kodzie dyrektywy preprocesora. Jeśli w tym skrypcie gdzieś jest użyte makro STACK_SIZE, to znaczy że odpowiedni #define musi się pojawić _W_ skrypcie linkera, np. za pomocą jakiegoś #include'a albo wymuszony z linii poleceń (choć to byłoby chyba dosyć dziwne i wymagało pliku pośredniego).

    Marek_Skalski napisał:
    W pliku .map, bardzo dużo pamięci jest przypisane do .debug, a do tego pojawia się kilka różnych mutex'ów. Dlaczego?

    Istotne jest to jaka pamięć jest przypisana dla tych dziwnych sekcji typu .debug - sekcje te są w pliku .elf (co jest odnotowane w pliku .map), niemniej jednak nie są one nigdzie ładowane. Tutaj bardziej może pomóc tzw. "memory dump" (w moim prywatnym standardzie plik .dmp), w którym widać na samym początku, że sekcje typu .debug nie mają atrybutu "LOAD".

    0
  • #10 12 Lut 2018 22:25
    Marek_Skalski
    Poziom 33  

    Freddie Chopin napisał:
    raczej 64 kB.
    Masz rację. Zera mi się rozmnożyły ;)
    Pisząc o ustawieniach z poziomu aplikacji miałem na myśli ustawienia projektu w Atmel Studio, które później powinny zostać zapisane w skryptach. Flagi w skryptach są modyfikowane, ale wielkość pliku wynikowego nie zmienia się. Podobnie jak info dotyczące pamięci. Ręczna modyfikacja flag w make jest nadpisywana przez AS7, więc nie ma sensu.
    Jak ktoś ma chęć, to w załączniku są ostatnie linie uzyskane z użyciem arm-none-eabi-nm --size-sort plik.elf Niestety, to tylko Flash. Nie ma ani słowa na temat SRAM.
    Microchip SAM D5x/E5x Pusta kompilacja a zajmuje 66kB RAMu
    Dla zainteresowanych plik .map. Rozszerzenie zmieniłem ze względu na komunikat o nieprawidłowym typie pliku podczas dołączania do postu.

    0
  • #12 12 Lut 2018 22:32
    grko
    Poziom 32  

    Marek_Skalski napisał:

    Jak ktoś ma chęć, to w załączniku są ostatnie linie uzyskane z użyciem arm-none-eabi-nm --size-sort plik.elf Niestety, to tylko Flash. Nie ma ani słowa na temat SRAM.


    A rozmiar wszystkich symboli oznaczonych literami B b d oraz D to nie SRAM? :) Ale fakt, nie ma na tej liście symbolu związanego ze stosem. Ale jest za to w pliku *.map. Mógłbyś wrzucić tutaj plik *.elf?

    0
  • #13 12 Lut 2018 22:34
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Marek_Skalski napisał:
    Jak ktoś ma chęć, to w załączniku są ostatnie linie uzyskane z użyciem arm-none-eabi-nm --size-sort plik.elf Niestety, to tylko Flash. Nie ma ani słowa na temat SRAM.
    Microchip SAM D5x/E5x Pusta kompilacja a zajmuje 66kB RAMu

    BTW - ten obrazek dobitnie pokazuje jedną z przyczyn istnienia bleeding-edge-toolchain - impure_data to jest właśnie "duży" _reent z newliba, w BET jest specjalnie ustawiony mały (rozmiar około 110 bajtów, czyli ~10x mniej).

    0
  • #14 12 Lut 2018 22:42
    grko
    Poziom 32  

    @Freddie Chopin Szybkie pytanie. Czy duży rozmiar _reent nie jest głównie związany wersją linkowanej biblioteki standardowej? Bo jak używam nano.specs to mam tylko coś takiego:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Dodam, że używam nano.specs na Cortex-M0 z małą ilością pamięci Flash 32K oraz RAM 8K. Wydaje mi się to lepszą opcją dla małych projektów bez OSa.

    0
  • #15 12 Lut 2018 22:45
    Marek_Skalski
    Poziom 33  

    Plik .elf w załączniku. Spakowany, ze względu na silnik Forum, który nie zezwala na bezpośrednie dodanie plików ELF, nawet ze zmienionym rozszerzeniem.
    Po zmianie wielkości stosu, zmienia się adekwatnie zużycie SRAM. Rezerwacja 25% RAM na stos, to chyba działanie prewencyjne. Ale zużycie >1KiB na start systemu, to trochę dużo.

    1
  • #16 12 Lut 2018 23:21
    Freddie Chopin
    Specjalista - Mikrokontrolery

    grko napisał:
    @Freddie Chopin Szybkie pytanie. Czy duży rozmiar _reent nie jest głównie związany wersją linkowanej biblioteki standardowej? Bo jak używam nano.specs to mam tylko coś takiego:
    ...
    Dodam, że używam nano.specs na Cortex-M0 z małą ilością pamięci Flash 32K oraz RAM 8K. Wydaje mi się to lepszą opcją dla małych projektów bez OSa.

    nano.specs to właśnie taki prawie-że-bleeding-edge-toolchain (; W każdym razie "nano" było później niż bleeding-edge-toolchain. Z drugiej zaś strony wersja nano jest kompilowana z takimi flagami, że newlib miejscami robi się nieco tępy - największy akcent jest postawiony na rozmiar. O ile minimalizacja użycia pamięci RAM ma sens w praktycznie każdych warunkach (zwłaszcza z takim _reent, z którego w typowym przypadku realnie wykorzystywane jest dokładnie ZERO bajtów, w mniej typowym może kilkanaście [np. errno]), tak już minimalizacja ilości użytej pamięci flash za wszelką cenę (np. użycie tępawych wersji memcpy() zamiast tych zoptymalizowanych) niezbyt mnie przekonuje. Dla M0 z 32 kB flash może tak, ale jak masz ze 128 kB flasha to trochę bezsensu się szczypać o flash przy tak podstawowych sprawach.

    W ogóle to ideałem byłoby kompilowanie newliba razem z projektem - wtedy można by sobie dopasować go jak trzeba zależnie od sytuacji. Ewentualnie zupełnie inna biblioteka, bo newlib jest trochę za bardzo przekombinowany - z jednej strony niby na mikrokontrolery, z drugiej strony na Cygwina (PC)... Tyle że niezbyt są dostępne jakieś otwarte alternatywy.

    0
TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo