Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++

Freddie Chopin 26 Sep 2019 15:02 36333 255
Computer Controls
  • #211
    adamusx
    Level 27  
    Cześć,
    Mam klika pytań :)
    Czy planujesz w najbliższym czasie zrobić wsparcie dla STM32H7?
    Posiadasz jakiś skonfigurowany projekt pod środowisko na bazie Eclipse (np Atollic TRUEStudio STM32) ?

    Jakie są też plany na rozwój tego rtosa? Rozwijasz go sam czy planujesz zaangażować jakąś społeczność do tego ?
    Pytam, bo system wydaje się bardzo ciekawy, jest świetną alternatywą do FreeRtosa i generalnie zastanawiam się nad użyciem go w pewnym dość dużym projekcie. Smutno by było, gdyby się okazało, że za rok czy trzy lata projekt tego systemu zostanie porzucony..
  • Computer Controls
  • #212
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    Czy planujesz w najbliższym czasie zrobić wsparcie dla STM32H7?

    Jeśli Ci na takowym wsparciu zależy, to mogę je dodać. Zwykle bazowe wsparcie dla nowej rodziny układów nie zajmuje długo. Problemem jest jednak to, że obecnie mam sporo rzeczy na głowie, a za 2 tygodnie jadę na trzytygodniowe wakacje, więc to wszystko może nieco odsunąć dodanie takiego wsparcia...

    adamusx wrote:
    Posiadasz jakiś skonfigurowany projekt pod środowisko na bazie Eclipse (np Atollic TRUEStudio STM32) ?

    Skonfigurowanego nie mam, ale mogę Ci coś wyczarować. Eclipse niestety nie ma porządnego wsparcia dla CMake'a, więc jest to trudniejsze niż by mogło być. Sam osobiście praktycznie nie używam już Eclipse, bo zbyt mocno mnie irytuje (;

    adamusx wrote:
    Jakie są też plany na rozwój tego rtosa? Rozwijasz go sam czy planujesz zaangażować jakąś społeczność do tego ?

    Nie mam tak sprecyzowanych planów, gdyż cokolwiek bym sobie w takiej kwestii zaplanował, to nie mam na to żadnego wpływu. Projekt jest oczywiście open-source i ja jestem oczywiście otwarty na współpracę. Po prostu nie mam takiej współpracy "zaplanowanej", no bo jak miałbym taki plan zrealizować? Przecież nikogo nie zmuszę do takiej współpracy (;

    Co do planów takich ogólnych, to oczywiście są dalekosiężne (; Zapewne w niedługim czasie z projektem przejdę na C++17, gdyż oferuje on sporo fajnych rzeczy które będą mi potrzebne przy lepszym API dla wątków <: Wkrótce pojawi się być może wsparcie dla pamięci flash po SPI + jakiś flash-translation-layer, tak aby można było z takimi pamięciami używać wszystkich aktualnie obsługiwanych systemów plików (FAT + dwie wersje littlefs [choć ten ostatni ma niestety bardzo poważne ograniczenia które mocno zawężają obszar potencjalnych zastosowań]). Sporo dzieje się w kwestii integracji z innymi projektami, np. udało mi się dwa dni temu pogadać poprzez distortos i lwIP + mbed TLS z Microsoftową chmurą IoT czyli Azure (;

    adamusx wrote:
    Smutno by było, gdyby się okazało, że za rok czy trzy lata projekt tego systemu zostanie porzucony..

    Na razie nie planuję go porzucać i wszystko jest aktywnie rozwijane, choć może ruch mniejszy niż na samym początku. Niemniej jednak oczywiście nie jestem Ci w stanie dać gwarancji co się stanie za rok, dwa czy trzy, bo tego nikt nie wie (; W każdym razie system z pewnością działa tak jak należy, czyli stabilnie <:
  • #213
    adamusx
    Level 27  
    Freddie Chopin wrote:
    Skonfigurowanego nie mam, ale mogę Ci coś wyczarować. Eclipse niestety nie ma porządnego wsparcia dla CMake'a, więc jest to trudniejsze niż by mogło być. Sam osobiście praktycznie nie używam już Eclipse, bo zbyt mocno mnie irytuje (;
    Freddie Chopin wrote:
    Skonfigurowanego nie mam, ale mogę Ci coś wyczarować. Eclipse niestety nie ma porządnego wsparcia dla CMake'a, więc jest to trudniejsze niż by mogło być. Sam osobiście praktycznie nie używam już Eclipse, bo zbyt mocno mnie irytuje (;


    Czy wsparcie dla CMake jest w tym przypadku potrzebne ? Załóżmy, że całość ma się kompilować w AtollicStudio (lub nowym wynalazku STM STM32CubeIDE) dla konkretneo typu mikrokontrolera. CMake posłuży tylko do wygenerowania pliku konfiguracyjnego oraz skryptu linkera. Pozostaje przygotowanie makefile lub po prostu skonfigurowanie projektu we wspomnianym wyżej środowisku przez dodanie właściwych plików i określenie ścieżek dla includów.
  • #214
    Freddie Chopin
    MCUs specialist
    Wsparcie dla CMake'a w IDE nie jest konieczne, ale po prostu gdyby było, to pewnie projekt by się konfigurowało trzema kliknięciami (np. w KDevelop autentycznie można tak właśnie zrobić). Jako że w Eclipse wsparcie dla CMake'a robił ktoś, kto w życiu na oczy nie widział cross-kompilacji, to całe to wsparcie się do niczego nie nadaje w przypadku mikrokontrolerów. Z tego względu trzeba sobie to po prostu skonfigurować jako "makefile project" (co wcale nie znaczy, że trzeba używać make'a - można użyć ninja). Ścieżek include i definicji też nie trzeba ustawiać ręcznie, wystarczy tak skonfigorować Eclipse'a, żeby sobie te rzeczy wykrył sam.

    Osobiście _NIE_ zalecam prób pominięcia CMake'a w distortos, a wiec na pewno nie polecałbym prób ustawienia takiego projektu jako "natywnego" w danym IDE - tzn. takiego, że to IDE samo generuje odpowiednie pliki i możesz sobie "wyklikać" odpowiednie opcje/flagi z GUI w parametrach projektu. Takie coś może się udać tylko pod warunkiem, że nigdy w życiu nie zmienisz żadnej opcji konfiguracyjnej samego RTOSa. Zresztą konfiguracja takiego projektu to z pewnością byłoby 5x tyle roboty co z wykorzystaniem CMake'a i Ninja <:

    Powtórzę, bo to istotne. NIE polecam prób pomijania CMake'a i robienia systemu budowania samodzielnie. Naprawdę!

    Na stronie projektu jest artykuł o konfiguracji projektu w Eclipse:
    http://distortos.org/documentation/creating-configuring-project-eclipse/
    Artykuł niestety jest lekko przestarzały i nie został zaktualizowany do najnowszej wersji projektu, która używa CMake'a (przyznaję z bólem, że tworzenie dokumentacji nie jest moim ulubionym zajęciem, a gdy ta ma mieć formę czytelnego artykułu, to już jest naprawdę dużo roboty...). Niemniej jednak zasadniczo wygląda to bardzo podobnie, z tym że zamiast "make menuconfig" trzeba sobie odpalić cmake-gui i skonfigurować folder kompilacji (o czym info można znaleźć w innym artykule - http://distortos.org/documentation/configuring-building/ - ten jest zaktualizowany (; ). Druga różnica jest taka, że w opcjach projektu trzeba ustawić odpowiednią ścieżkę w której wykonywana jest kompilacja. Jak coś, to mogę spróbować ten artykuł zaktualizować - tak naprawdę zacząłem to robić w maju, ale coś mnie wtedy mocno zirytowało (chyba Eclipse ze swoimi durnymi nowymi problemami lub coś w ten deseń) i nie skończyłem...
  • #215
    adamusx
    Level 27  
    W takim razie podejdę do tematu od drugiej strony - jakiego środowiska do pracy z STM oraz distortos polecasz, albo czego sam używasz ? :)

    Może wynika to z mojej niewiedzy, ale w moim odczuciu kompilowanie projektu z użyciem cmake + ninja sprawdza się np. przy generowaniu bibliotek, gdzie po zmianie parametrów i nie ingerowaniu w sam kod szybko można wygenerować nową bibliotekę czy plik wsadowy do uC.
    Jednak przy tworzeniu konkretnej aplikacji na uC od zera, gdzie często popełnia się błędy w kodzie, chociażby typu literówki itp, gotowe IDE znacznie ułatwia znalezienie takiego błędu czy ostrzeżenia (po kliknięciu w konsoli na konkretny błąd przenosi w to miejsce). Druga sprawa to debugger ze wsparciem dla konkretnego typu mikrokontrolera, pokazujący wartości rejestrów peryferiów i inne narzędzia wspomagające debugowanie. Stąd też wydaje mi się, że korzystanie z gotowego IDE w takich przypadkach jest znacznie wygodniejsze...
  • #216
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    jakiego środowiska do pracy z STM oraz distortos polecasz, albo czego sam używasz ?

    Osobiście używam teraz Visual Studio Code. Eclipse oczywiście też jak najbardziej się nadaje i pewnie gdybym musiał coś konkretnego polecić, to wciąż byłoby to Eclipse (; Po prostu mnie akurat wybitnie już irytuje <:

    adamusx wrote:
    Może wynika to z mojej niewiedzy, ale w moim odczuciu kompilowanie projektu z użyciem cmake + ninja sprawdza się np. przy generowaniu bibliotek, gdzie po zmianie parametrów i nie ingerowaniu w sam kod szybko można wygenerować nową bibliotekę czy plik wsadowy do uC.
    Jednak przy tworzeniu konkretnej aplikacji na uC od zera, gdzie często popełnia się błędy w kodzie, chociażby typu literówki itp, gotowe IDE znacznie ułatwia znalezienie takiego błędu czy ostrzeżenia (po kliknięciu w konsoli na konkretny błąd przenosi w to miejsce).

    Jedno nie wyklucza drugiego. Projekt w którym budowanie oparte jest na CMake można zintegrować z (prawie) każdym IDE - w tym z Eclipse - tak abyś miał parsowanie tego co pojawia się w konsoli. Dzięki temu parsowaniu Eclipse np. potrafi sam wykryć ścieżki include i definicje preprocesora, a do tego oczywiscie wyszukuje komunikaty błędów/ostrzeżeń i łączy je z konkretnym miejscami w kodzie. Wszystko o czym wspomniałeś zadziała zarówno w "natywnym" projekcie dla danego IDE jak i w projekcie budowanym przez CMake i (np.) ninja.

    adamusx wrote:
    Druga sprawa to debugger ze wsparciem dla konkretnego typu mikrokontrolera, pokazujący wartości rejestrów peryferiów i inne narzędzia wspomagające debugowanie. Stąd też wydaje mi się, że korzystanie z gotowego IDE w takich przypadkach jest znacznie wygodniejsze...

    Tutaj jest tak samo. Jeśli skonfigurujesz sobie taki projekt w Eclipse to budowany będzie przez CMake i ninja, a debugger będzie działał tak samo dobrze jak w każdym innym przypadku.

    Moja propozycja jest taka, że jeśli chcesz to odpalić, to możemy się umówić na sesję na jakimś czacie/komunikatorze (albo i przez telefon) i w 15 minut będziesz miał działający projekt (; Tylko najlepiej by było, gdybyś miał jakąś płytkę rozwojową która jest od razu wspierana przez wersję która jest w repozytorium ( https://github.com/DISTORTEC/distortos/tree/master/configurations ), ewentualnie jakąś bardzo podobną. Po prostu zrobienie artykułu to jednak sporo roboty i pewnie gdybym do tego siadł, to i tak kilka dni by z tym zeszło. Za to przez komunikator moje porady nie muszą być wyłożone piękną i poprawną angielszczyzną, nie muszą być wzbogacone o pełen zestaw ładnie przyciętych screenshotów i nie muszą być pięknie sformatowane, więc pójdzie znacząco szybciej.
  • Computer Controls
  • #217
    adamusx
    Level 27  
    Dzięki za wyjaśnienia, trochę się temat rozjaśnia :)

    Jak się ma jednak to
    Freddie Chopin wrote:
    ...Eclipse niestety nie ma porządnego wsparcia dla CMake'a, więc jest to trudniejsze niż by mogło być. Sam osobiście praktycznie nie używam już Eclipse, bo zbyt mocno mnie irytuje (;

    oraz
    Freddie Chopin wrote:
    ... Jako że w Eclipse wsparcie dla CMake'a robił ktoś, kto w życiu na oczy nie widział cross-kompilacji, to całe to wsparcie się do niczego nie nadaje w przypadku mikrokontrolerów


    do tego:
    Freddie Chopin wrote:
    Jedno nie wyklucza drugiego. Projekt w którym budowanie oparte jest na CMake można zintegrować z (prawie) każdym IDE - w tym z Eclipse - tak abyś miał parsowanie tego co pojawia się w konsoli. Dzięki temu parsowaniu Eclipse np. potrafi sam wykryć ścieżki include i definicje preprocesora, a do tego oczywiscie wyszukuje komunikaty błędów/ostrzeżeń i łączy je z konkretnym miejscami w kodzie. Wszystko o czym wspomniałeś zadziała zarówno w "natywnym" projekcie dla danego IDE jak i w projekcie budowanym przez CMake i (np.) ninja.


    Dla mnie robienie dokumentacji i opisów to też męka, także doskonale rozumiem :) Pomysł z czatem jest jak najbardziej ok, ale może najpierw byłbyś w stanie skonfigurować projekt pod Eclipse (najlepiej pod Atollic TRUEStudio), na podstawie którego spróbuje rozkminić co i jak, a potem w razie problemów i pytań zgłoszę się o pomoc, nie chcę zabierać dużo czasu :)
    Chyba, że wymaga to zmian ustawień w samym Eclipse wraz z instalacją dodatków, a nie tylko konfiguracja samego projektu. Obecnie mogę to przetestować na stm32f429-DISCOVERY.
  • #218
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    Jak się ma jednak to ...

    Po prostu gdyby w Eclipse było zrobione porządne wsparcie dla CMake'a, to projekt pewnie konfigurowałbyś trzema kliknięciami. A skoro go nie ma, to tych kliknięć jest wielokrotnie więcej, bo projekt musisz skonfigurować "ręcznie", jako projekt "makefile project". "makefile project" to jest taki projekt w którym Eclipse po prostu nie zajmuje się generowaniem systemu budowania, a gdy naciśniesz "build all" to uruchamiany jest w wybranym folderze nowy proces którego dokładne wywołanie (komendę, argumenty, ...) sobie ustawiasz. W przypadku projektu z CMake i ninja ustawiasz wiec jakiś podfolder który wybrałeś do budowania (ja używam zwykle "output") i za komendę wpisujesz "ninja -v". Jeślibyś używał make'a zamiast ninja, to po prostu komendę wpisujesz "make" (a raczej zostawiasz domyślną) i tyle. Nie jest to jakiś wielki dramat, ale jednak można byłoby to zrobić lepiej, zwłaszcza, że CMake to nie jest jakiś egzotyczny program którego nikt nie używa.

    adamusx wrote:
    Pomysł z czatem jest jak najbardziej ok, ale może najpierw byłbyś w stanie skonfigurować projekt pod Eclipse (najlepiej pod Atollic TRUEStudio), na podstawie którego spróbuje rozkminić co i jak, a potem w razie problemów i pytań zgłoszę się o pomoc, nie chcę zabierać dużo czasu

    Możemy tak spróbować zrobić, z tym że Eclipse przy przenoszeniu projektów w zupełnie inne miejsce lubi mocno protestować (bo sobie np. wewnętrznie w parametrach projektu zapisuje niekiedy pełne ścieżki zamiast ścieżek względnych). No ale zobaczymy - przygotuję Ci takiego migacza diodką dla Eclipse'a i to powinno się dać zaimportować w Atollic. Mam też zainstalowane tymczasowo STM32CubeIDE, to mogę od razu działać w tym. Atollica akurat nie mam <:

    adamusx wrote:
    Chyba, że wymaga to zmian ustawień w samym Eclipse wraz z instalacją dodatków, a nie tylko konfiguracja samego projektu.

    Jeśli używałbyś czystego Eclipse, to potrzebny Ci jest ewentualnie tylko jeden dodatek do debuggowania, czyli "GDB Hardware Debugging". W przypadku Atollic/STM32CubeIDE żaden dodatek nie będzie potrzebny.
  • #219
    adamusx
    Level 27  
    Możemy być STM32CubeIDE. Czekam w takim razie za przykładem, zobaczymy co z tego wyjdzie ;)
  • #220
    Freddie Chopin
    MCUs specialist
    No dobra. Coś mam. Nie udało się tego zrobić na STM32CubeIDE, ponieważ wejście do opcji projektu (prawym na projekt > Properties) a następnie do istotnych C/C++ General > Preprocessor Include Paths, Macros etc. powoduje u mnie pojawienie się okienka z błędem że "The currently displayed page contains invalid values" i tyle mogę sobie tam pozmieniać...

    Projekt jest więc zrobiony na czyste Eclipse. Z dużym prawdopodobieństwem da się go zaimportować zarówno do Atollic jak i do STM32CubeIDE, ale czy po tej operacji będzie się dało zobaczyć co jest ustawione akurat w tych opcjach - nie wiem. Rzeczy które można tam znaleźć są właśnie kluczowe aby Eclipse było w stanie prawidłowo sparsować projekt (tzn. np. prawidłowo podpowiadać nagłówki systemowe i nagłówki z projektu, odpowiednio rozumiało makra itd.).

    Nie wiem czy używasz Linuxa czy Windowsa, więc profilaktycznie wysyłam dwie wersje (w wersji dla Linuxa z nazwy trzeba usunąć ".zip" - bez takiej dodatkowej końcówki nie dało się wysłać pliku na forum). Zasadniczo różnią się tym, że wersja dla Linuxa ma ustawione niektóre skrypty jako wykonywalne, co jest istotne gdybyś np. chciał generować płytkę czy robić coś w ten deseń.

    ST_32F429I...blinker.7z Download (1.4 MB)
    ST_32F429I...tar.xz.zip Download (1.41 MB)

    Warto może jeszcze dodać, że projekty z distortos należy kompilować TYLKO przy użyciu bleeding-edge-toolchain. Próba użycia domyślnego toolchaina od ARMa (albo toolchaina domyślnie dostępnego w STM32CubeIDE / Atollic) z pewnością źle się skończy.

    https://github.com/FreddieChopin/bleeding-edge-toolchain

    Aby tego użyć:
    0. Rozpakować sobie to gdzieś (;
    1. Otwierasz swoje IDE
    2. File > Import... > General > Existing Projects into Workspace, klikasz Next, wybierasz ścieżkę do rozpakowanego projektu, zaznaczasz w Options checkboxa przy Copy projects into workspace i klikasz Finish.
    3. Tworzysz sobie folder w którym będzie to kompilowane, polecam na razie zostać przy "output", bo właśnie na taki folder jest skonfigurowany projekt.
    4. Z konsoli systemowej wchodzisz do stworzonego właśnie folderu i wpisujesz:
    cmake -C ../distortosConfiguration.cmake .. -G"Unix Makefiles"
    Klikasz ENTER. Powinno się wyświetlić mniej-więcej coś takiego:
    Code:
    $ cmake -C ../distortosConfiguration.cmake .. -G"Unix Makefiles"
    
    loading initial cache file ../distortosConfiguration.cmake
    -- The C compiler identification is GNU 9.2.0
    -- The CXX compiler identification is GNU 9.2.0
    -- Check for working C compiler: /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-gcc
    -- Check for working C compiler: /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-gcc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Check for working CXX compiler: /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-g++
    -- Check for working CXX compiler: /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-g++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Generating /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/distortos/distortosConfiguration.cmake
    -- Generating /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/distortos/include/distortos/distortosConfiguration.h
    -- Generating /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/distortos/ST_32F429IDISCOVERY.preprocessed.ld
    -- Generating /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/.gitignore
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output

    5. Wracasz do IDE. Project > Build All (albo Ctrl + B) i wszystko się pięknie kompiluje:
    Code:
    ...
    
    [ 98%] Building CXX object CMakeFiles/ST_32F429IDISCOVERY-blinker.dir/main.cpp.o
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-g++  -DLFS1_NO_DEBUG -DLFS1_NO_ERROR -DLFS1_NO_WARN -DLFS2_NO_DEBUG -DLFS2_NO_ERROR -DLFS2_NO_WARN -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/distortos/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/board/ST_32F429IDISCOVERY/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/peripherals/GPIOv2/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/peripherals/SPIv1/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/peripherals/USARTv1/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/peripherals/DMAv2/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/STM32F4/../include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/STM32F4/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/chip/STM32/STM32F4/external/CMSIS-STM32F4 -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/include -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/FileSystem/FAT/external/uFAT -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/FileSystem/littlefs1/external/littlefs1 -I/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/distortos/source/FileSystem/littlefs2/external/littlefs2  -fno-rtti -fno-exceptions -ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -Wno-psabi -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mfloat-abi=hard -fno-use-cxa-atexit -O2 -g -ggdb3   -o CMakeFiles/ST_32F429IDISCOVERY-blinker.dir/main.cpp.o -c /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/main.cpp
    [100%] Linking CXX executable ST_32F429IDISCOVERY-blinker.elf
    /usr/bin/cmake -E cmake_link_script CMakeFiles/ST_32F429IDISCOVERY-blinker.dir/link.txt --verbose=1
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-g++  -fno-rtti -fno-exceptions -ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -Wno-psabi -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mfloat-abi=hard -fno-use-cxa-atexit -O2 -g -ggdb3  -Wl,--gc-sections CMakeFiles/ST_32F429IDISCOVERY-blinker.dir/main.cpp.o  -o ST_32F429IDISCOVERY-blinker.elf -T"/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/distortos/ST_32F429IDISCOVERY.preprocessed.ld" -Xlinker -Map="/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.map" -Wl,--whole-archive distortos/libdistortos.a distortos/libuFAT.a distortos/liblittlefs1.a distortos/liblittlefs2.a -Wl,--no-whole-archive
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-objcopy -O binary /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf ST_32F429IDISCOVERY-blinker.bin
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-objdump -x --syms --demangle /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf > ST_32F429IDISCOVERY-blinker.dmp
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-objcopy -O ihex /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf ST_32F429IDISCOVERY-blinker.hex
    /home/freddie/arm-none-eabi-gcc-9.2.0-190812/bin/arm-none-eabi-objdump --demangle -S /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf > ST_32F429IDISCOVERY-blinker.lss
    arm-none-eabi-size -B /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf
       text      data       bss       dec       hex   filename
      15788      1260      6580     23628      5c4c   /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/ST_32F429IDISCOVERY-blinker.elf
    make[2]: Leaving directory '/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output'
    [100%] Built target ST_32F429IDISCOVERY-blinker
    make[1]: Leaving directory '/home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output'
    /usr/bin/cmake -E cmake_progress_start /home/freddie/STM32CubeIDE/workspace_1.0.2/ST_32F429IDISCOVERY-blinker/output/CMakeFiles 0

    19:37:16 Build Finished. 0 errors, 0 warnings. (took 9s.759ms)


    Na 100% coś nie będzie działać, więc pisz jakie efekty [;

    P.S. Konfiguracja projektu (to co można sobie wyklikać w cmake-gui) jest na razie identyczna z tą dla aplikacji testowej. Nie jest to może najbardziej optymalna wersja (spory stos, powłączane wiele różnych dodatków), więc jak ktoś jest wybitnie czuły na zajętość pamięci flash/RAM, to trzeba sobie to nieco zoptymalizować pod konkretną aplikację (;
  • #221
    adamusx
    Level 27  
    Hej,

    Ja w miedzy czasie też z tym walczyłem z pewnym sukcesem.
    Zaimportowałem przykład distortosExamples-20190505 do Eclipse, ustawiając ninja jako narzędzie kompilacji (oraz właściwą ścieżkę dla Build directory) i w sumie całość się skompilowała, a po wgraniu na Discovery... diody migają :). Wcześniej oczywiście skonfigurowałem całość za pomocą cmake. Wszysto byłoby by ok, gdyby nie konfiguracja i używanie debuggera z openocd w czystym Eclipse. Może kwestia przyzwyczajenia, ale uruchamianie za każdym razem openocd, a potem gdb trochę jest irytująca.

    Zaimportowałem więc przykład do STM32CubeID. Wybierając czysty projekt (podobnie jak w Eclipse) także pojawiały się błędy przy próbach wejść w niektóre ustawienia. Rozwiązaniem okazało się wybranie projektu STM32Project, wybranie konkretnego procesora, a następnie usuniecie wszystkich dodanych plików do projektu. Dopiero wówczas import projektu za katalogu, skonfigurowanie narzędzia budowania dla Ninja i całość działa łącznie z debuggerem po jednym kliknięciu :)

    Niestety występuje problem z widocznością makr. Prawdopodobnie kwestia ustawienia poprawnego parsowania - podejrzę jak zrobiłeś to w swoim przykładzie.

    PS1. Pracuje pod Win. Przy budowaniu konfiguracji także dodawać "Unix Makefiles" ??

    PS2. Jako toolchain póki co używam najnowszej wersji od arma (gcc-arm-none-eabi-8-2019-q3-update-win32). Wszystko buduje się bez błędów i ostrzeżeń, prosty przykład ze statycznym wątkiem także działa na płytce. Mimo wszystko sugerujesz przejść na Twoją wersję ?

    PS3. Narazie to może zbyt daleko idące pytanie, ale czy pożeniłeś już distortos z lwip lub innym stosem?
  • #222
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    uruchamianie za każdym razem openocd

    Akurat OpenOCD nie trzeba uruchamiać za każdym razem. Ono sobie może chodzić cały czas. Nie ma najmniejszej potrzeby aby zamykać akurat ten program.

    adamusx wrote:
    Prawdopodobnie kwestia ustawienia poprawnego parsowania - podejrzę jak zrobiłeś to w swoim przykładzie.

    Zobacz jak jest ustawiony "build output parser" w tym problematycznym miejscu właściwości projektu. Drugą - kluczowo ważną! - rzeczą jest to, że musisz całość kompilować w trybie "verbose". Dla make'a dodajesz więc do wywołania `VERBOSE=1`, a dla ninja dodajesz `-v` (czyli w konfiguracji narzędzia po prostu masz `ninja -v` zamiast samo `ninja`). Wtedy w konsoli masz pełne wywołania kompilatora które Eclipse może sobie przeparsować.

    Drugą rzeczą która wpływa na indexer jest "built-in compiler settings".

    W artykule który wcześniej wspominałem - http://distortos.org/documentation/creating-configuring-project-eclipse/ - jedna i druga kwestia są opisane i to jest akurat wciąż aktualne, więc możesz się posiłkować tym opisem. Jeśli masz problem przy projekcie który zaimportowałeś ode mnie, to być może jest to właśnie kwestia tego, że u mnie wykryło jakieś tam ścieżki, które u Ciebie nie istnieją, no i teraz będzie się czepiał do końca świata i dzień dłużej. Zwykle pomaga na coś takiego wybranie opcji "Clear Entries" przy tych dwóch parserach - wtedy Eclipse sobie od nowa wczyta co trzeba. Czy to jest tego typu sytuacja to można sprawdzić, jak podejrzysz co tam Eclipse zaindexował dla jakiegoś pliku (np. głównego main.cpp) - jak masz tam jakieś ścieżki z kosmosu, to znaczy że to właśnie ten problem.

    adamusx wrote:
    PS1. Pracuje pod Win. Przy budowaniu konfiguracji także dodawać "Unix Makefiles" ??

    Tak, bo na Windowsa domyślnie Ci wybierze jakieś durne narzędzie którego pewnie nie masz (; Albo "Unix Makefiles", albo "Ninja" - innych zasadniczo nie testowałem (no może poza generatorem projektów dla Eclipse, który w ogóle nie działa (; ), może działają, a może nie.

    adamusx wrote:
    PS2. Jako toolchain póki co używam najnowszej wersji od arma (gcc-arm-none-eabi-8-2019-q3-update-win32). Wszystko buduje się bez błędów i ostrzeżeń, prosty przykład ze statycznym wątkiem także działa na płytce. Mimo wszystko sugerujesz przejść na Twoją wersję ?

    Toolchainy od ARMa mają zupełnie inną konfigurację bibliotek i newliba. Przede wszystkim mają włączone wyjątki i RTTI w samych bibliotekach, więc jak tylko zaczniesz używać czegokolwiek bardziej zaawansowanego, to Twój projekt dostanie bonusowe 50-100 kB zajętości flasha na wyjątki C++. To jest główny powód dla którego warto zmienić toolchaina. Pozostałe nie są aż tak istotne, choć sprowadzają się z grubsza do tego samego (np nieco bardziej pasująca do mikrokontrolerów - moim zdaniem - konfiguracja newliba).

    adamusx wrote:
    PS3. Narazie to może zbyt daleko idące pytanie, ale czy pożeniłeś już distortos z lwip lub innym stosem?

    Tak. Na githubie jest gotowe repo z integracją do lwIP i z integracją dla HALa od ST (aby mieć driver ETH) - akurat tylko z tym dla F7, ale dla innych będzie to zasadniczo +/- identyczne. Mogę spróbować też przygotować jakiś przykładowy projekt jeśli napiszesz czego byś potrzebował. Integracja z lwIP i z HALem jest też w tym projekcie (ale tam akurat nie ma ETH) - https://github.com/DISTORTEC/STM32F7-USB-host-ME906-lwIP-MQTT Tak naprawdę zacząłem też przygotowywać sobie projekt podobny do tego wyżej, ale bez tego modemu GSM - po prostu po ETH, aby każdy sobie mógł przetestować - ale na razie sprawa oczywiście stanęła w miejscu.

    https://github.com/DISTORTEC/lwIP-integration
    https://github.com/DISTORTEC/STM32F7xx_HAL_Driver-integration

    Każde pytanie jest dobre więc pytaj (; Ten projekt naprawdę nie jest taką zabawką na której się nic nie da zrobić - jak już pisałem obecnie pracuję nad aplikacją która ma aż tyle podmodułów:
    Code:
    drwxr-xr-x 21 freddie freddie 4096 09-19 10:19 azure-iot-sdk-c
    
    drwxr-xr-x  2 freddie freddie 4096 09-23 11:45 azure-iot-sdk-c-integration
    drwxr-xr-x 10 freddie freddie 4096 09-20 12:56 distortos
    drwxr-xr-x  6 freddie freddie 4096 07-23 10:13 FreeMODBUS
    drwxr-xr-x  3 freddie freddie 4096 09-12 10:51 FreeMODBUS-integration
    drwxr-xr-x  7 freddie freddie 4096 07-17 09:59 lwIP
    drwxr-xr-x  3 freddie freddie 4096 08-16 13:15 lwIP-integration
    drwxr-xr-x 12 freddie freddie 4096 09-20 13:07 mbed-TLS
    drwxr-xr-x  3 freddie freddie 4096 09-27 14:22 mbed-TLS-integration
    drwxr-xr-x  9 freddie freddie 4096 2018-08-27  mbmaster
    drwxr-xr-x  2 freddie freddie 4096 2018-08-27  pycrc
    drwxr-xr-x  4 freddie freddie 4096 07-16 13:17 STM32F7xx_HAL_Driver
    drwxr-xr-x  2 freddie freddie 4096 08-16 13:15 STM32F7xx_HAL_Driver-integration
    drwxr-xr-x  4 freddie freddie 4096 07-16 12:01 STM32_USB_Device_Library


    Jakby się ktoś zastanawiał, Azure jest dramatyczny <:
  • #223
    adamusx
    Level 27  
    Modbus RTU i TCP mnie interesuje :)
    Docelowo też CanOpen. Samą bibliotekę CANopen (https://github.com/CANopenNode/CANopenNode ) mam już przetestowaną, ale do tej pory bez rtosa.
    Ponadto obsługa fat, sdcard oraz pamieć flash (najlepiej po qspi). W dalszej przyszłości może EtherCat, ale nie wiem czy F7/H7 bez zewnętrznego kontrolera sobie z tym poradzą.

    Jakie narzędzie w takim razie lepiej używać do budowania projektu make czy ninja ? Oby dwa z tego co widzę działają z Eclipse, tylko make kompiluje w jakieś 30 sekund, a ninja w 15 ...
  • #224
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    Modbus RTU i TCP mnie interesuje

    Jeśli jako slave, to FreeMODBUS (z modyfikacjami, dosyć karkołomnymi, które umożliwiają wieloinstancyjność) jest gotowy, testowany w trybie RTU i TCP. Jeśli jako master, to używam komercyjnej biblioteki mbmaster - integrację do niej mogę udostępnić, samej biblioteki niezbyt. Tą testowałem tylko jako RTU.

    adamusx wrote:
    Ponadto obsługa fat, sdcard oraz pamieć flash (najlepiej po qspi).

    No to pierwsze dwa gotowe - biblioteka uFAT + karta SD zarówno po SPI jak i po SDIO/SDMMC, dodatkowo magiczna klasa buforująca operacje, która realnie daje przyspieszenie o rząd wielkości. Pamięć flash po QSPI - brak sterownika. Wkrótce będę musiał dodać taki driver dla pamięci flash, ale po zwyczajnym SPI.

    Przy okazji - mocno zalecam używanie wersji wprost z repozytorium (np. jako submodułu git), szczególnie jeśli chcesz używać integracji z lwIP czy np. wymienionych wyżej niektórych nowości (choćby system plików FAT). W ostatnim stabilnym wydaniu 0.7.0 niektórych z tych rzeczy jeszcze nie ma.

    Przy okazji 2 - integracja systemu plików nie jest jeszcze idealna (np. nie zadziała funkcja fopen/open oraz te najbardziej bazowe read/write), ale przy użyciu funkcji `distortos::openFile()` można otrzymać piękny i w pełni funkcjonalny obiekt `FILE*`, używalny z (chyba) wszystkimi funkcjami które taki obiekt akceptują. W zalinkowanym wcześniej projekcie (tym z modemem GSM) jest też pokazane jak sobie opakować USB CDC albo port szeregowy (klasę `SerialPort`) w `FILE*`, tak aby można było używać np. `fprintf()` czy `fscanf()`.

    adamusx wrote:
    Jakie narzędzie w takim razie lepiej używać do budowania projektu make czy ninja ? Oby dwa z tego co widzę działają z Eclipse, tylko make kompiluje w jakieś 30 sekund, a ninja w 15 ...

    Jeśli dla make'a włączyłeś opcję Properties > C/C++ Build > Behavior > Enable parallel build i dalej jest znacząco wolniej, no to chyba masz odpowiedź, no nie? (; Ja używam Ninja, w poście wyżej opisywałem użycie z "Unix Makefiles", bo na początek wolałem nie przesadzać z ilością nowości [; Jeśli Ci to obojętne, to ja bym używał szybszego narzędzia, czyli Ninja. Sprawdza się i działa bardzo dobrze.
  • #225
    adamusx
    Level 27  
    Freddie Chopin wrote:
    Jeśli jako slave, to FreeMODBUS (z modyfikacjami, dosyć karkołomnymi, które umożliwiają wieloinstancyjność) jest gotowy, testowany w trybie RTU i TCP. Jeśli jako master, to używam komercyjnej biblioteki mbmaster - integrację do niej mogę udostępnić, samej biblioteki niezbyt. Tą testowałem tylko jako RTU.


    Master, mam w sumie własną implementację RTU/TCP, ale także bez RTOSa.

    Freddie Chopin wrote:
    No to pierwsze dwa gotowe - biblioteka uFAT + karta SD zarówno po SPI jak i po SDIO/SDMMC, dodatkowo magiczna klasa buforująca operacje, która realnie daje przyspieszenie o rząd wielkości. Pamięć flash po QSPI - brak sterownika. Wkrótce będę musiał dodać taki driver dla pamięci flash, ale po zwyczajnym SPI.

    Będę zatem testował :)

    Freddie Chopin wrote:
    Jeśli dla make'a włączyłeś opcję Properties > C/C++ Build > Behavior > Enable parallel build i dalej jest znacząco wolniej, no to chyba masz odpowiedź, no nie? (; Ja używam Ninja, w poście wyżej opisywałem użycie z "Unix Makefiles", bo na początek wolałem nie przesadzać z ilością nowości [; Jeśli Ci to obojętne, to ja bym używał szybszego narzędzia, czyli Ninja. Sprawdza się i działa bardzo dobrze.

    W obu przypadkach budowanie równoległe, także różnica w prędkości kolosalna.
    Myślałem, że make jest bardziej "kompatybilne" z Eclipse, ale skoro nie ma to znaczenia to przechodzę na Ninja :)

    PS. Po ustawieniach build output parser oraz built-in compiler settings nadal nie widzi właściwego define np typu DISTORTOS_BOARD_LEDS_LD3_ENABLE, a to wynika pewnie z tego, że plik "distortos/distortosConfiguration.h" uparcie widzi w katalogu "unit-test/include-mocks/DistortosConfiguratio.h..." zamiast z "output\distortos\include\distortos"
    Na dziś niestety muszę zakończyć testy, wrócę do tematu po weekendzie.
  • #226
    Freddie Chopin
    MCUs specialist
    adamusx wrote:
    Po ustawieniach build output parser oraz built-in compiler settings nadal nie widzi właściwego define np typu DISTORTOS_BOARD_LEDS_LD3_ENABLE, a to wynika pewnie z tego, że plik "distortos/distortosConfiguration.h" uparcie widzi w katalogu "unit-test/include-mocks/DistortosConfiguratio.h..." zamiast z "output\distortos\include\distortos"
    Na dziś niestety muszę zakończyć testy, wrócę do tematu po weekendzie.

    Napisz z którego pliku oglądasz to makro. Jeśli chciałbyś zobaczyć jego rozwinięcie w jakimś pliku nagłówkowym, to jest to niestety (moim zdaniem) jedna z przypadłości Eclipse'a, że w takiej sytuacji "nie ogarnie" i trzeba by mu pomóc np. ręcznymi ustawieniami dla całego projektu. Jeśli nie widzi tego w jakimś pliku źródłowym, to zobacz co Eclipse dla tego dokładnie pliku zaindexował - czy masz tam wszystkie potrzebne ścieżki itd.

    Może po prostu musisz zrobić clean, a potem build all? Jeśli wcześniej miałeś zbudowany projekt i dopiero potem ustawiłeś "build output parser", albo dopiero później właczyłeś tryb "verbose" kompilacji, no to Eclipse po prostu nie miał jeszcze okazji zobaczyć wywołania kompilatora dla danego pliku (bo on już był zbudowany). Po przebudowaniu całego projektu może akurat przejść, jeśli to ten problem.

    Generalnie taki to właśnie jest ten Eclipse, zawsze coś w nim nie działa tak do końca i w pełni <: Choć trzeba mu przyznać, że debugger ma pod wieloma względami fajniejszy, klient gita też jest moim zdaniem nie do przebicia (choć tam też bugów do wyboru i do koloru...).
  • #227
    arcyimperator
    Level 14  
    Witam,
    mój Distortosowy projekt ma problem z rozmiarem binarki. W tej chwili Distortos + USB host + FatFS zajmują ok 50kb. Co ciekawe te komponenty któr wymieniłem kończą się na 26kB. Z tego co widzę bardzo dużo miejsca zajmuja dołączane biblioteki. proszę o pomoc/analizę jak mogę zredukować rozmiar aplikacji.

    Załączam fragment pliku .lss (zaraz wrzucę osobno...) oraz info z arm-non-eabi.


    Code: bash
    Log in, to see the code


    Dodano po 16 [minuty]:

    Plik .lss
  • #228
    Freddie Chopin
    MCUs specialist
    Rozumiem, że wynikowy plik binarny jest za duży dla Twojego układu, tak? 50 kB na taki projekt to przecież nie jest jakoś specjalnie dużo. Czy może chodzi o coś innego?

    Warto też dodać, że obecnie wersja master w distortos ma lepsze wsparcie dla systemów plików oraz wsparcie dla systemu plików FAT (choć akurat nie przy użyciu FatFs, tylko biblioteki uFAT). W sumie ostatnio dodałem też na githuba repo w którym jest forknięta biblioteka USB Host od ST oraz biblioteka HAL od ST (dla STM32F7) - obie z poprawkami, dzięki którym to w ogóle działa. Do tego dwa repozytoria z integracją dla tych dwóch bibliotek. Nie jest to może jeszcze wybitnie spójne (finalny "model" się jeszcze wypracowywuje), niemniej jednak zawsze to jakiś punkt zaczepienia.

    Wrzuć lepiej konfigurację projektu (plik distortosConfiguration.cmake, który znajdziesz w podfolderze distortosa folderu kompilacji (np. output/distortos/distortosConfiguration.cmake lub coś w ten deseń) oraz wynik takiej oto komendy - `arm-none-eabi-nm -ClS --radix=d --size-sort tutaj-nazwa-twojego-pliku.elf`
  • #229
    arcyimperator
    Level 14  
    Freddie Chopin wrote:
    50 kB na taki projekt to przecież nie jest jakoś specjalnie dużo.

    uyheeyeyyyyy, nie? 24kb na biblioteki (c) wydaje mi się dość sporo...

    Freddie Chopin wrote:
    wynik takiej oto komendy - `arm-none-eabi-nm -ClS --radix=d --size-sort tutaj-nazwa-twojego-pliku.elf`

    To bardzo fajna komenda, wklejam końcówkę bo Elektroda nie puszcza:

    Code: bash
    Log in, to see the code
  • #230
    Freddie Chopin
    MCUs specialist
    arcyimperator wrote:
    uyheeyeyyyyy, nie? 24kb na biblioteki (c) wydaje mi się dość sporo...

    Czemu? Zależy jakie biblioteki.

    Największą funkcja u Ciebie jest _svfprintf_r(), który sam zajmuje 5kB (+ sporo funkcji jest zapewne tylko dla niej, np. _dtoa_r() który zajmuje 3.5kB). Musisz zobaczyć co w Twoim kodzie używa funkcji sprintf() (bo svfprintf() jest używany właśnie jako baza dla sprintf()) lub podobnej (np. snprintf(), asnprintf() itd.) i po prostu się tego pozbyć. Ewentualnie zamiast się jej pozbywać, można używać funkcji siprintf() - działa tak samo, tylko nie obsługuje w ogóle zmiennego przecinka, dzięki czemu jest znacząco mniejsza. Co do kandydata, który by tego formatowania stringów używał, to obstawiam jakąś funkcję logującą.

    W samym distortos też można by pewnie nieco zminimalizować konfigurację, ale jeszcze nie przeglądałem tej Twojej.
  • #231
    osctest1
    Level 21  
    arcyimperator wrote:
    mój Distortosowy projekt ma problem z rozmiarem binarki. W tej chwili Distortos + USB host + FatFS zajmują ok 50kb.
    Ty to tak na poważnie czy to czysto teoretyczna dywagacja? STM-y z USB OTG poza kilkoma modelami (do drona sądząć po nazwie katalogu to chyba nie użyłeś takiego z 64 FLASH) mają min 128kB (a jeżeli wywalimy "odpadowe" H7 i F7) to min 256kB FLASH.

    Jak już mamy te wszystkie biblioteki - to dalej pamięć flash będzie rosła dużo wolniej. Jak nie będziesz wrzucać obrazków czy innych fontów 48pix ze wszystkimi znakami, to zajętość FLASH będzie dalej rosnąć już powoli, aby zapełnić pozostałe 200kB flash naprawdę trzeba napisać wiele dziesiątków tysięcy linii.

    Widać (a raczej można się domyśleć ) że linkujesz C bibliotekę nie "nano". Zobacz co się stanie jak zmienisz na nano C bibliotekę. Nie wiem jak w toolchainie @Freddie Chopin są zrobione i nazwane pliki .specs tak że nie podpowiem ale spróbuj "specs=nano.specs"


    Zresztą jest wiele "pico" implementacji - jęzeli nie używasz zaawansowanego formatowania np:

    Code: c
    Log in, to see the code
  • #232
    arcyimperator
    Level 14  
    Freddie Chopin wrote:
    Czemu? Zależy jakie biblioteki.

    Największą funkcja u Ciebie jest _svfprintf_r(), który sam zajmuje 5kB (+ sporo funkcji jest zapewne tylko dla niej, np. _dtoa_r() który zajmuje 3.5kB). Musisz zobaczyć co w Twoim kodzie używa funkcji sprintf() (bo svfprintf() jest używany właśnie jako baza dla sprintf()) lub podobnej (np. snprintf(), asnprintf() itd.) i po prostu się tego pozbyć


    Byłem świadomy że mam sprintf, ale nie wiedziałem że ona + koleżanki tyle zajmują. Cóż, odkrywam świat. Usunięcie sprintf zmniejszyło binarkę z 50 do 32kB (37kB z siprintf). Chyba obędę się bez tego:]

    osctest1 wrote:
    Ty to tak na poważnie czy to czysto teoretyczna dywagacja? STM-y z USB OTG poza kilkoma modelami (do drona sądząć po nazwie katalogu to chyba nie użyłeś takiego z 64 FLASH) mają min 128kB (a jeżeli wywalimy "odpadowe" H7 i F7) to min 256kB FLASH.

    Jak już mamy te wszystkie biblioteki - to dalej pamięć flash będzie rosła dużo wolniej. Jak nie będziesz wrzucać obrazków czy innych fontów 48pix ze wszystkimi znakami, to zajętość FLASH będzie dalej rosnąć już powoli, aby zapełnić pozostałe 200kB flash naprawdę trzeba napisać wiele dziesiątków tysięcy linii.


    Piszę bootloader na USB i mam limit 48kB, stąd walka o te kB. W tej chwili obędzie się bez tych bibliotek.
  • #233
    Freddie Chopin
    MCUs specialist
    arcyimperator wrote:
    Byłem świadomy że mam sprintf, ale nie wiedziałem że ona + koleżanki tyle zajmują. Cóż, odkrywam świat. Usunięcie sprintf zmniejszyło binarkę z 50 do 32kB (37kB z siprintf). Chyba obędę się bez tego:]

    Zgadzałoby się to z moimi starymi obserwacjami, że użycie tych funkcji w wersji bez "i" to około 20 kB. Czyli nic się nie zmieniło [; W każdym razie te z "i" wystarczają w 99% przypadków, a jak widziałeś zajmują 3-4x mniej.

    Wrzuć jeszcze raz wynik `arm-none-eabi-nm ...` to zobaczymy co jeszcze można przyciąć.

    Jak już soft będziesz miał dobrze sprawdzony, to może jeszcze kilka kilobajtów utniesz zmieniając nieco konfigurację distortos - można wyłaczyć wszystkie opcje distortos_Checks_... (teraz masz włączoną distortos_Checks_00_Context_of_functions i distortos_Checks_06_Asserts). Możesz sprawdzić build w opcji MinSizeRel zamiast RelWithDebInfo (przy okazji w CMAKE_CXX_FLAGS_RELEASE zmieniło Ci się domyślne -O2 na błędne -2).
  • #234
    arcyimperator
    Level 14  
    Freddie Chopin wrote:
    Jak już soft będziesz miał dobrze sprawdzony, to może jeszcze kilka kilobajtów utniesz zmieniając nieco konfigurację distortos - można wyłaczyć wszystkie opcje distortos_Checks_... (teraz masz włączoną distortos_Checks_00_Context_of_functions i distortos_Checks_06_Asserts). Możesz sprawdzić build w opcji MinSizeRel zamiast RelWithDebInfo (przy okazji w CMAKE_CXX_FLAGS_RELEASE zmieniło Ci się domyślne -O2 na błędne -2).


    Dzieki za czujność, już poprawiłem. Krótki test z wyrzuceniem opcji i zmianą konfiguracji na MinSizeRel dał wynik 27kB.

    Dziękuję serdecznie za pomoc
  • #235
    arcyimperator
    Level 14  
    Freddie Chopin wrote:
    Trochę tego tam używa - systick, pendsv, svc. Dodatkową (sporą) komplikacją jest też to, że distortos używa oczywiście dwóch stosów. Niemniej jednak w sytuacji skoku z bootloadera opartego na distortos do aplikacji opartej na distortos być może te rzeczy nie są takim dużym problemem, bo w końcu aplikacja też ich używa. Niemniej jednak np. systick powinien być jednak zatrzymany, bo inaczej może się odpalić wcześniej niż by tego chciała aplikacja. Do tego jeszcze - jak pisałem wcześniej - kod konfiguracji zegara w aplikacji najprawdopodobniej się "przytnie" gdy będzie próbował skonfigurować zegar po raz drugi. Jeśli finalnie też chcesz używać distortos w bootloaderze, to jest inna opcja zrobienia skoku do aplikacji z "nieskonfigurowanym" układem - może trochę prostsza niż próba wyłączenia wszystkiego co distortos włączył (jawnie lub nie).

    Cześć, wracam do tego tematu, niestety po skoku do Aplikacji z Bootloadera pojawia się dziwne zachowanie: zaczyna się wykonywać kod main() który jest przerwany i widzę w debugerze wykonywanie konstruktorów obiektów globalnych. Co może być tego przyczyna?
    W Bootloaderze przed skokiem, robię __disable_irq(), zatrzymuję Systicka, czyszczę peryferia, czyszczę RCC do reset state, __enable_irq(), skok do aplikacji.
    Coś z SVC, pendsv o których pisałeś?
    Jak wykonać opcję z nieskonfigurowanym układem? Jakaś nieulotna flaga i reset? Ale jak zatrzymać Distortos przed robieniem konfiguracji?
  • #236
    Freddie Chopin
    MCUs specialist
    arcyimperator wrote:
    po skoku do Aplikacji z Bootloadera pojawia się dziwne zachowanie: zaczyna się wykonywać kod main() który jest przerwany i widzę w debugerze wykonywanie konstruktorów obiektów globalnych.

    Możesz pokazać jak to wygląda w debuggerze? Te konstruktory wykonują się jakby z main() czy jakby z przerwania?

    arcyimperator wrote:
    W Bootloaderze przed skokiem, robię __disable_irq(), zatrzymuję Systicka, czyszczę peryferia, czyszczę RCC do reset state, __enable_irq(), skok do aplikacji.

    Tablica wektorów też przestawiona? (;

    arcyimperator wrote:
    Jak wykonać opcję z nieskonfigurowanym układem? Jakaś nieulotna flaga i reset? Ale jak zatrzymać Distortos przed robieniem konfiguracji?

    Można stworzyć initializer bardzo niskiego poziomu, który wykona się na samym początku Reset_Handler'a, nawet przed aktywacją dwóch stosów.

    Poniżej przykład wykorzystania tego mechanizmu do skoku do bootloadera "systemowego" STM32 (tego który jest wbudowany w układ):

    Code:
    #include "distortos/BIND_LOW_LEVEL_PREINITIALIZER.h"
    

    namespace
    {

    constexpr uint32_t systemMemoryBase {0x1fff0000};
    constexpr uint32_t startBootloaderKey {0xf2b70959}; // jakas randomowa wartosc
    uint32_t startBootloader __attribute__ ((section(".noinit")));

    }   // namespace

    void lowLevelPreinitializer()
    {
       if (startBootloader != startBootloaderKey)
          return;

       startBootloader = {};

       asm volatile
       (
             "   msr      msp, %[sp]      \n"
             "   bx      %[pc]         \n"

             ::   [sp] "r" (*reinterpret_cast<const uint32_t*>(systemMemoryBase)),
                [pc] "r" (*reinterpret_cast<const uint32_t*>(systemMemoryBase + 4))
       );
    }

    BIND_LOW_LEVEL_PREINITIALIZER(0, lowLevelPreinitializer);

    void requestBootloader()
    {
       startBootloader = startBootloaderKey;
       NVIC_SystemReset();
       __builtin_unreachable();
    }


    (funkcja requestBootloader() jest globalna)

    Warto pamiętać o ograniczeniach preinitializerów:

    Code:
     * Low-level preinitializers are executed before .bss and .data sections' initialization, before constructors for global
    
     * and static objects.
  • #237
    arcyimperator
    Level 14  
    Freddie Chopin wrote:
    arcyimperator napisał:
    po skoku do Aplikacji z Bootloadera pojawia się dziwne zachowanie: zaczyna się wykonywać kod main() który jest przerwany i widzę w debugerze wykonywanie konstruktorów obiektów globalnych.

    Możesz pokazać jak to wygląda w debuggerze? Te konstruktory wykonują się jakby z main() czy jakby z przerwania?


    Późnym wieczorem sprawdzę i napiszę
    [edit] Powodem był błąd w kodzie aplikacji- odnosiłem się do obiektu z za zakresu tablicy -dlatego działy sie "cuda"


    Freddie Chopin wrote:
    Tablica wektorów też przestawiona? (;

    "yes of course natürlich jawohl absolument", przestawiona :)
    Freddie Chopin wrote:
    Poniżej przykład wykorzystania tego mechanizmu do skoku do bootloadera "systemowego" STM32 (tego który jest wbudowany w układ):

    Czy to jest mechanizm w 100% pewny, w sensie zawarość RAMu nie zmieni się podczas resetu?
  • #238
    Freddie Chopin
    MCUs specialist
    arcyimperator wrote:
    Czy to jest mechanizm w 100% pewny, w sensie zawarość RAMu nie zmieni się podczas resetu?

    Sama z siebie nie, ale oczywiście trzeba uwzględniać inne ciekawe kwestie - np. jeślibyś tego chciał użyć w aplikacji, to ona zresetuje układ, potem zacznie się wykonywać Twój bootloader i on sobie może w tym .noinit (z punktu widzenia aplikacji) akurat mieć stos czy cokolwiek. Jeśli chcesz tego użyć w bootloaderze, to zadziała (;
  • #239
    adamusx
    Level 27  
    Cześć Freddie

    Dodałeś już może wsparcie dla serii STM32H7?
    Mam pod ręką płytkę NUCLEO-H743ZI (480MHz robi wrażenie :) .Na chwilę obecną testuje ją z FreeRTOS + LWIP, udaje się wyciągnąć ok 95 Mbps full duplex. Jednak chętnie wróciłbym do tematu distortosa i zastąpiłbym FreeRTOSa..
  • #240
    Freddie Chopin
    MCUs specialist
    Niestety jeszcze nie... Ale wszystko da się zrobić jeśli Ci zależy. Akurat tak ciekawie się składa, że mam tą płytkę, ale... z tego co gdzieś czytałem przy serii STM32H7 ST nieźle zrąbało sprawę i stara (pierwsza) rewizja nie dość że różni się max zegarem (400 MHz), to ponoć różni się mocno jeszcze jakimiś istotnymi rzeczami w rejestrach niektórych peryferiów. Niby więc mam tą sama płytkę o której mówisz, ten sam układ, ale pisze na niej, że zegar do 400 MHz (ona właśnie jest z tych pierwszych partii).