Maszyny stanów na mikroprocesorach

[adi1525]

Witam, chciałbym się dowiedzieć kiedy powinno się używać maszyny stanów w systemach embedded. Uczę się programowania w c na PIC we własnym zakresie i doszedłem do programowania wyświetlaczy LCD z kartą i modułem WIFI. Używałem to tego harmony i tam właśnie jest używane programowanie przy wykorzystaniu maszyny stanów. Czy pisząc samemu małe programy na mikroprocesory opłaca się tego używać ?

[marek1707]

Co to znaczy "opłaca się"? Chodzi Ci o postać kodu korzystającą z tej lub innej formy zapisu maszyny czy w ogóle o stosowanie "stanów". Przecież gdy reakcja systemu ma być uzależniona nie tylko od aktualnego stanu wejść (przycisków, czujników itp), ale także od historii to już masz jakiś stan, który musisz pamiętać. W prostym programie (np. zamruganie jedną diodą a potem drugą) stanem jest samo miejsce wykonywania kodu - licznik instrukcji procesora. Najpierw "wskazuje" on pętlę mrugającą pierwszą a potem przechodzi do pętli mrugającej drugą diodą - stan zmienia się tak jak zmienia się miejsce wykonywania programu. To działa jednak tylko w przypadku trywialnych rzeczy, gdzie main() lub funkcje przez niego wołane może/mogą być wykonywane sekwencyjnie i nie trzeba nic robić równolegle. Stan "przesuwa się" wtedy tak jak przepływ sterowania w kodzie.

Używanie maszyn stanów zapisanych explicite bardzo poprawia czytelność i późniejsze zrozumienie kodu. Co więcej, wymyślenie jak nasza maszyna stanów ma działać już samo w sobie wymaga zastanowienia się (co jest chyba wystarczającym argumentem za), często pokazuje istotne luki w założeniach (nie przewidzieliśmy wszystkiego co tu wychodzi czarno na białym), pomaga znaleźć i reagować na zdarzenia/stany niezwykłe a także ułatwia "gromadzenie" pewnych funkcjonalności w jednym miejscu kodu. Jasne, czasem wymaga to rozpisania wszystkiego na papierze i odrobiny wysiłku bo większe automaty mogą mieć dziesiątki stanów, ale łatwość pisania oraz późniejsze uruchamianie i testowanie oddają to z nawiązką. A jeśli do tego dorzucisz prawie 1:1 przeniesienie algorytmu z kartki/głowy na kod i łatwość jego modyfikacji/rozbudowy - masz potężną argumentację by stosować to gdziekolwiek się da.

Idealnym, wręcz książkowym miejscem na automat jest interfejs użytkownika, np. system menu lub w inny sposób zrobione ustawianie parametrów i wydawanie poleceń. Czasem są to bardzo rozbudowane drzewa decyzyjne a ja spodziewam się, że system będzie zawsze responsywny (nie będzie miał bezsensownych "zwisów" czy opóźnień reakcji na przyciskanie klawiszy - nic mnie nie obchodzi, że coś tam musi zrobić). Dodatkowo obsługa tego interfejsu powinna być tylko małą częścią tego co procesor robi a np. wpisywanie nowych parametrów nie może wstrzymywać pracy reszty systemu. I dlatego automat wykonywany "w tle" nawet małego programu jest tu jak znalazł.

Niestety, w kodach które tutaj widujemy najczęściej to właśnie współpraca z użytkownikiem jest tą najważniejszą, blokującą całą resztę funkcjonalności operacją właśnie dlatego, że nikt z początkujących programistów automatów nie używa świadomie a jedynym "stanem" jest właśnie miejsce wykonywania programu.

[adi1525]

Wielkie dzięki, za tak wyczerpującą odpowiedź, w takim razie się w to wgłębię i zacznę wszystkie programy w ten sposób pisać. Dzięki !