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.

[STM32/ARM/ogólnie o programowaniu na uC]Wielowątkowość, wielozadaniowość

-XantiO- 28 Dec 2018 01:55 1584 35
Computer Controls
  • #1
    -XantiO-
    Level 21  
    Witam,

    Jako jeszcze niedoświadczony w programowaniu i całym tym mikroprocesorowym świecie chciałbym rozpocząć dyskusję z której mam nadzieję uda mi się coś wyciągnąć, czegoś się dowiedzieć. Mianowicie pierwsza sprawa to przeklęte delay'e. Czasami trzeba przeczekać na coś ileś tam czasu ale po co marnować go w delay? Jakie mamy alternatywy i jak z nich korzystać? kolejna sprawa to "podział" czasu procesora na dwa zadania. Jak sensownie to wykonywać? Oczywiście nie chcę tu mieszać do tego RTOS'a.

    Dla przykładu. Piszę teraz soft na STM32F469 gdzie już zasięgałem waszej pomocy odnośnie QSPI i działa to teraz super. Ale mam kilka operacji wykonywanych ciągle w tle realizowanych wywołaniem z przerwania natomiast główna część programu leci i mam miejsca gdzie muszę zrobić "postój" na czas 100ms-1000ms ze względu na inicjalizację pewnych urządzeń. W tej chwili robię to wystawianiem flagi z timera ale chciałbym poznać jakieś alternatywy.

    Dodatkowo czy jest sens zakupu jakiejś dev board z uC (np. TMS320F28374D i pokrewne)wielordzeniowym aby poznać prawdziwą wielowątkowość?
  • Computer Controls
  • #2
    LChucki
    Level 31  
    -XantiO- wrote:
    Czasami trzeba przeczekać na coś ileś tam czasu ale po co marnować go w delay? Jakie mamy alternatywy i jak z nich korzystać?

    Timery, przy czym mogą to być programowe timery zrealizowane w przerwaniu np 1ms.

    -XantiO- wrote:
    kolejna sprawa to "podział" czasu procesora na dwa zadania. Jak sensownie to wykonywać? Oczywiście nie chcę tu mieszać do tego RTOS'a.

    Najłatwiej zrobić to RTOS-em innych sensownych metod nie znam. Jak zrobisz to na zasadzie maszyny stanów dla każdego zadania, to zadanie weźmie tyle czasu ile potrzebuje (jak w Windows) a nie ile ma przydzielone.
  • #3
    kacpo1
    Level 33  
    -XantiO- wrote:
    Ale mam kilka operacji wykonywanych ciągle w tle realizowanych wywołaniem z przerwania natomiast główna część programu leci i mam miejsca gdzie muszę zrobić "postój" na czas 100ms-1000ms ze względu na inicjalizację pewnych urządzeń. W tej chwili robię to wystawianiem flagi z timera ale chciałbym poznać jakieś alternatywy.

    Bardzo ciekawą rzeczą jest DMA, pozwala odciążyć procesor, przez przejmowanie pewnych jego obowiązków, właśnie takich jak obsługiwanie urządzeń zewnętrznych.
    -XantiO- wrote:
    kolejna sprawa to "podział" czasu procesora na dwa zadania. Jak sensownie to wykonywać?

    Zależy w czym programujesz. Jeśli piszesz np. w C to kompilator i tak wytworzy najbardziej optymalny kod Assemblera. Jeśli faktycznie chcesz się zagłębić w takie sfery, polecam poradnik szczywronka dot. STM32.
  • #4
    LChucki
    Level 31  
    kacpo1 wrote:
    Bardzo ciekawą rzeczą jest DMA, pozwala odciążyć procesor, przez przejmowanie pewnych jego obowiązków, właśnie takich jak obsługiwanie urządzeń zewnętrznych.

    W jaki sposób DMA rozwiąże wielozadaniowość? Będzie wywłaszczać taski? Przełączać je?
    DMA przy obsłudze peryferii potrafi trochę mniej niż przerwania ale nie obciąża CPU i w tym jest jego moc. Może też kopiować lub wypełniać bloki pamięci.

    kacpo1 wrote:
    Jeśli piszesz np. w C to kompilator i tak wytworzy najbardziej optymalny kod Assemblera.

    Co ma kompilator do wielozadaniowości? Będzie wywłaszczać taski? Przełączać je?


    PS
    @kacpo1, avatar dobrze wybrałeś.
  • #5
    kacpo1
    Level 33  
    LChucki wrote:
    W jaki sposób DMA rozwiąże wielozadaniowość?

    No nie wiem, może choćby przez to, że DMA może zająć się "inicjalizacją pewnych urządzeń" kiedy procesor robi coś innego.
    LChucki wrote:
    DMA potrafi trochę mniej niż przerwania ale nie obciąża CPU

    Czekaj, czekaj... Czy Ty właśnie porównujesz DMA do przerwania...?
    LChucki wrote:
    Co ma kompilator do wielozadaniowości?

    A czy autor tutaj pisał o wielozadaniowości? Pisał o podziale zadań, które i tak na jedno rdzeniowym procesorze się nie uda, więc w grę wchodzą tutaj raczej priorytety i wywłaszczanie.
  • Computer Controls
  • #6
    LChucki
    Level 31  
    kacpo1 wrote:
    LChucki wrote:
    W jaki sposób DMA rozwiąże wielozadaniowość?

    No nie wiem, może choćby przez to, że DMA może zająć się "inicjalizacją pewnych urządzeń" kiedy procesor robi coś innego.

    Inicjalizacji? DMA potrafi tylko transmitować dane i nic więcej. Używał kiedykolwiek kolega DMA? Wie jak działa? Odnoszę wrażenie, ze nie.

    kacpo1 wrote:

    LChucki wrote:
    DMA potrafi trochę mniej niż przerwania ale nie obciąża CPU

    Czekaj, czekaj... Czy Ty właśnie porównujesz DMA do przerwania...?

    Nie porównuję, proszę przeczytać moją wypowiedź w #4 ze zrozumieniem.

    kacpo1 wrote:

    LChucki wrote:
    Co ma kompilator do wielozadaniowości?

    A czy autor tutaj pisał o wielozadaniowości?

    Jaki jest tytuł wątku?

    kacpo1 wrote:

    Pisał o podziale zadań,

    Pisał o równym podziale a czym jest równy podział jak nie wielozadaniowością?

    kacpo1 wrote:

    które i tak na jedno rdzeniowym procesorze się nie uda,

    No proszę, co ja czytam! Komputery Mac czy Amiga na jednordzeniowym 68k czy PPC nie miały wielozadaniowości? Windows 95 na I486 nie miał wielozadaniowości? RTOS na STM32 nie istnieje? uRTOS na AVR, ESP nie ma?

    kacpo1 wrote:

    więc w grę wchodzą tutaj raczej priorytety i wywłaszczanie.

    Podaj przykład systemu z wywłaszczaniem i priorytetami, który nie jest wielozadaniowy. Nie pisz tylko, że Windows, bo to nie system z prawdziwego zdarzenia.
  • #7
    User removed account
    Level 1  
  • #8
    Kuniarz
    Moderator of Designing
    Moderated By Kuniarz:

    Panowie... celowo nie usuwam Waszych pyskówek, bo jednak można z nich coś tam interesującego wyciągnąć. Niemniej, zachęcam do MERYTORYCZNYCH odpowiedzi na przedstawione przez autora tematu zagadnienia.

  • #10
    User removed account
    Level 1  
  • #11
    -XantiO-
    Level 21  
    kacpo1 wrote:
    -XantiO- wrote:
    Ale mam kilka operacji wykonywanych ciągle w tle realizowanych wywołaniem z przerwania natomiast główna część programu leci i mam miejsca gdzie muszę zrobić "postój" na czas 100ms-1000ms ze względu na inicjalizację pewnych urządzeń. W tej chwili robię to wystawianiem flagi z timera ale chciałbym poznać jakieś alternatywy.

    Bardzo ciekawą rzeczą jest DMA, pozwala odciążyć procesor, przez przejmowanie pewnych jego obowiązków, właśnie takich jak obsługiwanie urządzeń zewnętrznych.
    -XantiO- wrote:
    kolejna sprawa to "podział" czasu procesora na dwa zadania. Jak sensownie to wykonywać?

    Zależy w czym programujesz. Jeśli piszesz np. w C to kompilator i tak wytworzy najbardziej optymalny kod Assemblera. Jeśli faktycznie chcesz się zagłębić w takie sfery, polecam poradnik szczywronka dot. STM32.


    Kolego nie do końca zrozumiałeś sens tej dyskusji. DMA mam zastosowane chyba dla wszystkiego co się dało czyli ADC, I2C, TIM(PWM), USART, SDIO, QSPI i dodatkowe MemToMem lecz to nie rozwiązuje problemu wielozadaniowości a jedynie "zwalnia" czas kontrolera dla innych zadań. Tak więc dalej zostaje problem "podziału" tego czasu w ramach wielozadaniowości.

    stmx wrote:
    Dodam jeszcze że tych RTOSow nie trzeba się bać. Nie jest to żadna czarna magia, ani wiedza dla wtajemniczonych.

    Co więcej po jakimś czasie uznasz, że pisanie bez i utrudnianie sobie życia jest bez sensu.

    Ja się nie boję RTOSa i nie bronie się przed nim. Problemem jest natomiast ten aktualny projekt gdzie na początku wszystko było ok do zrobienia bez RTOSa po czym zmieniły się założenia jak byłem już pod koniec pisania softu i tu pojawił się problem pisać od nowa na RTOS czy stosując jakieś sztuczki starać się to już ogarnąć na tym co mam. (tonący brzytwy się chwyta) No i wybór padł na kończenie tego co jest.

    Plus taki, że procesor jest na tyle wydajny, że można stosować nawet bardzo nie optymalne rozwiązania jeśli to w czymś pomoże. Do tego nie ma tu krytycznych zadań wymagających super responsywności. Tak więc zamiast czekać w bezsensownym delay'u to przeliczam sobie dane nagromadzone w ramie z ADC i kilku czujników przygotowując w ten sposób dane dla innej funkcji.
  • #12
    Freddie Chopin
    MCUs specialist
    -XantiO- wrote:
    Ja się nie boję RTOSa i nie bronie się przed nim. Problemem jest natomiast ten aktualny projekt gdzie na początku wszystko było ok do zrobienia bez RTOSa po czym zmieniły się założenia jak byłem już pod koniec pisania softu i tu pojawił się problem pisać od nowa na RTOS czy stosując jakieś sztuczki starać się to już ogarnąć na tym co mam. (tonący brzytwy się chwyta) No i wybór padł na kończenie tego co jest.

    Nie musisz niczego pisać od nowa. Obecnie Twój program jest jednowątkowy, więc możesz go przenieść na RTOSa 1:1 bez żadnych zmian (no chyba że używasz SysTicka, PendSV czy blokowania przerwań, to trzeba będzie troszkę zmian wprowadzić). Już na samej takiej zmianie masz jakieś plusy, bo możesz durne delaye zastąpić delayami RTOSa. Wtedy możesz się zastanowić co można łatwo "wyciągnąć" z tego super-wątku do innych wątków - trzeba tym nowym wątkom dać czas się wykonywać, wiec super-wątek musi zyskać jakąś synchronizację z przerwaniami, żeby się nie kręcił w kółko sprawdzając jakieś flagi.

    Idealnie nie będzie, ale na 80% będzie łatwiej niż kombinować jednowątkowo z tym co masz.
  • #13
    User removed account
    Level 1  
  • #14
    -XantiO-
    Level 21  
    Aktualnie w tym projekcie zostało mi tylko dopisanie 1 czy 2 funkcji więc na teraz będzie wszystko działało tak jak jest lecz jako, że jest luźniej z racji okresu świątecznego to postaram się wszystko przepisać na czysto na RTOSie w ramach takiego wprowadzenia bo póki co robiłem tylko jakieś proste testowe rzeczy.

    A jak sprawa z RTOSem wygląda jak są obecne w uC dwa lub więcej fizyczne rdzenie? Czy to trzeba jakoś specjalnie przygotować RTOS do tego czy on powinien sam wiedzieć już co robić?
    Kusi mnie bardzo nauka TMS320F28xxx gdzie mamy takie mikrokontrolery. Jest sens się w ogóle tym interesować?

    stmx wrote:
    Jeżeli to projekt komercyjny to tym bardziej jestem zdziwiony. Łatwiej jest zmodularyzować program wielowątkowy i rozdzielić zadania na zespól.

    Zastosowanie RTOS-a ma wiele plusów, praktycznie bez minusów.

    No niestety jest taki dział w mojej firmie gdzie jest jedna osoba i robi takie dziwne projekty. Jest to dość uciążliwe bo brakuje mi kogoś typowo od softu ale póki kogoś mi nie znajdą to sobie sam muszę radzić :)
  • #15
    Freddie Chopin
    MCUs specialist
    -XantiO- wrote:
    A jak sprawa z RTOSem wygląda jak są obecne w uC dwa lub więcej fizyczne rdzenie? Czy to trzeba jakoś specjalnie przygotować RTOS do tego czy on powinien sam wiedzieć już co robić?

    Mało który RTOS (jeśli mowa o darmowych, to chyba praktycznie żaden?) ma obsługę wielu rdzeni. Inną kwestią jest to, że typowy STM32 ma tyle mocy, że jak napiszesz aplikację "z głową", to uciągnie 20 sporych wątków, choć ma tylko 1 rdzeń. Oczywiście jeśli zadaniem każdego z tych 20 wątków będzie liczenie FFT, to może nie działać tak jak chcesz, ale w typowych zastosowaniach na prawdę ciężko te układy wykorzystać w 100%.

    -XantiO- wrote:
    Kusi mnie bardzo nauka TMS320F28xxx gdzie mamy takie mikrokontrolery. Jest sens się w ogóle tym interesować?

    Najpierw sobie sprawdź narzędzia, bo może się okazać, że potrzebujesz kompilatora za 10000 $, debuggera za 5000 $ i RTOSa za 50000 $.

    -XantiO- wrote:
    No niestety jest taki dział w mojej firmie gdzie jest jedna osoba i robi takie dziwne projekty. Jest to dość uciążliwe bo brakuje mi kogoś typowo od softu ale póki kogoś mi nie znajdą to sobie sam muszę radzić :)

    outsourcing rozwiązuje i takie problemy [;
  • #16
    User removed account
    Level 1  
  • #17
    -XantiO-
    Level 21  
    Freddie Chopin wrote:

    Mało który RTOS (jeśli mowa o darmowych, to chyba praktycznie żaden?) ma obsługę wielu rdzeni. Inną kwestią jest to, że typowy STM32 ma tyle mocy, że jak napiszesz aplikację "z głową", to uciągnie 20 sporych wątków, choć ma tylko 1 rdzeń. Oczywiście jeśli zadaniem każdego z tych 20 wątków będzie liczenie FFT, to może nie działać tak jak chcesz, ale w typowych zastosowaniach na prawdę ciężko te układy wykorzystać w 100%.

    To akurat wiem bo zazwyczaj korzystam z STM32F4xx i to w większości wypadków już jest jak strzelanie z armaty do wróbli.

    Freddie Chopin wrote:

    Najpierw sobie sprawdź narzędzia, bo może się okazać, że potrzebujesz kompilatora za 10000 $, debuggera za 5000 $ i RTOSa za 50000 $.

    Kompilator, debuger i prawdopodobnie RTOS byłby dostępny u mnie w firmie więc miałbym "tani" start w nauce.

    Freddie Chopin wrote:

    outsourcing rozwiązuje i takie problemy [;

    Ale to nie rozwiąże problemu, że czasem fajnie byłoby mieć kogoś do pogadania :)
    A tak na poważnie to nabór jest otwarty na stanowisko więc to kwestia czasu co mnie bardzo cieszy.

    stmx wrote:
    Widzę że widzisz RTOS jak desktopowy OS. Pomino tego że się nazywają Operting System to niewiele mają ze sobą wspólnego.

    Procesory wielordzeniowe to temat rzeka i jednym postem na forum problemu nie rozwiążemy. Generalnie problem komunikacji między rdzeniami jest bardziej złożony.

    proponuję poczytaj o AMP SMP, i BMP


    Mam nadzieję, że jednak widzę to inaczej niż desktopowy OS. A poczytam na pewno o tych zagadnieniach bo po to jest ta dyskusja abym dowiadywał się czegoś nowego.
  • #18
    BlueDraco
    MCUs specialist
    Ja np. w moich projektach nie używam RTOS, chociaż niewątpliwie jest spora grupa projektów, których zrobienie bez RTOS graniczy z niemożliwością i jest nieopłacalne (np. cokolwiek, co używa TCP/IP).
    Zwykle rozpisuję wszytskie zadania 2w postaci automatów realizowanych w przerwaniach (timera lub peryferiów), do tego pewna liczba własnych przerwań i otrzymujemy elegancki system zdarzeniowy.
    RTOS (podobnie jak mnóstwo innych technologii informatycznych) jest sposobem na zrobienie czegoś skomplikowanego bez nadmiernego wysiłku intelektualnego. Piszemy kręcące się w kółko bez sensu pętle zdarzeń i przy użyciu RTOSa udajemy, że mamy tyle procesorów ile pętli - prosto, leniwie, mało efektywnie (to samo można powiedzieć o wielu innych pomysłach informatycznych, np. językach takich jak Python czy Lua, co wcale nie znaczy, że nie należy ich używać).

    Przestawienie się na programowanie czysto zdarzeniowe wymaga zmiany myślenia o programowaniu - zamiast niekończących się zadań chodzących w kółko mamy kończące się, wywoływane wtedy, kiedy trzeba, procedury obsługi zdarzeń. Pewnie na początku jest to trudne, ale po opanowaniu takiego podejścia - skutkuje dużo wyższą wydajnością i krótszymi czasami reakcji. W moich projektach pisanych w ten sposób obsługuję ponad pół miliona zdarzeń na sekundę na 80 MHz STM32L4, i nie jest to obsługa bardzo prosta. Jednocześnie chodzi USB, system plików i parę innych rzeczy.
  • #19
    User removed account
    Level 1  
  • #20
    BlueDraco
    MCUs specialist
    Każde zadanie, które na cokolwiek czeka, tzn. każde zadanie kręci się w kółko z punktu widzenia programisty, bo każde ma postać pętli. RTOS marnuje czas procesora na przełączanie zadań, żeby program nie marnował go więcej w pętlach aktywnego oczekiwania. W modelu zdarzeniowym nie ma przełączania zadań, bo program nie "zatrzymuje się w oczekiwaniu" - obsługa zdarzenia kończy się i już. To po prostu inne podejście do programowania, pewnie trudniejsze, ale dużo efektywniejsze niż posługiwanie się zadaniami, kolejkami i magikiem, który pilnuje, żeby się nie posypało (RTOSem).

    Są też środowiska zdarzeniowe będące hybrydami RTOS i modelu zdarzeniowego, w których nie ma pętlących się zadań, ale jest oprogramowanie zarządzające kolejkami i zdarzeniami.Zdaje się, że tak właśnie jest napisane oprogramowanie Nordic na nRF5xxxx (protothreads lub coś podobnego).
  • #21
    LChucki
    Level 31  
    BlueDraco wrote:
    W modelu zdarzeniowym nie ma przełączania zadań, bo program nie "zatrzymuje się w oczekiwaniu" - obsługa zdarzenia kończy się i już.

    Tyle, że zadanie może wykonywać się długo, np zapis dużego pliku, programowe dekodowanie JPG. Wtedy trzeba rozbić na mniejsze fragmenty co bywa upierdliwe.
  • #22
    Freddie Chopin
    MCUs specialist
    BlueDraco wrote:
    Piszemy kręcące się w kółko bez sensu pętle zdarzeń i przy użyciu RTOSa udajemy, że mamy tyle procesorów ile pętli - prosto, leniwie, mało efektywnie

    Proponuję sprawdzić czy faktycznie jest to tak mało efektywne jak to malujesz [; Generalnie Twój post jest "prawie" że obiektywny i "wyjątkowo" wyważony (te sugestie że rozwiązanie oparte o zdarzenia jest dla osób bardziej rozwiniętych intelektualnie - miód!) (;
  • #23
    User removed account
    Level 1  
  • #24
    Freddie Chopin
    MCUs specialist
    BlueDraco wrote:
    Zdaje się, że tak właśnie jest napisane oprogramowanie Nordic na nRF5xxxx (protothreads lub coś podobnego).

    Protothreads to scheduler tyle że bez wywłaszczania. Ma to tyle samo wspólnego z system eventowym co zwyczajny RTOS. Swoją drogą Twoja opinia naprawdę jest mocno nietrafiona, ponieważ dobrze zrobiony program wielowątkowy właśnie _JEST_ zdarzeniowy, inaczej po prostu nie mógłby w ogóle działać (bo jakiś wątek by w kółko blokował pozostałe). Do tego zrobienie systemu w 100% zdarzeniowego na RTOSie jest banalnie proste i wymaga po prostu użycia kolejki + grupy tasków (oczywiście może być jeden) które z tej kolejki pobierają zdarzenia do obsłużenia.
  • #25
    -XantiO-
    Level 21  
    BlueDraco wrote:
    Każde zadanie, które na cokolwiek czeka, tzn. każde zadanie kręci się w kółko z punktu widzenia programisty, bo każde ma postać pętli. RTOS marnuje czas procesora na przełączanie zadań, żeby program nie marnował go więcej w pętlach aktywnego oczekiwania. W modelu zdarzeniowym nie ma przełączania zadań, bo program nie "zatrzymuje się w oczekiwaniu" - obsługa zdarzenia kończy się i już. To po prostu inne podejście do programowania, pewnie trudniejsze, ale dużo efektywniejsze niż posługiwanie się zadaniami, kolejkami i magikiem, który pilnuje, żeby się nie posypało (RTOSem).

    Są też środowiska zdarzeniowe będące hybrydami RTOS i modelu zdarzeniowego, w których nie ma pętlących się zadań, ale jest oprogramowanie zarządzające kolejkami i zdarzeniami.Zdaje się, że tak właśnie jest napisane oprogramowanie Nordic na nRF5xxxx (protothreads lub coś podobnego).


    Piszesz, że w modelu zdarzeniowym nie ma miejsca na oczekiwanie. A co w sytuacji gdy mamy zdarzenie o dość wysokim priorytecie ale gdzies w tym zdarzniu musimy zrobić pewną pauze/przerwę na naprzykład 100ms? Wtedy z tego co rozumiem musimy czekać w tym zdarzeniu mimo, że procesor się nudzi czyż nie? A taki RTOS by nam ten czas procesora wypełnił innym procesem o niższym priorytecie lepiej zarządzając całymi zasobami. Czy ja to dobrze rozumiem?

    Ja mam w tej chwili własnie takie przerwy wykorzystane do robienia obliczeń i na danych nagromadzonych w ram przez DMA. Jest to dość efektywne wykorzystanie zasobów lecz i tak przy "dłóższej" przerwie rzędu 250ms tych danych jest za mało :)
  • #26
    LChucki
    Level 31  
    Jeśli przełączanie zadań RTOS pożera za dużo czasu procesora, nie ma problemu aby przełączanie wywoływać nie co 1ms a co 10. Na zużycie RAM na osobne stosy lekarstwa nie ma ale chyba nik rozsądny nie uruchamia RTOS na ArduinoUNO.
  • #27
    BlueDraco
    MCUs specialist
    Z zasady w obsłudze zdarzeń nie ma oczekiwania. Obsługa z oczekiwaniem musi być rozbita na dwa zdarzenia.

    Nie ma się o co spierać. Piszemy w C, bo tak jest łatwiej i wygodniej (a na ARM - pewnie i kod lepszy, ale na PIC16 czy 51 żaden kompilator nie wygeneruje kodu lepszego niż średnio dobry programista). Piszemy pod RTOS, bo łatwiej i wygodniej, chociaż system zdarzeniowy jest z zasady wydajniejszy. Piszemy w Pythonie, bo 5 linijek kodu z wywołaniem gotowej biblioteki robi 10 razy wolniej to, co w C musielibyśmy pisać pół roku. W programowaniu zawsze idziemy na jakieś kompromisy pomiędzy wydajnością, wkładem pracy i łatwością uzyskania działającego rozwiązania. To samo, co piszę o RTOS vs. systemie zdarzeń można napisać o "pętli głównej" vs. RTOS.

    Tu nie chodzi o to, jak często przełączamy zadania, tylko o to, że w ogóle je przełączamy, co przy podejściu zdarzeniowym jest zbędne, bo obsługa zdarzenia nie ma stanu wymagającego zachowania - stosu, rejestrów procesora.

    System zdarzeń będzie zawsze wydajniejszy od rozwiązania z RTOS, trudniejszy do napisania i mniej zasobożerny. Każdy wybiera to, co mu pasuje.
    Nikogo nie namawiam na programowanie w asemblerze, chociaż sam 51 ani PIC10/12/16 nie miałbym sumienia mordować kodem generowanym przez kompilator. Nikogo też na siłę nie nawracam na zdarzenia, a zwłaszcza Freddiego zakochanego w swoim RTOS. Po prostu mam nieco inne sympatie.
    W tym wątku podobno dyskutujemy o metodach wydajnego programowania wielowątkowego - właśnie przedstawiłem swoje przemyślenia na ten temat i okazuje się, że paru Kolegom bardzo one nie w smak i koniecznie muszą coś nawytykać.
  • #28
    User removed account
    Level 1  
  • #29
    Freddie Chopin
    MCUs specialist
    LChucki wrote:
    Jeśli przełączanie zadań RTOS pożera za dużo czasu procesora, nie ma problemu aby przełączanie wywoływać nie co 1ms a co 10.

    RTOS nie przełącza zadań z częstotliwością ticka systemowego. Okres ticka systemowego służy tylko i wyłącznie do określenia rozdzielczości delayów, timeoutów itd. Ewentualnie wpływa jeszcze na to jak często przełączane są zadania o identyczny priorytecie jeśli są stale odblokowane (tzw. round-robin scheduling), co w typowym przypadku i tak praktycznie nie występuje. Jak system nie ma co robić (albo jakiś wątek liczy ostro FFT, więc zagarnia dla siebie cały czas), to wątki _NIE_ będą przełączane wcale, z drugiej strony jest możliwe również przełączanie ich 10000 razy w ciągu sekundy, nawet jeśli tick systemowy ma okres 100 ms.

    Z niezrozumienia tej podstawowej prawdy wynikają potem przesądy, że jak system ma ustawiony tick systemowy np. na 10 ms, to nie jest w stanie zareagować na jakiekolwiek zdarzenie szybciej niż te 10 ms. Jest to całkowicie błędne, przy odpowiednim priorytecie reakcja będzie w zasadzie natychmiastowa, a opóźnienie wynikać będzie jedynie z czasu przełączania kontekstu (zwykle coś w rejonie 100-200 cykli zegara).

    BlueDraco wrote:
    W tym wątku podobno dyskutujemy o metodach wydajnego programowania wielowątkowego - właśnie przedstawiłem swoje przemyślenia na ten temat i okazuje się, że paru Kolegom bardzo one nie w smak i koniecznie muszą coś nawytykać.

    Pytanie jest takie - na czym opierasz swoje przemyślenia? Na teoretycznych rozważaniach, czy sprawdziłeś to w praktyce?

    BlueDraco wrote:
    obsługa zdarzenia nie ma stanu wymagającego zachowania - stosu, rejestrów procesora.

    Opisujesz to jako zaletę, jednak realnie jest to cecha kompletnie neutralna, ponieważ - zależnie od sytuacji - może być również wadą. W końcu jednak programy jakiegoś "stanu" potrzebują i gdzieś to trzeba zapisywać. Zgadnijmy gdzie... hmm... w zmiennych globalnych? (; Ciekawe więc jak dobrze się to podejście skaluje [;

    W RTOSie możesz sobie zrobić system zdarzeniowy z naprawdę minimalnym narzutem. W systemie zdarzeniowym wielowątkowości już nie zrobisz.
  • #30
    User removed account
    Level 1