We wbudowanej aplikacji zaprogramowanej na C na ARM7 (z wymaganiami przenośności), obecnie używającego komercyjnego systemu priorytetu RTU opartego na priorytetach, musimy usunąć tę zależność RTOS i dowolnej zależności od RTOS zgodnie z mandatem klienta. Mamy 8 zadań korzystających z wielu interfejsów HW, instrukcji sleep, komunikacji I2C. W rzeczywistości SW wykorzystuje dobrze funkcje RTOS do uproszczenia kodu, chociaż wymagania dotyczące czasu byłyby możliwe do zarządzania bez systemu operacyjnego czasu rzeczywistego.Alternatywy dla jawnych stosów w ćwiczeniach usuwania RTOS?
Kilka funkcji, w tym procedury wywoływane w wielu miejscach obecnie implementują sekwencje blokowania (dla tego wątku) wywołania funkcji sterownika I2c, instrukcji uśpienia itp. W oparciu o założenie, że odpytywanie na połączenia I2C/uśpienie jest nie do przyjęcia dla klientów, takie połączenia muszą być wtedy blokowane i zwracane. Kwestią oczywiście jest "powrót" do "instrukcji", ewentualnie 4 wywołania z poziomu najwyższego poziomu zadania, po zakończeniu I2C lub upłynięciu czasu uśpienia.
Koncentruję się w kierunku hierarchicznej konstrukcji maszyny stanów dla każdego zadania, z prostym harmonogramem na górze. Jednak obsługa kilku procedur, które tworzyły sekwencje wywołań blokujących, a teraz stają się maszyną stanów, która może zostać wywołana w kilku miejscach i na różnych głębokościach wywołania funkcji, wydaje się wymagać jawnej funkcji stosu dla każdego zadania, tak aby za każdym razem, gdy uruchamiam pod-stan-maszynę, mogę przydzielić stany dla tego procesu i wypchnąć je na "stos stanów" tego zadania, aby następne wywołanie programu planującego do tego zadania mogło zejść w dół stany hierarchiczne, aby kontynuować przetwarzanie tam, gdzie zostało "przerwane".
Czy widzisz inne architektury projektowe mające zastosowanie do problemu, rozważania na temat szybkiego przeniesienia kodu do paradygmatu zapobiegawczego lub wskaż na zasoby wzbogacające myślenie i dyskusje na temat technik i projektów "usuwania RTOS"?
Wszystkie trzy odpowiedzi dają dobry obraz stopnia rozwoju sytuacji w oparciu o maszynę państwową i powiązanych narzędzi, aby uniknąć ponownego wynalezienia koła. Nasi klienci nie przyjmą żadnej licencji, w tym licencji GPL. Z odpowiedzi wydaje się, że nie ma mowy o buforowaniu stanów, jeśli chce się używać hierarchicznych automatów stanów bez RTOS i z zakazem połączeń głosowych. Ponieważ hierarchiczna SM znacznie ułatwia przeniesienie istniejącego kodu przez zachowanie jego struktury (wywołanie funkcji do rutyny staje się wywołaniem maszyn podległych stanom), pójdę tą drogą, używając dostarczonych narzędzi jako dobrych przykładów. - Dzięki.