Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search

Search our partners

Find the latest content on electronic components. Datasheets.com
Datasheets
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

bleeding-edge-toolchain - kolejny toolchain dla ARM

Freddie Chopin 15 Sep 2017 12:39 37725 222
Texa Poland
Reply | New topic
  • #181
    Grizzly16
    Level 14  
    Wywołanie poszczególnych programów ze sprawdzeniem wersji nie dało by radę? Jeśli zgłasza brak programu lub awk nie zwraca żądanej wartości (wersji) lub jest ona mniejsza od wymaganej to zwraca błąd o konieczności uzupełnienia brakujących aplikacji.

    Przepraszam za moje lenistwo, że nie zerknąłem na skrypt. Po ściągnięciu wszystkich sourców kompilacja trwa ~2h. Dysk SSD, i5 (4wątki), 8GB RAM, to domyślnie pomyślałem, że idzie z jednym wątkiem kompilacja, a ona po prostu tak długo trwa. Nawet się upewniłem co mi zwraca echo $(nproc) i faktycznie jest 4.
  • Texa Poland
  • #182
    Freddie Chopin
    MCUs specialist  
    Grizzly16 wrote:
    Wywołanie poszczególnych programów ze sprawdzeniem wersji nie dało by radę? Jeśli zgłasza brak programu lub awk nie zwraca żądanej wartości (wersji) lub jest ona mniejsza od wymaganej to zwraca błąd o konieczności uzupełnienia brakujących aplikacji.

    Tylko chodzi o ustalenie tej listy programów <: że "python" to wiadomo, ale w przypadku innych rzeczy (np. jakieś texinfo, makepdf czy coś w ten deseń) już nie jest tak łatwo...

    Grizzly16 wrote:
    Po ściągnięciu wszystkich sourców kompilacja trwa ~2h. Dysk SSD, i5 (4wątki), 8GB RAM, to domyślnie pomyślałem, że idzie z jednym wątkiem kompilacja, a ona po prostu tak długo trwa.

    No niestety... Całość można nieco skrócić (myślę że spokojnie o jakieś 30-40%) jeśli pominiesz kompilację bibliotek "nano", czyli skrypt można wywołać z argumentem `--skip-nano-libraries`.
  • #183
    filipo96
    Level 11  
    Dzień dobry!
    Czy ktoś może próbował odpalić na makefile i kompilatorze od Freddiego build parallel w eclipse ustawiłem coś takiego:

    bleeding-edge-toolchain - kolejny toolchain dla ARM

    Bez tej opcji oczywiście wszystko do tej pory działa świetnie! Dostaję takie odpowiedzi:
    Spoiler:
    12:20:41 **** Build of configuration Default for project led_blink_103C8T6 ****
    make -j4 all
    Assembling file: startup_stm32f103xb.S
    arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m3 -mthumb -g -ggdb3 -Wa,-amhls=out/startup_stm32f103xb.lst -MD -MP -MF out/startup_stm32f103xb.d -I. -Iinc -Igpio startup_stm32f103xb.S -o out/startup_stm32f103xb.o
    Compiling file: main.c
    arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu99 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/main.lst -MD -MP -MF out/main.d -I. -Iinc -Igpio main.c -o out/main.o
    Compiling file: gpio/gpio.c
    arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu99 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/gpio.lst -MD -MP -MF out/gpio.d -I. -Iinc -Igpio gpio/gpio.c -o out/gpio.o
    Size of modules:
    arm-none-eabi-size -B -t --common out/startup_stm32f103xb.o out/main.o out/gpio.o
    text data bss dec hex filename
    354 0 0 354 162 out/startup_stm32f103xb.o
    C:\arm-none-eabi-gcc-7.2.0-170901\bin\arm-none-eabi-size.exe: 'out/main.o': No such file
    354 0 0 354 162 (TOTALS)
    C:\arm-none-eabi-gcc-7.2.0-170901\bin\arm-none-eabi-size.exe: 'out/gpio.o': No such file
    make: *** [Makefile:269: print_size] Error 1
    make: *** Waiting for unfinished jobs....


    Strukura plików wygląda w ten sposób:
    bleeding-edge-toolchain - kolejny toolchain dla ARM
    Po drugim kliknięciu w build jest tworzony *.elf a za trzecim razem jego rozmiar. Jest to dość dziwne czy ktoś próbował z tym i może pomóc w jakikolwiek sposób?

    Pozdrawiam
    Filip.
  • #184
    Freddie Chopin
    MCUs specialist  
    W pliku Makefile którego używasz (zakładam że z którychś przykładów) brakuje odpowiednich zależności, więc make próbuje wyczarować pliki docelowe zanim jeszcze powstaną pliki źródłowe. W tym przypadku akurat reguła "size" powinna mieć zależność do wszystkich skompilowanych plików *.o, ale takich drobnych problemów jest tam więcej.

    Możesz albo spróbować z którymś z "nowszych" przykładów i jeśli tam to jest poprawione, to sobie przenieść samego Makefile'a, albo wrzuć tu cały plik Makefile to Ci powiem co i gdzie trzeba zmienić (;
  • Texa Poland
  • #187
    filipo96
    Level 11  
    Działa!!!
    Bardzo dziękuję za pomoc!
  • #188
    Freddie Chopin
    MCUs specialist  
    Jak zwykle zapraszam na moją stronkę po najnowszą wersję paczek dla Łindołsa i/lub skrypt do zbudowania toolchaina na Linuxie

    http://www.freddiechopin.info/ > Download > Software > bleeding-edge-toolchain

    Quote:
    - gcc-7.3.0
    - newlib-3.0.0
    - binutils-2.29.1
    - gdb-8.0.1
    - expat-2.2.5
    - gmp-6.1.2
    - isl-0.18
    - libiconv-1.15 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.0
    - python-2.7.14 (Windows only)
    - zlib-1.2.11
  • #189
    Freddie Chopin
    MCUs specialist  
    bleeding-edge-toolchain - kolejny toolchain dla ARM

    No i mamy GCC 8.1.0 (;

    Na stronce standardowo można znaleźć skrypt do kompilacji na Linuxie + gotowe paczki dla Windowsa.

    http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain

    Quote:
    - gcc-8.1.0
    - newlib-3.0.0.20180226
    - binutils-2.30
    - gdb-8.1
    - expat-2.2.5
    - gmp-6.1.2
    - isl-0.19
    - libiconv-1.15 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.1
    - python-2.7.14 (Windows only)
    - zlib-1.2.11
  • #190
    Sareph
    Level 24  
    Coś się w niej zmieniło w zakresie obsługi przerwań? Bo ta wersja postanowiła zignorować wszystkie moje handlery i wrzuciła zamiast nich wszędzie (poza resetem) Default_Handler. (;

    Dopisane: ah, ta wersja najwyraźniej ma jakiś problem z -flto, po usunięciu tej opcji handlery wróciły na miejsce. Ale w takim razie... starsza generuje mniejszy kod.
  • #191
    Freddie Chopin
    MCUs specialist  
    Nie do końca jest tak jak mówisz [; `-flto` jest bardzo problematyczną opcją, która czasem wymaga dodawania do "dziwnych" elementów programu (takich jak pozornie nigdzie nieużywane handlery czy tablice wektorów) atrybutów typu `__attribute__ ((used))`. Musiałem takie zmiany wprowadzać w RTOSie jakiś czas temu. Przykładowo - https://github.com/DISTORTEC/distortos/blob/m...-ARMv7-M/ARMv6-M-ARMv7-M-coreVectors.cpp#L161

    Jak zwykle zalecam daleko posuniętą ostrożność w ferowaniu wyroków o błędach w kompilatorze (; Choć coś mi się obiło o uszy że w poprzedniej wersji binutils (czyli _NIE_ w tej z najnowszego toolchaina, ale w tej ze stycznia) jest jakiś problem z wywalaniem pewnych handlerów - niestety nie znam żadnych dalszych szczegółów... Musiałbyś napisać coś więcej, a najlepiej zrobić jakiś test-case żeby można było zawyrokować co jest źle i ewentualnie zgłosić buga.

    Dodano po 4 [minuty]:

    Profilaktycznie właśnie sprawdziłem - RTOS z włączonym LTO kompiluje się i działa poprawnie, handlery i tablice wektorów są takie jak należy (przynajmniej w aplikacji testowej).
  • #192
    Sareph
    Level 24  
    Czy do końca czy nie to ja nie wiem, bo wnętrzności kompilatorów to nie do końca moja działka, ale może bym jednak poczytał :D. No ale na 6.3 lto mi kod zmniejsza o dobre 10%, i wszystko działa poprawnie. I w sumie na tym 6.3 sobie siedzę, zgodnie z zasadą "jak działa to nie ruszaj", tylko jak wychodzi jakaś nowsza wersja to z ciekawości sprawdzam czy wszystko działa (a na nowszych zawsze coś nie działa. No ale może nowsza wersja poprawi (; )

    Z tymi wyrokami o błędach w kompilatorze to się generalnie zgadzam, no ale jak .map z 6.3 wygląda tak (dla przykładu SysTick):
    Code: 
     .text          0x0000000008014818      0x858 [...]\AppData\Local\Temp\ccQCUWaM.ltrans22.ltrans.o

                    0x0000000008014874                SysTick_Handler


    A z 8.1:
    Code: 
     .text.Default_Handler

                    0x0000000008019b5c        0x2 build/arm-common/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/startup_STM32F107xC.o

                    [... tu wszystkie dostepne handlery ...]

                    0x0000000008019b5c                SysTick_Handler


    Za to po wyłączeniu lto (@8.1):
    Code: 
     .text.SysTick_Handler

                    0x000000000801bc2c       0x24 build/sensors-common/sys/timers.o

                    0x000000000801bc2c                SysTick_Handler

    handler nagle wskakuje na swoje miejsce, a sam jest zadeklarowany jako:

    Code: C
    Log in, to see the code

    No to nie wiem co tu może być zepsute z mojej strony, ale może mi coś umyka, nigdy nie wykluczam. Co ciekawe, rozmiar kodu jest z grubsza taki jak powinien być, tylko te wektory jakoś nie są podlinkowane gdzie byc powinny, ot je po prostu olał (i wrzucił wszędzie defaulta), chociaż widzi, że (i gdzie) są:

    Code: 

    SysTick_Handler                                   build/arm-common/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/startup_STM32F107xC.o

                                                      build/sensors-common/sys/timers.o (symbol from plugin)

    A test case jak bede mial czas to może jutro, chyba że po drodze doznam olśnienia, czy może ktoś mnie olśni. (;
  • #193
    Freddie Chopin
    MCUs specialist  
    Sareph wrote:
    A test case jak bede mial czas to może jutro

    Spróbuj coś takiego zrobić, bo sam bym chętnie zerknął. Przy okazji sprawdzania LTO z nowym toolchainem widzę też, że coś nie mogę wyczarować listingu assemblera bez litanii dziwnych błędów (które nic specjalnego nie psują), więc też jakaś nowość dla mnie (; poprzednio działało bez tych błędów
  • #194
    Sareph
    Level 24  
    Już się bałem, że jak zostawię tylko main i SysTick, to problem zniknie i będzie trzeba grzebać głębiej, ale nie, problem z samym mainem i jednym handlerem (SysTick) się objawia.

    W załączniku setup, na którym przynajmniej u mnie (W7 x64 + gcc 8.1 x64) problem spokojnie odtwarza. W archiwum dodatkowo dwa pliki .map dla tego kodu, jeden z włączonym lto, drugi "normalny".
    Attachments:
  • #195
    Freddie Chopin
    MCUs specialist  
    Jak już poprawiłem Twój Makefile tak żeby się budowało (nie wszystkie systemy są takie głupie jak Windows, że nie zwracają uwagi na wielkość liter w nazwach plików), to w istocie wywala tą funkcję. Niemniej jednak z mojej perspektywy problem jest w assemblerowej tablicy wektorów - z tablicą zrobioną w C LTO działa jak trzeba.

    Dla Twojego projektu można go "poprawić" w dwóch krokach:
    1. dodać `__attribute__ ((used))` przed `void SysTick_Handler()`
    2. w tablicy wektorów wywalć wszystkie `.weak ...Handler`

    Myślę że możesz spróbować zgłosić buga w projekcie binutils, choć nie do końca jestem pewny który komponent by za to odpowiadał - problemem może być zarówno gas jak i linker... Ewentualnie możesz napisać najpiew na listę mailingową, byle od razu z test-casem prostym, który kompiluje się na Linuxie. Twój Makefile jest niestety mocno przekombinowany ale takiego "ficzera" żeby pokazywać komendy które wykonuje (zwykle `make VERBOSE=1` lub coś w ten deseń) to już nie ma... Najlepszy byłby test-case w postaci wymaganych plików źródłowych + komendy które trzeba odpalić z konsoli z palca.

    https://sourceware.org/bugzilla/
    https://sourceware.org/binutils/

    BTW - w GCC 7.3.0 Twój projekt nie wymaga poprawek pod tym względem.
  • #196
    Freddie Chopin
    MCUs specialist  
    Pojawiła się wersja gcc 8.2.0, a więc czas na nowego bleeding-edge-toolchain. Na mojej stronce - http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain można więcp pobrać skrypt linuxowy oraz paczki dla Łindołsa (;

    Quote:
    - gcc-8.2.0
    - newlib-3.0.0.20180720
    - binutils-2.31.1
    - gdb-8.1
    - expat-2.2.5
    - gmp-6.1.2
    - isl-0.19
    - libiconv-1.15 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.1
    - python-2.7.15 (Windows only)
    - zlib-1.2.11
  • #197
    filipo96
    Level 11  
    Dzień dobry!
    Czy bawił się któryś tutaj z kolegów z cmake i arm-none-eabi?
    Sam dopiero się uczę tego narzędzia ale widzę olbrzymią moc w nim.
    Z innej strony gdzie można znaleźć jakiś najnowszy, dobrze działający Makefile?
  • #198
    Freddie Chopin
    MCUs specialist  
    filipo96 wrote:
    Czy bawił się któryś tutaj z kolegów z cmake i arm-none-eabi?

    Niedawno przerobiłem swojego RTOSa całkowicie na CMake - https://github.com/DISTORTEC/distortos

    filipo96 wrote:
    Sam dopiero się uczę tego narzędzia ale widzę olbrzymią moc w nim.

    Generalnie jest spoko, choć wiadomo że nic nie jest idealne. Generalnie do momentu aż nie chce się zrobić czegoś dziwnego to jest OK, potem zaczynają się schody (; Szczególnie gdy ktoś chce używać "custom target" i "custom command".

    filipo96 wrote:
    Z innej strony gdzie można znaleźć jakiś najnowszy, dobrze działający Makefile?

    Ile ludzi, tyle pomysłów na to co to jest "dobrze działający Makefile". Powiedzmy że można by wygrzebać z nieco starszych wersji distortos cały system budowania oparty na make, wydawał mi się całkiem fajny do zastosowań embedded, ale wiadomo że moja opinia tutaj jest subiektywna. Przykładowo w tej rewizji można go zobaczyć - https://github.com/DISTORTEC/distortos/tree/v0.6.0
  • #199
    filipo96
    Level 11  
    Bardzo dziękuję.
    No niestety odnośnie "custom target" to jest prawda jest trochę schodów z tego co widzę.
    Korzystając z okazji powyżej napisałeś jednemu użytkownikowi:

    Quote:
    Dla Twojego projektu można go "poprawić" w dwóch krokach:
    1. dodać `__attribute__ ((used))` przed `void SysTick_Handler()`
    2. w tablicy wektorów wywalć wszystkie `.weak ...Handler`


    Co robi __attrubute__((used)) i dlaczego wywalić wszystkie .weak?
  • #200
    Freddie Chopin
    MCUs specialist  
    filipo96 wrote:
    Co robi __attrubute__((used)) i dlaczego wywalić wszystkie .weak?

    1. Atrybut ten mówi LTO żeby nie wywalał tego kodu/obiektu bo jest on używany, tyle że nie bezpośrednio.
    2. Pytanie o to czemu pliki w paczkach od ST są takie durne raczej należy kierować do ludzi z ST (;
  • #201
    filipo96
    Level 11  
    Hmmm... pewnie źle myślę, ale to weak nie jest po to by funkcja o takiej samej nazwie, która będzie strong nadpisze tą z weak?
  • #202
    Freddie Chopin
    MCUs specialist  
    Sprecyzuj o co dokładnie pytasz. Weak właśnie do tego służy (w skrócie i w pewnym uproszczeniu), tyle że najwidoczniej sposób w jaki zrobione są wektory dostarczone przez ST nie chce dobrze działać przy włączonym LTO. Dlaczego - nie wiem, ale też niezbyt mnie to interesuje, gdyż po pierwsze nigdy nie używam tych plików od ST, a po drugie od lat robię wektory w C lub C++, gdzie taki akurat problem po prostu nie istnieje. Jeśli nie używasz LTO to problemu nie masz. Jeśli używasz, to będziesz niezłym szczęściarzem jeśli kwestia tych wektorów będzie jedynym problemem na jaki trafisz (oczywiście przy założeniu, że debatujemy o "nietrywialnym" projekcie).

    Przy okazji dodam może, że działanie atrybutu "weak" nie jest wcale takie proste jakby się mogło wydawać, szczególnie w kwestii tego kiedy jeden obiekt może wciągnąć pozostałe.
  • #204
    User removed account
    Level 1  
  • #205
    Freddie Chopin
    MCUs specialist  
    stmx wrote:
    Przy okazji też warto przenieść sprawdzanie czy jest mingw na początek skryptu jeżeli opcja jest wybrana.

    Niby można by sprawdzić obecność samego tylko ...-gcc, ale to trochę dziurawy test.
  • #206
    Freddie Chopin
    MCUs specialist  
    No i jest już kolejne wydanie, z GCC 8.3.0, newlib 3.1.0 i oczywiście najnowszymi wersjami innych komponentów. Pliki (skrypt i paczki dla Windows) jak zwykle do ściągnięcia z mojej strony - http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain. Sam skrypt oczywiście jest też na github - https://github.com/FreddieChopin/bleeding-edge-toolchain/releases/tag/190223

    Quote:
    - gcc-8.3.0
    - newlib-3.1.0
    - binutils-2.32
    - gdb-8.2.1
    - expat-2.2.6
    - gmp-6.1.2
    - isl-0.20
    - libiconv-1.15 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.2
    - python-2.7.15 (Windows only)
    - zlib-1.2.11
  • #207
    Freddie Chopin
    MCUs specialist  
    Tadam! GCC 9.1.0 już dostępne (;

    bleeding-edge-toolchain - kolejny toolchain dla ARM

    Skrypt shella i skompresowane paczki dla Windows do pobrania z http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain. Skrypt można też znaleźć na github - https://github.com/FreddieChopin/bleeding-edge-toolchain/releases/tag/190503

    Quote:
    - gcc-9.1.0
    - newlib-3.1.0
    - binutils-2.32
    - gdb-8.2.1
    - expat-2.2.6
    - gmp-6.1.2
    - isl-0.21
    - libiconv-1.16 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.2
    - python-2.7.16 (Windows only)
    - zlib-1.2.11
  • #208
    Freddie Chopin
    MCUs specialist  
    Wczoraj wieczorem przygotowałem skrypt generujący toolchaina z GCC 9.2.0.

    Quote:
    - gcc-9.2.0
    - newlib-3.1.0
    - binutils-2.32
    - gdb-8.3
    - expat-2.2.7
    - gmp-6.1.2
    - isl-0.21
    - libiconv-1.16 (Windows only)
    - mpc-1.1.0
    - mpfr-4.0.2
    - python-2.7.16 (Windows only)
    - zlib-1.2.11


    Wszystko do pobrania ze standardowych lokalizacji:
    - http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain
    - https://github.com/FreddieChopin/bleeding-edge-toolchain/releases/tag/190812
  • #209
    osctest1
    Level 21  
    Dzięki @Freddie Chopin

    gdb w wersji poniżej wersji < 8.3 w moim projekcie niestety zrezygnowało ze współpracy (może projekt za duży (ok 800k kodu i g3) - nie wiem).

    Code: c
    Log in, to see the code


    Tak że Twój kompilat do windy bardzo mi ułatwił życie (co prawda toolchaina nie zmieniłem), bo wersja 8.3 działa - aczkolewiek jest sporo wolniejsza.
  • #210
    arcyimperator
    Level 14  
    Mam problem z instalacją BETa. Dlaczego protestuje o brak kompilatora? nie wiem jaki robi check że zwraca taki błąd -sam nie umiem znaleźć tego miejsca w skrypcie,

    Code: bash
    Log in, to see the code
Reply | New topic