Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

Freddie Chopin 13 Lis 2016 12:56 18540 148
  • #121 13 Lis 2016 12:56
    Piotrus_999
    Poziom 39  

    michalko12 napisał:
    Nie może być też tak, że jeśli jeden wątek ma 90% a drugi 9% to ten z tym 9% zostanie obsłużony dopiero wtedy kiedy wyczerpie się czas wątku 90%.

    W systemach RT tym się musi zająć projektant aplikacji.

  • #122 13 Lis 2016 12:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    michalko12 napisał:
    Na jedno wychodzi, zamiast 90ms, podpriorytet 90/100, tym bardziej, że nie ma możliwości zagwarantowania tych 90ms. Można zagwarantować, że ten wątek otrzyma 90% kwantów czasu procesora w stosunku do innych wątków o tym samym priorytecie. Nie może być też tak, że jeśli jeden wątek ma 90% a drugi 9% to ten z tym 9% zostanie obsłużony dopiero wtedy kiedy wyczerpie się czasz wątku 90%.

    Nie wychodzi na jedno. Algorytmy szeregowania wątków w systemach operacyjnych czasu rzeczywistego są takie a nie inne, gdyż chodzi o to, aby poddawały się jakiejś analizie, np. https://en.wikipedia.org/wiki/Rate-monotonic_scheduling , dzięki czemu można faktycznie powiedzieć, że coś jest real-time, a nie "cos podobnego, ale działa dobrze". Wynajdywanie jakiegoś algorytmu od nowa, tylko do specyficznej i dosyć hipotetycznej na razie sytuacji, nie brzmi zbyt kusząco (; Jeśli kwanty 90ms, 9ms i 1ms nie spełniają Twoich założeń przez zbyt długie oczekiwanie na obsługę w tych dwóch "krótszych", to znaczy że po prostu system jest nie do końca przemyślany i te dwa krótsze powinny być jednak wątkami o wyższym priorytecie. Albo po prostu 90/9/1 można zmienić na 9/1/1 - zawsze 10x krótsze czekanie <;

    michalko12 napisał:
    Jeśli wątek przechodzi w stan blokowania to automatycznie wypada z kolejki tasków w stanie wykonywania, a tym samym algorytm r-r nie bierze go pod uwagę i jego kwant czasu w ogóle nie ma znaczenia dla r-r. Co innego jeśli wątek sam się wywłaszcza na rzecz innych, wtedy raczej jego kwant czasowy nie powinien być resetowany.

    To nie chodzi o to czy scheduler bierze pod uwagę zablokowany wątek czy nie - to jest oczywiste. Chodzi o to, co powinno się stać z kwantem czasowym wątku po jego zablokowaniu. We FreeRTOSie nie trzeba się nad tym zastanawiać, ponieważ kwant czasowy round-robin wynosi tam zawsze "1", więc zbytnio nie ma pola manewru. Jednak w innych systemach (np. w distortos) kwant ten może być większy i wynosić np. 10 albo 100. Dla uproszczenia załóżmy, że chodzi o milisekundy. Moje rozumienie jest takie, że jeśli wątek ma np. 100ms kwant czasowy, wykonuje się przez 90ms (zostało więc 10ms) i w tym momencie zostanie zablokowany (bo czeka na semafor, kolejkę, mutexa, cokolwiek), to gdy zostanie odblokowany (bo się doczekał na ten semafor, mutexa czy kolejkę), to jego kwant czasowy zostaje zresetowany do 100ms. W distortos kwant czasowy jest resetowany tylko w 3 przypadkach:
    - przy zmianie algorytmu szeregowania dla danego wątku (round-robin <-> fifo),
    - jeśli się faktycznie wyczerpał i wątek został przełączony,
    - jeśli wątek zostaje zablokowany na jakimś obiekcie synchronizacyjnym.

    Z tego więc wynika, że kwant nie jest resetowany gdy wątek zostanie wywłaszczony - czy to przez wątek o wyższym priorytecie, czy to z własnej woli poprzez wywołanie funkcji yield(). W takim wypadku, gdy zostanie on ponownie uruchomiony, będzie po prostu kontynuował z takim kwantem czasowym jaki mu został.

  • #123 25 Lis 2016 09:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Wczoraj sfinalizowałem w końcu kolejną wersję o numerku 0.3.0. Zajęło to 3x dłużej niż planowałem, ale w trakcie takiego spiętrzenia spraw zawodowych, osobistych i remontowych niczego innego nie można było oczekiwać (; Najważniejsze zmiany w kolejności chronologicznej to:
    - wsparcie dla okresowych timerów programowych ,
    - miły w użyciu driver do portu szeregowego , operujący na abstrakcyjnej klasie interfejsowej dla sprzętowej części + implementacja tejże klasy interfejsowej dla wszystkich obsługiwanych układów (STM32F0, STM32F1 i STM32F4), na razie jedynie w wersji z przerwaniami,
    - równie prosty w użyciu (bo korzystający z tego wspomnianego powyżej) driver dla RS-485 ,
    - driver obsługujący magistralę SPI w trybie "master" , operujący na abstrakcyjnej klasie interfejsowej dla sprzętowej części - jak wyżej, dostępna jest implementacja dla 3 typów STM32 oparta na przerwaniach,
    - abstrakcyjna klasa bazowa "urządzenie SPI" , oraz pierwsza przydatna implementacja tej klasy w postaci drivera dla popularnych układów EEPROMów podłączanych przez SPI ,
    - poprawki wymagane przez GCC 6,
    - zmiana generatora pliku distortosConfiguration.h z takiego który używał AWK na taki bazujący tylko na shellu i coreutils (np. sed), dzięki czemu AWK nie jest już potrzebny w ogóle.

    Bardziej "rozwlekła" lista wprowadzonych zmian - http://distortos.org/distortos-change-log/#0.3.0

    http://distortos.org/news/distortos-0-3-0-released/

  • #124 03 Gru 2016 20:49
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Długo oczywiście zeszło, ale wyczarowałem drugi artykuł o stanach w jakich może się znaleźć wątek i przejściach między tymi stanami.

    http://distortos.org/documentation/task-states/

    Tym razem już nieco "wyższy" poziom (a przynajmniej tak mi się wydaje), choć starałem się ograniczyć w przykładach czy opisach do minimalnego zestawu "ficzerów", aby tekst był zrozumiały nawet dla kogoś kto pierwszy raz czyta coś o RTOSach. Może się udało, może nie (; We'll see... Teraz prace nad kolejnymi artykułami powinny nieco przyspieszyć.

  • #125 11 Sty 2017 19:14
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Wrzuciłem dwa kolejne ciekawe artykuły:
    1. ARM toolchain for Windows - zawiera kompletny i szczegółowy opis instalacji pod Windows wszelkich narzędzi wymaganych przez distortos (MSYS2, make, gcc [bleeding-edge-toolchain], OpenOCD, kconfig-frontends, Eclipse),
    2. Creating and configuring a project in Eclipse - opis tworzenia i konfiguracji nowego projektu z distortos w Eclipse, włącznie z najważniejszą chyba rzeczą, czyli konfiguracja indeksera.

    Artykuły te nie są oczywiście przeznaczone tylko dla distortos - zarówno jeden i drugi można potraktować jako opis konfiguracji toolchaina dla "zwykłych" projektów dla ARM. W pierwszym artykule pomijamy wtedy akapity o kconfig-frontends, a w drugim rzeczy typu konfiguracja samego RTOSa (czyli tworzenie/modyfikacja pliku distortosConfiguration.mk) czy włączanie pełnych komend kompilacji w konsoli (choć to również może się przydać w niektórych projektach).

    Jak zwykle wszelkie uwagi i opinie mile widziane (;

  • #126 11 Sty 2017 19:29
    tadzik85
    Poziom 38  

    ad.1 ścieżkę systemową można ustawić w Eclipse. Uważam, że tak jest lepiej jak ktoś używa wielu środowisk itp itd, wtedy kompilatory i make nie będą się gryzły. I Nadal aktualne przecież jest doinstalowanie pluginu Hardware debuging.

    I może polecenia których należy użyć rzeczy które należy skopiować daj w nowych liniach dla ułatwienia.

  • #127 11 Sty 2017 19:32
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Można ustawić w Eclipse, ale dla celów tego projektu i tak musi być ustawiona ścieżka systemowa, bo inaczej nie będzie działać konfiguracja projektu z konsoli systemowej (tam potrzebne jest MSYS2 i kconfig-frontends).

    Wtyczka do debuggowania, jak i samo debuggowanie, planowane jest jako osobna część trzecia.

  • #128 11 Sty 2017 19:34
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    Można ustawić w Eclipse, ale dla celów tego projektu i tak musi być ustawiona ścieżka systemowa, bo inaczej nie będzie działać konfiguracja projektu z konsoli systemowej (tam potrzebne jest MSYS2 i kconfig-frontends).
    Dodać można wszystko co chcesz ;),

    Zaznacz choć, że jest taka możliwość....

  • #129 11 Sty 2017 19:45
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Dodać można wszystko co chcesz ,

    Opiszę może dokładniej o co mi chodziło, gdyż poprzedni post może nie być wystarczająco jednoznaczny. Niektóre narzędzia muszą być w ścieżce systemowej widocznej na poziomie systemu operacyjnego, ponieważ polecenie "make menuconfig" (które jest bardzo ważną częścią projektu distortos) _NIE_ zadziała nigdy z poziomu Eclipse'a. Dla narzędzia uruchamianego z "cmd.exe" czy z terminala w Linuxie (bo uruchomienie go w Eclipse jest fizycznie niemożliwe) nie ma znaczenia co sobie ustawisz w opcjach projektu w Eclipse.

    tadzik85 napisał:
    Zaznacz choć, że jest taka możliwość....

    Idea jest taka że artykuły są też dla ludzi którzy nie mają z tym obycia. Dla takich osób dawanie miliona opcji jest tylko zaciemnianiem obrazu, a sam opis (bez obrazków i np. osobnego akapitu) będzie zbyt skromny aby ktoś sobie z tego skorzystał. Zakładam, że osoby zaawansowane nie muszą takiego opisu wykonywać krok po kroku z dokładnością co do kropki, bo wiedzą co chcą osiągnąć i w jaki sposób. Mogę więc dodać na górze jednego i drugiego artykułu informację, że opisany sposób nie jest jedynym ani "jedynym właściwym" i są możliwe inne rozwiązania, które również będą działać.

    Swoją drogą - sam używam wielu toolchainów i nigdy nie używam konfiguracji PATH z poziomu projektu Eclipse'a - jeśli jest problem, to uruchamiam Eclipse z linii komend z dodatkowymi folderami na początku PATH, wtedy mają one priorytet nad tym co jest już w systemowym PATH. W linuxie z konsoli "PATH=~/what/ever/bin:$PATH eclipse &", w Windows zapewne podobnie (nie wiem, nie używam obecnie).

  • #130 11 Sty 2017 19:50
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    Spróbuj przeczytać dokładnie to co napisałem. Niektóre narzędzia muszą być w ścieżce systemowej widocznej na poziomie systemu operacyjnego, ponieważ polecenie "make menuconfig" _NIE_ zadziała nigdy z poziomu Eclipse'a. Dla narzędzia uruchamianego z "cmd.exe" czy z terminala w Linuxie (bo uruchomienie go w Eclipse jest fizycznie niemożliwe) nie ma znaczenia co sobie ustawisz w opcjach projektu w Eclipse.
    Podobno to temat o konfiguracji eclipse nie tylko pod Distortos. A to są sugestie jedynie......

    Jak nie chcesz zaciemniać artykułu. To może tricks & tips na końcu? Właśnie, może drobna wzmianka bo autosave? gdzie znaleźć?

  • #131 11 Sty 2017 19:57
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Podobno to temat o konfiguracji eclipse nie tylko pod Distortos. A to są sugestie jedynie......

    Temat jest o distortos. Artykuł jest na stronie distortos i jest przeznaczony głównie dla distortos. Po prostu distortos nie jest tak specjalnie różny od dowolnego innego projektu dla ARM, żeby opis konfiguracji toolchaina czy projektu w Eclipse nie pokrywał się w jakichś 95% z opisami dla "zwykłych" projektów. Sugestię odnotowałem i oczywiście za nią dziękuję, tylko że we wszystkim musi być umiar - jak w artykule w każdym akapicie będzie coś na styl "zrób daną rzecz tak albo siak. jeśli wybrałeś pierwszą opcję to pomiń następne 3 akapity. jesli wybrałeś drugą opcje, skocz 2 akapity w tył" to po prostu nikt się w tym nie połapie i nikt nie będzie w stanie na jego podstawie zrobić czegoś co jest dla niego/niej absolutną nowością.

    tadzik85 napisał:
    Jak nie chcesz zaciemniać artykułu. To może tricks & tips na końcu? Właśnie, może drobna wzmianka bo autosave? gdzie znaleźć?

    To jest planowane jako jeszcze jedna - czwarta - część, która byłaby poświęcona przydatnym opcjom "kosmetycznym". Tutaj sprawa jest mocno niejasna, bo większość takich opcji jest całkowicie subiektywna - ja np. nie włączam autosave, bo nie chce mi się szukać (; A jak nie wiem gdzie jest jakaś opcja, to warto odnotować, że wyszukiwarka w "preferences" działa bardzo dobrze i przy jej pomocy można znaleźć każdą opcje w 5 sekund (jeśli wiemy czego szukamy <: ). Artykuł podstawowy chciałem zredukować do minimum wymaganych kroków, aby nie przedłużać.

  • #132 11 Sty 2017 20:01
    tadzik85
    Poziom 38  

    No to sporo mi wyjaśniłeś.... A, że taka wyszukiwarka jest też trzeba zauważyć, co dla kogoś kto eclipse widzi 1 raz może nie być oczywiste.

    PS. indexer, często warto odznaczyć indexowanie plików nie używanych w kompilacji a będących w projekcie.


    Poza tym informacja nie jest przykazem do stosowania. Ale lepiej znać możliwości, niż szukać godzinami czy zadawać pytania na forum.

  • #133 22 Sty 2017 01:35
    kriss68
    Poziom 20  

    Planujesz podpiąć tego RTOSa pod std::thread?

  • #134 22 Sty 2017 10:42
    Freddie Chopin
    Specjalista - Mikrokontrolery

    kriss68 napisał:
    Planujesz podpiąć tego RTOSa pod std::thread?

    Nie mam na ten temat sprecyzowanego zdania... Związane jest to z nieoptymalną (moim zdaniem) proporcją zalet do wad. Zaleta zasadniczo jest tylko jedna, choć oczywiście bardzo istotna - standardowy interfejs. Za to bez specjalnego zastanawiania się rozwiązanie to ma dwie bardzo poważne wady.

    1. Wymagałoby to utrzymywania forka GCC i newlib, aby produkować toolchain "arm-distortos-eabi-" zamiast "arm-none-eabi-", taka integracja oczywiście działałaby tylko na tym pierwszym, więc aby dało się używać systemu z tym drugim, konieczne byłyby pewnie jakieś kompilacje warunkowe w samym projekcie.

    2. Sam interfejs std::thread jest niezbyt dopasowany do wymagań mikrokontrolerów czy w ogóle embedded, a jego "standardowość" jest mocno ograniczona - warto zauważyć, że w kwestii wątków interfejs std::thread w ogóle nie zakłada istnienia czegoś takiego jak priorytet, algorytm szeregowania czy rozmiar stosu. O ile te dwie pierwsze rzeczy można po stworzeniu wątku zmienić (korzystając z _NIE_standardowych rozwiązań dostępnych poprzez obiekt zwracany przez funkcję native_handle()), o tyle tej ostatniej rzeczy się niestety nie da zmodyfikować po starcie wątku na mikrokontrolerze bez MMU. Oczywiście też nie da się zrobić tak, żeby po wywołaniu konstruktora std::thread wątek nie był od razu uruchamiany, bo tego ten interfejs też nie przewiduje...

    Szczególnie istotny jest ten drugi punkt, bo on mocno ogranicza zasadniczą zaletę tego rozwiązania. No bo w takim przypadku albo wszystkie wątki stworzone tym interfejsem muszą mieć dokładnie ten sam rozmiar stosu, albo konieczne jest dokładanie niestandardowych rozwiązań, np. funkcji modyfikującej domyślny rozmiar stosu dla std:thread (która do poprawnego działania musiałaby być używana w sekcji krytycznej wraz z konstruktorem wątku...).

    Z drugiej strony interfejs udostępniany w distortos jest bardzo zbliżony do std::thread, tyle że z drobnymi modyfikacjami tak aby bardziej pasował do mikrokontrolerów. Nie wiem więc, czy w ogóle warto coś takiego robić, ponieważ dla mikrokontrolerów byłaby to raczej "ciekawostka" niż coś używalnego do poważnych zastosowań. Interfejs pthread jest dużo bardziej dopasowany do naszych wymagań - jeśli więc ktoś lubi rozwiązania standardowe, to właśnie w tym kierunku warto się odwrócić. Ten interfejs oczywiście nie jest w C++, więc też nie załatwia wszystkich problemów...

  • #135 11 Mar 2017 17:25
    Freddie Chopin
    Specjalista - Mikrokontrolery

    No i mamy kolejną wersję, oznaczoną numerkiem 0.4.0!

    Najważniejsze - moim skromnym zdaniem - zmiany, to:
    - wsparcie dla całej rodziny STM32F7, dzięki czemu ilość obsługiwanych układów wynosi obecnie 395 sztuk,
    - dwie opcje (każda w dwóch wariantach) umożliwiające wykrywanie przepełnienia stosu wątku,
    - opcja sprawdzania kontekstu funkcji które nie mogą być używane w przerwaniach (blokujące, mutexy i cały namespace ThisThread), co załatwia chyba najpopularniejszy typ błędu w aplikacjach.

    Krótki artykuł o najnowszej wersji (wraz ze wszystkimi ciekawymi linkami) można znaleźć na stronce projektu - http://distortos.org/news/distortos-0-4-0-released/

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

  • #136 05 Kwi 2017 19:07
    arcyimperator
    Poziom 11  

    Witam,
    niestety ale skonfigurowanie kconfig-frontends mnie przerosło. Ściągnałem repozytorium, zainstalowałem wszystkie pakiety o które sie upominał instalator, potem autoreconf -fi, ./configure, niesty dla make mam:
    maciek@maciek:~/kconfig-frontends$ make
    YACC libs/parser/yconf.c
    byacc: e - line 95 of "/home/maciek/kconfig-frontends/libs/parser/yconf.y", syntax error
    %destructor {
    ^
    Makefile:1570: polecenia dla obiektu 'libs/parser/yconf.c' nie powiodły się
    make[1]: *** [libs/parser/yconf.c] Błąd 1
    Makefile:877: polecenia dla obiektu 'all' nie powiodły się
    make: *** [all] Błąd 2
    maciek@maciek:~/kconfig-frontends$

    nie doczytałem czegoś? Miał ktos podobny problem? Jakies nieaktualne pakiety?

  • #137 05 Kwi 2017 19:27
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Próbowałeś postępować wg opisu z http://distortos.org/documentation/building-kconfig-frontends-linux/ ?

    Możesz wrzucić tutaj pełny log tego co wyrzuca Ci komenda "./configure ..." (i może też plik config.log, który gdzieś tam powinien się utworzyć)? Porównam z tym co wyświetla u mnie, to może do czegoś dojdziemy. Wydaje się, jakby u Ciebie używał do kompilowania pliku yconf.y programu byacc, tymczasem u siebie nawet takiego nie mam (;

    Swoją drogą czy "autoreconf" jest tutaj konieczne? Nigdy nie musiałem przy kconfig-frontends wydawać tej komendy...

    Anyway - sprawdziłem właśnie, że u mnie też się kconfig nie kompiluje, ale z zupełnie innego powodu... Wyrzuca mi coś takiego:

    Code:
    $ make
    
    Making all in docs
    Making all in libs
    Making all in parser
      GPERF  hconf.c
      LEX    lconf.c
      YACC   yconf.c
      CC     libkconfig_parser_la-yconf.lo
    In file included from yconf.c:242:0:
    hconf.gperf:141:1: error: conflicting types for 'kconf_id_lookup'
    hconf.gperf:12:31: note: previous declaration of 'kconf_id_lookup' was here
     static const struct kconf_id *kconf_id_lookup(register const char *str, register unsigned int len);
                                   ^~~~~~~~~~~~~~~
    make[3]: *** [Makefile:456: libkconfig_parser_la-yconf.lo] Error 1
    make[2]: *** [Makefile:350: all] Error 2
    make[1]: *** [Makefile:334: all-recursive] Error 1
    make: *** [Makefile:385: all-recursive] Error 1


    Powinien to naprawić patch z https://gitlab.kn.e-technik.tu-dortmund.de/fa...config-frontends/blob/master/patch-size_t.zip , zaraz będę to sprawdzał i muszę zaktualizować opis całego procesu... Ehh...

  • #138 05 Kwi 2017 20:11
    arcyimperator
    Poziom 11  

    hmmm... na końcu README (używałem repo gitowego, nie paczki)

    Cytat:
    Note: if using the git tree, or changing the autostuff sources, you'll first
    have to run:
    autoreconf -fi


    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Cytat:

    Nie zauważyłem go wcześniej. Szkoda, bo działa:)

    Cytat:
    Powinien to naprawić patch z https://gitlab.kn.e-technik.tu...s/blob/master/patch-size t.zip , zaraz będę to sprawdzał i muszę zaktualizować opis całego procesu... Ehh...

    Przepraszam


    :) Dzięki za pomoc!

  • #139 05 Kwi 2017 21:23
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Co do Twojego logu, główną różnicą która mi się rzuciła w oczy jest poniższe.

    U ciebie:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    U mnie:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Wydaje się więc, że pomimo tego iż "byacc" jest akceptowane przez skrypt, raczej trzeba się nastawić na używanie "bison".

    Błąd który jest u mnie wynika z nowej wersji gperf (3.1, wydane 05.01.2017), więc najwidoczniej w Twoim systemie jeszcze masz zainstalowaną poprzednią skoro poszło (chyba że użyłeś patcha).

  • #140 06 Kwi 2017 19:11
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Zaktualizowałem artykuł z instrukcjami kompilacji kconfig-frontends o dodatkowy krok który pozwala na ominięcie problemu z gperf 3.1 (lub nowszym).

    http://distortos.org/documentation/building-kconfig-frontends-linux/

    Tak czy siak problem ten na razie dotyczy tylko takich miłośników "bleeding-edge" jak ja, ale z pewnością nie jestem w tym sam, a do tego ilość osób z problemem z pewnością będzie rosnąć.

  • #141 07 Kwi 2017 15:24
    arcyimperator
    Poziom 11  

    Freddie Chopin napisał:
    Wydaje się więc, że pomimo tego iż "byacc" jest akceptowane przez skrypt, raczej trzeba się nastawić na używanie "bison".

    Jesli mnie pamięć nie myli to ubuntu podpowiadał 5 pakietów do wyboru w tej kwestii.

    Jeszcze lamerskie pytanie (przepraszam ale ostatnio mam b. mało czasu, więc każda pomoc się mi przydaje). Moja płytka to STM32F4 Discovery, ledy włączone w konfiguracji. Jaką ścieżkę podać do include w main żeby je widział? distortos/board.leds.hpp nie znajduje (tak jest w pliku main z katalogu test). BTW ledy to przykład, niektórych innych plików tez nie moge zainkludować.
    Dzieki z góry za pomoc

  • #142 07 Kwi 2017 15:39
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Obstawiam, że brakuje Ci dokładnie tej podświetlonej linijki w Twoim pliku Rules.mk:

    https://github.com/DISTORTEC/distortos/blob/master/test/Rules.mk#L43

    Warto jednak dodać, że zwykle użycie jej wymusza też dodanie trzech poprzednich (ze względu na inne zależności), choć nie zawsze.

    Kod: bash
    Zaloguj się, aby zobaczyć kod

    (ostatnia linijka)

    Daj znać czy pomogło, a jeśli nie, to wrzuć tutaj log kompilacji i może właśnie cały plik Rules.mk.

  • #143 07 Kwi 2017 18:09
    arcyimperator
    Poziom 11  

    Freddie,
    pomogło dodanie linijek do Rules.mk:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Wiesz może dlaczego musiałem dodać je ręcznie? Mam zaznaczone:
    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Dzieki za pomoc!

  • #144 07 Kwi 2017 18:38
    Freddie Chopin
    Specjalista - Mikrokontrolery

    arcyimperator napisał:
    Wiesz może dlaczego musiałem dodać je ręcznie? Mam zaznaczone:

    Nie no, tak dobrze to nie ma. Opcja ta w zasadzie tylko i wyłącznie wpływa na to czy zawartość pliku leds.hpp (i odpowiadającego mu pliku .cpp) jest "dostępna" czy nie.

    https://github.com/DISTORTEC/distortos/blob/m...ISCOVERY/include/distortos/board/leds.hpp#L64

    Jeśli tą opcję wyłączysz, to plik ten po prostu nie zawiera (z punktu widzenia kompilatora) żadnej użytecznej treści. Opcje wybierane w Kconfig niestety nie wpływają aż tak bardzo na sam proces kompilacji...

    W każdym razie w swoim projekcie możesz do absolutnie każdego pliku Rules.mk (czyli po prostu dla wszystkich Twoich plików źródłowych) dodać pełen komplet wszystkich 4 ścieżek "include" ("standard", "architecture", "chip" oraz "board"). Nigdy nie będzie to (a przynajmniej nie powinno) powodem jakichś błędów kompilacji czy zmiany zachowania całości. Jedyne co może się zmienić, to nieznacznie wydłuży się cała kompilacja (bo po prostu preprocesor będzie musiał przeszukać więcej folderów niż to absolutnie potrzebne), jednak różnica powinna być w akceptowalnych granicach (np. całość zamiast 10s będzie się kompilowała w 11s).

    Jeśli uważasz to za dobry pomysł, można by dodać np. jeszcze jedną "stałą", np. o nazwie ALL_INCLUDES, która po prostu zawierałaby w sobie pozostałe 4. Wtedy z punktu widzenia użytkownika byłoby to nieco prostsze do użycia. Dla łatwiejszego startu od razu można by jej użyć we wszystkich "przykładach" oraz w repozytorium z szablonem projektu.

  • #145 11 Kwi 2017 14:06
    arcyimperator
    Poziom 11  

    Freddie,
    dzięki za odpowiedź. Takich niestety teraz mamy programistów co nie potrafią sobie z najprostszą rzeczą poradzić:)
    Jeśli chodzi o dodawanie do przykładów -myślę że wystarczy dodać to do poradnika. Zdanie typu "pamiętajmy o dodaniu linijek ... do plików Rules.mk ... gdy chcemy używać plików board/chip specific. W przeciwnym przypadku otrzymamy błąd nieznalezienia pliku" powinno załatwić sprawę w moim przypadku.
    Poza tym jestem pod wrażeniem tego tutoriala -gratuluję cierpliwości w pisaniu:)
    Mam nadzieję ze wkrótce wygospodaruję więcej czasu i wystartuje nowy projekt z Twoim RTOSem.

  • #146 17 Kwi 2017 19:29
    08FEDRA
    Poziom 12  

    Freddie Chopin napisał:
    arcyimperator napisał:
    Wiesz może dlaczego musiałem dodać je ręcznie? Mam zaznaczone:


    Nie no, tak dobrze to nie ma. Opcja ta w zasadzie tylko i wyłącznie wpływa na to czy zawartość pliku leds.hpp (i odpowiadającego mu pliku .cpp) jest "dostępna" czy nie.

    Cześć, też się na to dziś "nadziałem" ;) Intuicja podpowiada, że jak się coś zaznaczy w konfiguratorze, to działa, bez konieczności wykonywania dodatkowych zabiegów. Ale to tylko taka drobna niedogodność. Zauważyłem jeszcze u siebie problem z Build Output Parserem. Mam zaznaczoną opcję "File" i wszystko działa jak trzeba w plikach *.cpp, nie działa natomiast w nagłówkach. Nie bardzo wiem jak to ugryźć.

    Pozdrawiam.

  • #147 17 Kwi 2017 21:17
    Freddie Chopin
    Specjalista - Mikrokontrolery

    08FEDRA napisał:
    Cześć, też się na to dziś "nadziałem" Intuicja podpowiada, że jak się coś zaznaczy w konfiguratorze, to działa, bez konieczności wykonywania dodatkowych zabiegów. Ale to tylko taka drobna niedogodność.

    To może faktycznie dodam coś na styl "ALL_INCLUDES" i będzie "problem solved" (;

    08FEDRA napisał:
    Zauważyłem jeszcze u siebie problem z Build Output Parserem. Mam zaznaczoną opcję "File" i wszystko działa jak trzeba w plikach *.cpp, nie działa natomiast w nagłówkach. Nie bardzo wiem jak to ugryźć.

    Tego się chyba nie da ugryźć wcale. Wg mnie chodzi o to, że nagłówki nie mają "kontekstu" - tzn. zależnie od tego z którego pliku źródłowego zostaną dołączone, to będą "widziały" zupełnie co innego. Z tego właśnie względu Eclipse zbytnio nic nie podpowiada...

  • #148 18 Kwi 2017 08:23
    08FEDRA
    Poziom 12  

    Póki co obszedłem problem, przełączając na "Folder". Działa ok, bo Rules.mk są definiowane na poziomie katalogu. Wadą jest konieczność trzymania trzymania nagłówków w jednym katalogu razem z plikami źródłowymi.
    Tak z innej beczki, udało mi się wczoraj odpalić SpiDevice. Rozumiem, że "domyślny" driver (spi1 z konfiguracji dla płytki discovery) nie dotyka konfiguracji pinów? :)

  • #149 18 Kwi 2017 08:54
    Freddie Chopin
    Specjalista - Mikrokontrolery

    08FEDRA napisał:
    Tak z innej beczki, udało mi się wczoraj odpalić SpiDevice. Rozumiem, że "domyślny" driver (spi1 z konfiguracji dla płytki discovery) nie dotyka konfiguracji pinów?

    Niestety - jest tak jak mówisz. Zarówno SPI jak i USART nie konfigurują automatycznie pinów. W swoich projektach inicjalizację taką daję w funkcji distortos::board::lowLevelInitialization(), która - jeśli jest zdefiniowana - zostanie automatycznie wywołana w trakcie inicjalizacji systemu. Ważna uwaga - funkcja ta jest wywołana _PRZED_ globalnymi konstruktorami i przed faktycznym uruchomieniem schedulera, tak więc:
    1. absolutnie nie należy odwoływać się do globalnych obiektów (chyba że masz 100% pewności że ich konstruktory są "trywialne" - "constexpr" - i obiekt jest już zainicjalizowany jako "data" lub "read-only data"),
    2. nie należy próbować wykonywać operacji blokujących (np sleep czy oczekiwanie na semafory).

    Kod w którym inicjalizuję piny wygląda zwykle tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    W każdym razie z racji tego, że to mi się również bardzo nie podobało, od dawna zastanawiałem się jak to zmienić i w końcu dałem się przekonać do dodania w systemie wsparcia dla devicetree znanych z Linuxa. Wsparcie to będzie działało (wg mojego aktualnego planu, sytuacja jest dynamiczna, bo to bardzo wczesny etap implementacji) nieco inaczej niż w Linuxie, gdzie na podstawie "skomplikowanego" pliku przy starcie systemu tworzone są różne obiekty, a więc wszystko odbywa się "dynamicznie" i dobrze współgra z zasadą że "wszystko jest plikiem". W distortos planuję użyć *.dts jako formatu konfiguracji, na podstawie którego w procesie kompilacji projektu będą tworzone odpowiednie pliki źródłowe i nagłówkowe z wybranymi obiektami czy z konfiguracją. Załatwi to więc właśnie konfigurację pinów jak i tworzenie obiektów SPI/USART/GPIO/... Inna zaleta (lub wada - zależnie od spojrzenia), to drastyczne uproszczenie i "zmniejszenie" konfiguracji przez kconfig, ponieważ w tej sytuacji zostaną tam jedynie opcje nie powiązane ze sprzętem (czyli np. ustawienie poziomu optymalizacji, tego czy jakaś funkcjonalność [programowa] systemu jest włączona czy nie, itd.).

    Taka mała rewolucja, ale myślę że "pozytywna". No i na pewno nie ostatnia (;

    Zobaczymy jak to wszystko wyjdzie, ale nadzieje mam spore. Poza załatwieniem tej drobnej niedogodności związanej z pinami GPIO od SPI/USART/RS-485, załatwia to też kilka innych rzeczy, np. konfigurację DMA. Na to też niezbyt miałem koncepcję (dlatego brak jakiegokolwiek wsparcia), bo bardzo ciężko byłoby to konfigurować przez kconfig, a robienie tego "ręcznie" w kodzie też jest średnio zabawne...

Szybka odpowiedź lub zadaj pytanie
Dziękuję Ci. Ta wiadomość oczekuje na moderatora.
 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME