logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Programowanie systemów wbudowanych: maszyny stanów sterowane danymi wejściowymi

ghost666 03 Gru 2023 12:05 693 0
  • We wcześniejszych lekcjach z tego cyklu (patrz YouTube) autor przedstawiał działanie maszyny stanów sterowanej zdarzeniami i warunkami strażnika, zgodnie z opisem zawartym w specyfikacji UML. Jednak, jeśli przeszuka się literaturę, można znaleźć również inne konstrukcje. Należy tutaj zauważyć, że nie chodzi o kosmetyczne różnice w prezentacji stanów, a o to, co zasadniczo napędza przejścia między nimi, ponieważ nie są to zazwyczaj zdarzenia. Zamiast tego, przejścia są oznaczone: „wejściami” i wyrażeniami zbudowanymi z tych: „wejść” (takimi jak: „gear_lever == UP && ! on_ground”, itp.). Wideo lekcja poniżej opowiada o takich maszynach stanów sterowanych wejściami, ich historię i związek z tymi sterowanymi zdarzeniami.





    Początki zainteresowania maszynami stanowymi sięgają lat 50. XX wieku, gdy George Moore i Edward Mealy opublikowali przełomowe prace na temat formalnych metod projektowania układów cyfrowych, generujących wyjścia w oparciu o wejścia i stan wewnętrzny całości. Wideo pokazuje przykłady takich układów i wyjaśnia sprzętowe maszyny stanowe jako technikę projektowania. Ta metoda miała później głęboki wpływ na oprogramowanie maszyn stanowych, które niosą wiele cech dziedziczonych po swoich sprzętowych korzeniach. Na przykład niektórzy projektanci oprogramowania wciąż używają kodowania binarnego dla stanów, jednocześnie pomijając inne istotne kwestie poruszone w artykułach Mealego i Moora, takie jak warunki wyścigowe.

    Maszyny stanowe sterowane wejściami

    Wejściami, które sterują sprzętowymi maszynami stanowymi, są bity lub grupy bitów. W oprogramowaniu grupy bitów, które mogą ulec zmianie, nazywane są zmiennymi. Dlatego oprogramowanie maszyn stanowych, które najbardziej przypominają swoje sprzętowe poprzedniki, również są sterowane wejściami, które są zmiennymi lub wyrażeniami zbudowanymi z tych zmiennych. Na przykład wideo pokazuje maszynę stanów sterowaną wejściami, operującą podwoziem samolotu. Wszystkie przejścia są oznaczone wyrażeniami, takimi jak: „(gear_lever == UP) && (prev_gear_lever == DOWN) && (squat_switch == UP)”. Takie wyrażenia boolowskie, znane z innych opisów maszyny stanów, są tutaj warunkami strażnikowymi. Z tego poziomu zrozumienia łatwo jest zidentyfikować maszyny stanów sterowane wejściami w kodzie, ponieważ każdy stan zaczyna się charakterystycznym if-em, który ocenia warunek strażnika.

    Kontekst wykonywania

    Interesującym pytaniem jest: kiedy maszyny stanów sterowane wejściami pracują, a kiedy czekają? W przypadku tych sterowanych zdarzeniami było to bardzo jasne. Te działają tylko wobec nowego zdarzenia. Kiedy nie ma dostępnych żadnych, są nieaktywne i nie robią nic. Jednak maszyny stanów sterowane wejściami są inne. Operują: „okresowo” lub „zawsze”. A zazwyczaj nie wynika to z diagramu, jak często ma to miejsce. Maszynę sterowaną wejściami czasami pokazuje się w kontekście, na przykład jako model Simulink uwidoczniony na filmie. Z tego szerszego kontekstu można przypuszczać, że musi napędzać ją jakiś: „Zegar”, co oznacza okresowe wykonanie. Jednak inne maszyny tego typu działają: „zawsze”. Na przykład są one często wykonywane bezpośrednio w głównej pętli while (1), gdzie zużywają wszystkie dostępne cykle procesora, bez względu na to, czy istnieją dla nich: „zdarzenia” do obsłużenia.

    Ryzyko wystąpienia wyścigu danych

    Prostota kontekstu wykonawczego to jedna z głównych przyczyn popularności maszyn stanów sterowanych wejściami. Nie ma potrzeby zdarzeń, ich kolejek i pętli, czy odwrócenia kontroli. Jednak wejścia sterujące maszyną stanów są często współdzielone z przerwaniami lub pochodzą bezpośrednio od urządzeń peryferyjnych (np. pinów GPIO). Takie wejścia zmieniają się asynchronicznie w stosunku do kodu maszyny stanowej. I tu doświadczeni programiści powinni natychmiast zauważyć ryzyko wyścigu (race condition). Wideo ilustruje ten punkt, omawiając potencjalne warunki wystąpienia takiej sytuacji w maszynie stanów sterowanej wejściami, operującej podwoziem samolotu.

    Maszyny stanów sterowane wejściami vs maszyny stanów sterowane zdarzeniami

    Ryzyko wystąpienia wyścigu danych można wyeliminować. W tym celu buforuje się poszczególne wejścia, aby nie zmieniały się nieoczekiwanie podczas kroku wykonania do zakończenia cyklu działania maszyny stanów. Jednak, jak pokazano w filmie, można zrobić jeszcze lepiej, buforując spójne migawki wszystkich powiązanych wejść jako parametry zdarzenia. W tym sensie można traktować wejścia jako: „proto-zdarzenia”, których parametry muszą być sprawdzane w warunkach strażnika, aby odkryć rzeczywiste zdarzenia. Takie spojrzenie prowadzi coraz bardziej w kierunku maszyn stanowych sterowanych zdarzeniami, gdzie te są generowane i buforowane zewnętrznie. Wideo powyżej ilustruje, jak buforowanie wejść zmienia kod maszyny stanowej sterowanej wejściami w kod przypominający operację dispatch() maszyny stanów sterowanej zdarzeniami.

    Podsumowanie

    Maszyny stanów sterowane wejściami i zdarzeniami stanowią ciągłe spektrum zastosowań. Te drugie są zazwyczaj bezpieczniejsze, ale i pierwsze mają swoje miejsce w przemyśle. Na przykład w grach komputerowych lub aplikacjach robotycznych odkrywanie zdarzeń silnie zależy od bieżącego stanu gry bądź robota. I nie jest możliwe do przeprowadzenia zewnętrznie do maszyny stanowej. Jednak to są zazwyczaj aplikacje sterowane czasem, gdzie warunki wyścigu danych są eliminowane poprzez synchronizację zmian wejść do wspólnej: „częstotliwości repetycji pętli” (podobnej do wspólnego sygnału zegarowego w synchronicznych układach cyfrowych).

    Źródła: https://www.embedded.com/programming-embedded-systems-input-driven-state-machines/

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
REKLAMA