On 02.11.2022 21:16, Atlantis wrote:
[...]
> Teraz sprawdzanie przycisków ma miejsce w innym tasku niż obsługa
> maszyny stanów. Domyślam się, że nie mogę tak po prostu w dowolnym
> momencie z innego tasku zamknąć połączenia, sprawdzić albo zmienić stanu
> maszyny stanów obsługującej odtwarzanie. Jaki jest najlepszy sposób na
> upewnienie się, że obsługa przycisków nie wywoła żadnej waznej funkcji
> zanim w innym tasku nie zakończy się wykonywać VS1003_handle()?
>
Poczytaj o mechanizmach synchronizacji w systemach wielowątkowych - nie
ma znaczenia czy to FreeRTOS, Linux, Windows czy coś innego - podstawy
są takie same, a API podobne. Na początek sprawdź hasła mutex (aka
binary semaphore), semafor, condition(al) varialble, bariera (np.
pthread_barrier, nie mylić z instrukcjami typu "memory barrier"
dostępnymi w niektórych CPU/MCU bo to co innego, chociaż jedno z drugom
jest powiązane). No i najważniejsze, to co leży u podstaw w/w pojęć -
dowiedz się co to jest operacja atomowa; chociaż w przypadku
programowania bare metal może być to temat trochę zaawansowany, to
poczytaj też o typach _Atomic (C) i std::atomic (C++), a także popatrz
jak ja się realizuje operacje atomowe na różnych platformach. Temat do
dalszych czytanek to lock-free programming (aka non-blocking
programming) - dosyć gorący temat ze względu na to, że wielordzeniowość
zeszła już na poziom MCU (Raspberry Pi Pico, ESP32).

do góry

On 03.11.2022 07:22, JDX wrote:

> Poczytaj o mechanizmach synchronizacji w systemach wielowątkowych - nie
> ma znaczenia czy to FreeRTOS, Linux, Windows czy coś innego - podstawy
> są takie same, a API podobne. Na początek sprawdź hasła mutex (aka
> binary semaphore), semafor, condition(al) varialble, bariera (np.

Inaczej, to nie jest tak, że te pojęcia są dla mnie czymś zupełnie
nowym. Używałem RTOS-a na ESP8266/ESP32 (tam jest on właściwie
zintegrowany z SDK) oraz na Raspberry Pi Pico i jakieś proste zadania
synchronizowałem za pomocą semaforów, np. upewniając się, że zadanie w
jednym tasku nie zostanie wykonanie do momentu, aż nie pozwoli na to
pojawienie się przerwania. W pierwszym momencie tutaj chciałem użyć
podobnego mechanizmu z binary semaphoirami, ale najwyraźniej robię coś
źle, bo po jego dodaniu mam dość mocny spadek wydajności - w tym
przypadku słyszalny.

Na chwilę obecną przeszedł mi do głowy jeszcze pomysł, żeby zastosować
kolejkę wiadomości. Na zasadzie:

Task I/O:
- Sprawdza stan kolejnych przycisków
- Jeśli wykryte zostanie naciśnięcie przycisku na kolejkę wysyłana jest
wiadomość z kodem operacji do wykonania

Główny task:
- Cyklicznie wywołuje funkcję obsługującą maszynę stanów urządzenia
- Następnie pobiera wiadomość z kolejki i wykonuje odpowiadającą jej
operację, modyfikującą stan maszyny stanów.
- W kolejnym przebiegu maszyna będzie już obsługiwana w swoim nowym stanie.

Dzięki temu task I/O nigdy nie będzie wywoływał funkcji modyfikujących
stan maszyny działającej w drugim tasku.

do góry

On 03/11/2022 08:33, Atlantis wrote:
> Na chwilę obecną przeszedł mi do głowy jeszcze pomysł, żeby zastosować
> kolejkę wiadomości.

A w zasadzie jakiego multitaskingu używasz w tym FreeRTOS? Preemptive
czy cooperative?

Pewne rzeczy łatwiej zrobic w cooperative, ale do tego wymagana jest
higiena pisania kodu. Za to znikają problemy z synchronizacjami między
wątkami.

do góry

On 03.11.2022 08:33, Atlantis wrote:
[...]
> podobnego mechanizmu z binary semaphoirami, ale najwyraźniej robię coś
> źle, bo po jego dodaniu mam dość mocny spadek wydajności - w tym
> przypadku słyszalny.
>
Zwróć uwagę na to, że ,,sekcje krytyczne" obudowane muteksem/semaforem
powinny być możliwie krótkie, aby wątki nie blokowały się na zbyt długo
na tych muteksach/semaforach.

> Na chwilę obecną przeszedł mi do głowy jeszcze pomysł, żeby zastosować
> kolejkę wiadomości. Na zasadzie:
>
> Task I/O:
> - Sprawdza stan kolejnych przycisków
> - Jeśli wykryte zostanie naciśnięcie przycisku na kolejkę wysyłana jest
> wiadomość z kodem operacji do wykonania
>
> Główny task:
> - Cyklicznie wywołuje funkcję obsługującą maszynę stanów urządzenia
> - Następnie pobiera wiadomość z kolejki i wykonuje odpowiadającą jej
> operację, modyfikującą stan maszyny stanów.
> - W kolejnym przebiegu maszyna będzie już obsługiwana w swoim nowym stanie.
>
> Dzięki temu task I/O nigdy nie będzie wywoływał funkcji modyfikujących
> stan maszyny działającej w drugim tasku.
Właśnie wynalazłeś przekazywanie wiadomości i kolejkę komunikatów. :-)
https://en.wikipedia.org/wiki/Message_passing
https://en.wikipedia.org/wiki/Message_queue

To niezły pomysł, ale wydaje mi się, że czytanie kilku klawiszy i
enkodera da się załatwić kilkoma współdzielonymi (globalnymi) zmiennymi
obudowanymi muteksem bądź semaforem. Tak czy inaczej, synchronizacja
musi być jakoś zapewniona.

do góry

On Thu, 3 Nov 2022 09:07:39 +0100, heby <h...@p...onet.pl> wrote:
> Pewne rzeczy łatwiej zrobic w cooperative, ale do tego wymagana
> jest
> higiena pisania kodu. Za to znikają problemy z synchronizacjami
> między
> wątkami.

Heh no właśnie. Nie wspominając, że kooperatywie mniej pamięci zużyje
niż w FTOS. Idąc dalej.. to po co mu ftos? :)

--
Marek

do góry