Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
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 22 Mar 2017 20:46 37725 222
Texa Poland
  • #151
    Freddie Chopin
    MCUs specialist
    W sensie że wisi na tej komendzie już od długiego czasu? Generalnie na pewno nie powinno tak być, komendy (poza tymi które kompresują paczkę) wykonują się bardzo szybko i niezbyt da się je nawet przeczytać. Sprawdź może takie rzeczy:
    - ile masz wolnego miejsca na dysku (df -h),
    - ile masz wolnego RAM (free -h),
    - czy jakiś proces nie zżera 100% procesora (top).

    Czas trwania całego procesu to oczywiście sprawa indywidualna, ale 2h to by trwało jakbyś miał jakiś NAPRAWDĘ stary i wolny komputer.
  • Texa Poland
  • #152
    arcyimperator
    Level 14  
    Tak jest, komendy wykonują się bardzo szybko. Nie wyraziłem sie precyzyjnie - przewinąłem terminal i skopiowałem jedną z ostatnich.
    Mam i3, 2,2GHz
    Jakieś 3G wolnego RAMu
    ok. 10G wolnego miejsca na dysku (w trakcie wykonywania skryptu zjeżdżało nawet do 6GB).
    Procek nie jest mocno używany:)

    Ok, skończyło się po ok 2,5h... błędem. python2.7 nie istnieje albo nie może być użyty, jakkolwiek...:

    maciek@maciek:~$ which python2.7
    /usr/bin/python2.7
    maciek@maciek:~$ python2.7
    Python 2.7.10 (default, Oct 14 2015, 16:09:02)
    [GCC 5.2.1 20151010] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
  • Texa Poland
  • #153
    Freddie Chopin
    MCUs specialist
    Hmm... Trochę wolno to u Ciebie działa, no ale chyba niewiele na to poradzisz. Powiedzmy że oryginalny czas o którym kiedyś pisałem (20 minut) już raczej nie jest aktualny (dodanie bibliotek "nano" i innych wariantów multiliba), niemniej jednak jakiejś drastycznej różnicy nie powinno być. Nie mierzyłem u siebie tego czasu ostatnimi czasy, ale "na oko" coś pomiędzy 30-40 minut. Na travis-ci buduje się w około 35 minut. No ale to nie jest takie istotne.

    Co do błędu, to istotne jest, abyś miał paczkę z bibliotekami i nagłówkami Pythona. W niektórych distro (nie wiem jakie masz) akurat sam plik wykonywalny Pythona jest rozdzielony od bibliotek i nagłówków, bo te nie są potrzebne do wykonywania skryptów. Kompilacja GDB potrzebuje tego drugiego, ponieważ ona linkuje w sobie interpreter Pythona. Jest tak np. na Ubuntu, w którym trzeba doinstalować m.in. paczkę "python2.7-dev" (zerknij do pliku README.md). Może w tym problem? Jakiej dystrybucji używasz i czy masz tą właśnie paczkę? Generalnie ten test sprawdza czy masz pliki typu /usr/include/python2.7/Python.h i /usr/lib/libpython2.7.so
  • #154
    arcyimperator
    Level 14  
    Freddie, dzięki za szybką i precyzyjna odpowiedź. Zgadza się, używam Ubuntu 15.10. Sprawdzę jak tylko wrócę z pracy ( i dam odpowiedź po skończonym buildzie:))

    Dodano po 6 [godziny] 7 [minuty]:

    [piszę z pracy]
    Jeszcze podepnę się pod ten temat: w tej chwili używam starszej wersji BETa(nie pamiętam jakiej). Niestety jestem bardzo niezadowolony z rozmiaru generowanego kodu. Krótkie funkcje (~20 linijek, same operacje na zmiennych lokalnych) ważą nawet do 200B. Jeśli w środku dodam wywołanie I2C_read(...); to _każde_ takie wywołanie zwiększa rozmiar o 40B. Czy ktoś może zasugerować przyczynę? Bo to chyba normalne nie jest:] Optymalizacja 0s.
  • #156
    arcyimperator
    Level 14  
    Przyklad:
    Code: c
    Log in, to see the code



    maciek@maciek:~/RFM73/out$ size -A -d inv_mpu.o |grep st_bias
    .text.get_st_biases.isra.0 272 0

    Albo takie coś o:
    Code: c
    Log in, to see the code

    text.mpu_run_self_test 776 0

    mam nadzieję że nie przesadzam "bo tyle ma być" :]
  • #157
    User removed account
    User removed account  
  • #158
    Grizzly16
    Level 14  
    Witam,
    mam dziwny problem z kompilowanym toolchainem przy użyciu skryptów od Freedie-go.
    Jest to (chyba) kłopot na poziomie komunikacji pomiędzy GDB, a openOCD.
    Używam eclipse, projekty kompiluje z makefile-a.

    Korzystam z prekompilowanej paczki: bleeding-edge-toolchain-160412 (64-bit Linux) i świetnie się spisuje.
    Programy kompilują się bez zająknięcia, również debugowanie z wykorzystaniem ST-Link V2 działa jak należy.
    Do komunikacji pomiędzy GDB a openOCD stosuję GDB openOCD Debugging z GNU ARM Eclipse plug-in.

    Z użyciem najnowszego skryptu (i starszymi również) już niestety nie jest tak wesoło. Kompilacja toolchaina wygląda na ok.
    Wgrywam kod do MCU z poziomu Eclipse, wykonywanie zatrzymuje się na początku main, puszczam program w ruch i działa ale... nie mogę zapauzować, stworzyć w locie breakpoint-a (po chwili wyskakuje obok breakpoint-a warrning o timeout-cie), zatrzymać debugowania przez przycisk stop (chociaż po dłuższej chwili potrafi wywrócić debugowanie od klikania na oślep w buttony ;) ).
    Zwracałem uwagę na wymagane zależności opisane w README.md.

    Używam sklonowanego z oficjalnego mirrora openOCD 0.10.0-dev.

    Miał ktoś podobną sytuację?
    Sporo szukałem na googlach, ale nic nie znalazłem podobnego. Pewnie coś przeoczyłem ale za cholerę nie mogę wyłapać co przy każdym powrocie do problemu, z którym walczę w luźniejszych okresach czasu bo jednak miło by mieć pachnący niczym świeże bułeczki toolchain.

    Pozdrawiam
  • #159
    User removed account
    User removed account  
  • #160
    Freddie Chopin
    MCUs specialist
    @Grizzly16 - zerknij tu https://www.elektroda.pl/rtvforum/topic3289255.html. Ze starym toolchainem Ci działa, bo tam jest GDB 7.11, więc w nowym Eclipse problem nie występuje. Zainstaluj sobie wcześniejszą wersję Eclipse'a (ja używam Neon.1a (4.6.1) i jest OK. Problemem jest tylko i wyłącznie kombinacja Eclipse Neon.2 (4.6.2) _i_ GDB 7.12 lub nowsze.

    Dodano po 8 [minuty]:

    @arcyimperator - ciężko wywnioskować po tym co wrzucasz czy tak ma być czy nie. Zapewne tak ma być, skoro tak Ci to skompilowało [; Czy może być inaczej? Pewnie tak, ale żeby odpowiedzieć definitywnie, trzeba by mieć cały projekt i eksperymentować, oglądać assemblera, sprawdzić różne wersje kompilatora itd.
  • #161
    Sareph
    Level 24  
    Freddie Chopin wrote:
    mojej stronki - http://www.freddiechopin.info/ > Download > Software > bleeding-edge-toolchain.

    Niektóre pliki, a przynajmniej arm-none-eabi-gcc-6.3.0-170314-win64.7z (czyli pewnie wszystkie 7z) mają źle ustawiony Content-Type na "text/plain" przez co przy próbie pobrania przeglądarka usiłuje to wczytać jako tekst.

    bleeding-edge-toolchain - kolejny toolchain dla ARM
  • #162
    Freddie Chopin
    MCUs specialist
    A która przeglądarka jest taka mądra? W Chrome wszystko działa (i działało zawsze, bo praktycznie wszystkie pliki są tak wrzucone) "od zawsze". W Joomli nawet nie ma od tego opcji, chyba że to kwestia "Direct link", z tym że to zamierzone, aby nie pobierać tak dużych plików przez PHP.
  • #163
    Sareph
    Level 24  
    Freddie Chopin wrote:
    A która przeglądarka jest taka mądra?
    Nie wiem czy mądra, to raczej poprawne zachowanie. Skoro serwer informuje, że wysyła właśnie plik tekstowy to go przeglądarka chce potraktować jak plik tekstowy. Nie ma też Content-Disposition, to wczytuje inline. A że w chrome działa - bo on zdaje się sprawdza czy ten tekst to faktycznie sensowny tekst. No ale, to że działa to nie oznacza z automatu, ze tak jest poprawnie. Która przeglądarka - Pale Moon 27 albo jak wolisz Firefox 49.

    Freddie Chopin wrote:
    W Joomli nawet nie ma od tego opcji
    Bo to najpewniej kwestia konfiguracji apache. 7z nie masz wpisanych do bazy mime apache, wiec serwuje z domyślnym jaki jest ustawiony, a ten (prawie zawsze) to text/plain właśnie.
  • #164
    Freddie Chopin
    MCUs specialist
    Sareph wrote:
    7z nie masz wpisanych do bazy mime apache, wiec serwuje z domyślnym jaki jest ustawiony, a ten (prawie zawsze) to text/plain właśnie.

    A jestem sobie to w stanie sam gdzieś wpisać, skoro to "shared hosting"?
  • #165
    Sareph
    Level 24  
    Freddie Chopin wrote:
    A jestem sobie to w stanie sam gdzieś wpisać, skoro to "shared hosting"?
    Możliwe. Dodaj sobie do .htaccess linijkę "AddType application/octet-stream .7z" i zobacz co się stanie. ;)
  • #168
    arcyimperator
    Level 14  
    Freddie & Piotrus dzieki za podpowiedź. W tej chwili analizuje assemblera, na razie ciężko cokolwiek mi powiedziec czy tak ma być -jak coś znajdę to się podzielę.
    Zastanawia mnie jeszcze jedna rzecz:eksperymentalnie zwiększyłem w linkerze rozmiar Flasha z 64 na 164 i w logu kompilacji mam coś takiego:
    Code: bash
    Log in, to see the code


    Przy czym gdy ustawię rozmiar Flasha z powrotem na 64kb w skrypcie linkera to mam "region `rom' overflowed by 1460 bytes"
    ZTCW to elf jest większy, ale nie jest ładowany w całości. Czy zgłaszanie tego błędu jest słuszne? Czy modyfikując Makefile mogę to jakoś poprawić, ew. uzyskać tylko hex?
  • #169
    Freddie Chopin
    MCUs specialist
    arcyimperator wrote:
    ZTCW to elf jest większy, ale nie jest ładowany w całości.

    Komenda `size` podaje Ci rozmiar dokładnie tych sekcji, które są ładowane. Do flash trafia zwykle .text + .data. Sam plik zajmuje pewnie z megabajt i rozmiar ten ma niewiele wspólnego z tym co zostanie wrzucone. Rozmiar twoich obiektów (to co podajesz w pierwszej linijce) ma małe znaczenie, bo do tego linker dorzuca jeszcze kod z bibliotek.
  • #170
    Sparrowhawk
    Level 22  
    Ja zapytam: Jakie korzyści, możliwości daje korzystanie z tego toolchain'a względem: "GNU ARM Embedded Toolchain" ?
  • #171
    Freddie Chopin
    MCUs specialist
    1. Jeśli używasz C++, to w tym toolchainie naprawdę są wyłączone wyjątki. W tym od ARMa w "normalnej" konfiguracji wyjątki pojawią się zwykle natychmiast po użyciu dowolnej funkcji z biblioteki. W efekcie rozmiar aplikacji rośnie o kilkadziesiąt kB, wraz ze zużyciem RAM.

    2. W mojej opinii opcje newliba które użyte są w bleeding-edge-toolchain są dużo lepsze dla mikrokontrolerów. Wydaje mi się, że opcje wybrane przez ludzi z ARM nigdy nie zostały w żaden sposób przemyślane i jest to po prostu jakiś "domyślny zestaw". Opcje te wpływają np. na to, czy użycie niektórych funkcji z stdio w ogóle się uda bez 3-4kB wolnego stosu, na to ile pamięci zajmuje firmware "na dzień dobry" i na to czy pewne funkcjonalności będą uparcie wciągały dynamiczną alokację, choć w embedded są one praktycznie zbędne (atexit()).

    3. Możesz sobie na Linuxie wygenerować toolchain taki jak Ci potrzeba (32/64-bit), który na pewno będzie działał. Toolchain od ARM wcale nie działa na każdej wersji Linuxa - u mnie np. nie działa ich GDB. Jeśli ktoś ma wersję 32-bitową (nie wiem po co, no ale jak ktoś chce to proszę bardzo), to też "ma pecha", bo toolchain od ARM jest tylko 64-bitowy teraz. W sumie to i tak lepiej niż ostatnio, kiedy był tylko 32-bitowy <:

    4. Z racji używania najnowszych komponentów wersja bleeding-edge-toolchain z GCC 7 będzie dostępna pewnie za niecały miesiąc (taka jest spodziewana data wydania GCC 7.1), a ARM pewnie taką wyda znów z rocznym opóźnieniem. Choć kto wie - może nas zaskoczą (;

    5. Nie wspierasz durnej manii robienia swoich własnych branchy wszystkiego. Goście od ARM chyba nie mają swojego brancha już tylko w newlibie!

    Argument szybkości kompilacji o którym kiedyś pisałem już najprawdopodobniej nie obowiązuje dla Windows (trzeba by sprawdzić, ale od pewnego czasu używają tak jak ja Mingw-W64), dla Linuxa też nie ma różnic.

    Generalnie najważniejszą przyczyną istnienia bleeding-edge-toolchain jest punkt 1. Używając toolchaina od ARM faktycznie można narzekać, że "C++ nie nadaje się w ogóle do mikrokontrolerów" i byłbym nawet gotów się z takim stwierdzeniem w takim przypadku zgodzić.

    Jeśli dla kogoś terminy typu "C++17" mają znaczenie, to również punkt 4 robi się bardzo istotny.

    Punkt 2 jest istotny dla osób używających RTOSów, które oczekują od nich czegoś więcej niż samego schedulera. Szczególnie chodzi tu o rozmiar struktury "_reent", który może wynosić ~1kB (ARM) lub ~100B (bleeding-edge-toolchain). Generalnie prawda jest taka, że każdy wątek powinien mieć swoją, więc kilka-kilkanaście takich obiektów już robi "pewną" różnicę.

    Summa summarum - używając toolchaina bleeding-edge-toolchain masz 99% tego co w toolchainie od ARM, z tym że - w mojej opinii - znacząco lepiej dopasowane do mikrokontrolerów (w sensie ARM Cortex-M). Z 1% rzeczy których nie masz w bleeding-edge-toolchain większość możesz mieć przy minimalnym wysiłku (wystarczy zmodyfikować opcje w skrypcie i przekompilować), a pozostałe są dla nas zupełnie nieistotne (wsparcie dla ARMv8-M) lub mało istotne (obszary "execute only" czy tego typu bajery), a tak czy siak będą dostępne już wkrótce (zapewne właśnie przy okazji GCC 7.1, czyli za ~miesiąc).
  • #172
    Sparrowhawk
    Level 22  
    Dzięki za obszerne wyjaśnienie. Muszę przyznać, że skrypt robi wrażenie, ale u mnie poległ:
    Code: bash
    Log in, to see the code
  • #173
    Freddie Chopin
    MCUs specialist
    Obstawiam brak texlive i/lub texinfo - generalnie jakiś problem z tymi paczkami. Jakiego dokładnie używasz systemu?

    Problem z dokumentacjami można też łatwo pominąć. Znajdź wszystkie
    Code:
    "html pdf"

    zamień na:
    Code:
    ""
  • #174
    Sparrowhawk
    Level 22  
    Faktycznie brakowało pakietu 'texlive-latex-base'. Po doinstalowaniu kompilacja przeszła bez błędów, chociaż trochę to trwało ;-)
  • #175
    Freddie Chopin
    MCUs specialist
    Gdyby ktoś miał ochotę na experymenty z experymentalnymi wersjami, to proszę bardzo (;

    Code: bash
    Log in, to see the code


    https://github.com/FreddieChopin/bleeding-edge-toolchain/tree/gcc-7-experimental

    Pełne wydanie (GCC 7.1.0) spodziewane jest w tym miesiącu.
  • #176
    Freddie Chopin
    MCUs specialist
    Mniej niż 24h po wydaniu stabilnej wersji gcc 7.1.0 można się nią już cieszyć na mikrokontrolerach ARM (;

    Quote:
    - gcc-7.1.0
    - newlib-2.5.0.20170421
    - binutils-2.28
    - gdb-7.12.1
    - expat-2.2.0
    - gmp-6.1.2
    - isl-0.18
    - libiconv-1.15 (Windows only)
    - mpc-1.0.3
    - mpfr-3.1.5
    - python-2.7.13 (Windows only)
    - zlib-1.2.11


    Pliki można pobrać jak zwykle z mojej strony: http://www.freddiechopin.info/ > Download > Programy > bleeding-edge-toolchain
  • #177
    Freddie Chopin
    MCUs specialist
    Tym razem z nieco większym poślizgiem, ale już jest (;

    Quote:
    - gcc-7.2.0
    - newlib-2.5.0.20170818
    - binutils-2.29
    - gdb-8.0
    - expat-2.2.4
    - gmp-6.1.2
    - isl-0.18
    - libiconv-1.15 (Windows only)
    - mpc-1.0.3
    - mpfr-3.1.5
    - python-2.7.13 (Windows only)
    - zlib-1.2.11


    Skrypt i toolchainy dla Windowsa są już do pobrania z mojej strony (;
  • #178
    08FEDRA
    Level 13  
    Dzięki! Właśnie testuję dedukcję parametrów template'ów :)
  • #179
    Grizzly16
    Level 14  
    Skompilowało się w sumie bez problemów. Po ostatnich fix-ach z GDB pewnie będzie śmigać jak i poprzednie wersje, wiec w weekend będę testował intensywnie.

    Mam tylko małą prośbę/uwagę: Nie dało by się zrobić sprawdzenia czy wymagane programy pod linuxem są zainstalowane przed rozpoczęciem kompilacji?
    Myślałem, wczoraj, że wszystko mam a jednak "python" to "nie to samo" co "python2.7". Wiem, że pewnie dowiązanie symlink rozwiązało by sprawę ale nie pomyślałem o tym przed kompilacją i wykrzaczyła się bardzo późno.
    Druga sprawa czy można by wybierać ilość wątków do kompilacji w opcjach skryptu czy trzeba ręcznie modyfikować skrypt (ew. czy można, bo rozumiem, że nie każdy makefile pozwala na użycie wielu wątków)?
  • #180
    Freddie Chopin
    MCUs specialist
    Grizzly16 wrote:
    Nie dało by się zrobić sprawdzenia czy wymagane programy pod linuxem są zainstalowane przed rozpoczęciem kompilacji?
    Myślałem, wczoraj, że wszystko mam a jednak "python" to "nie to samo" co "python2.7". Wiem, że pewnie dowiązanie symlink rozwiązało by sprawę ale nie pomyślałem o tym przed kompilacją i wykrzaczyła się bardzo późno.

    Jeśli masz pomysł jak to zrobić, to nie ma problemu <: W sumie akurat GDB jest dosyć tolerancyjne jeśli chodzi o nazwę pliku pythona, chyba że coś tam pomieszałem, to może i się czepia jak cos nie jest w 100% standardowe.

    Grizzly16 wrote:
    Druga sprawa czy można by wybierać ilość wątków do kompilacji w opcjach skryptu czy trzeba ręcznie modyfikować skrypt (ew. czy można, bo rozumiem, że nie każdy makefile pozwala na użycie wielu wątków)?

    Generalnie skrypt powinien działać wielowątkowo na maksymalnej dostępnej ilości rdzeni, gdyż wszędzie jest coś na styl `make -j$(nproc)` https://github.com/FreddieChopin/bleeding-edg...e7581ef/build-bleeding-edge-toolchain.sh#L141

    No chyba że chodzi Ci właśnie o to, żeby _nie_ działał na maksymalnej ilości wątków, żeby nie przymulało kompa w czasie działania?