2009-07-08 23 views
6

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.

Odpowiedz

4

Za pomocą narzędzia, takiego jak IARvisualState, można wygenerować kod dla hierarchicznych automatów stanów bez osobnych stosów. Istnieje freebie SMC, która jest nieco mniej wydajna, z mniejszą liczbą funkcji, i która nie obsługuje ładnych zdjęć UML StateChart.

Można również ręcznie zakodować maszyny stanów jako funkcje z instrukcjami przełączników i zmiennymi statycznymi, które utrzymują stan.

Istnieją lekkie pseudo-wątki biblioteki oparte na komputerze stanu, które robią to za pomocą makr C. Sprawdź protothreads

3

Gorąco polecam patrząc na Quantum programming framework Miro Samka. Ma jeden z najbardziej wydajnych HSM-ów, który działa na wielu platformach, takich jak ARM7. Ma również różne poziomy złożoności struktury, aby dopasować ją do twoich potrzeb. Polecam również jego książkę o nazwie Practical StateCharts in C/C++. Ma hierarchiczną maszynę stanów w C i C++. Piękno tej struktury polega na tym, że nie jest trudno przejść z UML lub diagramów stanu do rzeczywistego kodu z pewną wydajnością. Ta frameworka może być uruchamiana jako własny program planujący lub używany razem z systemem RTOS.

W rzeczywistości zaimplementowałem własny HSM w C++ dla jednego z rodzinnych systemów RTOS mojej firmy z pewnym sukcesem. Użyłem wielu zasad projektowania Samka, ale nie jego kodu z powodu GPL (wersja bezpłatna) i cennika licencji komercyjnej (bez licencji GPL).

5

Czy wymeldowałeś się Adam Dunkels' Protothreads? Nazywa je „Lekki, Stackless Wątki w C”

Zamiast wymyślać koło, będę cytować tad z witryny protothreads bezpośrednio w linii tutaj:

Protothreads są niezwykle lekkie wątki Stackless Przeznaczony dla systemów o ograniczonej pamięci, takich jak małe systemy wbudowane lub bezprzewodowe węzły sieci czujników. Protoureads zapewniają liniowy kod dla systemów sterowanych zdarzeniami zaimplementowanych w C. Protothreads mogą być używane z lub bez bazowego systemu operacyjnego, aby zapewnić blokujące obsługę zdarzeń. Protardy zapewniają sekwencyjny przepływ sterowania bez złożonych maszyn stanów lub pełnej wielowątkowości.

Użyłem Protothreads & HSM Samek's QP - oba są dobrymi rozwiązaniami problemów w nakładających się domenach. W tym celu prawdopodobnie skłaniałbym się ku prototypom.

Wspomniał Pan o wyeliminowaniu komercyjnego systemu RTOS. Zastanawiasz się, czy to z powodu przestrzeni kodu, kosztów, inżynierii krzywych uczenia się, wydajności ... czy możesz po prostu zastąpić RTOS jednym z (wielu) darmowych? Chyba nie, ale nie zaszkodzi zapytać.

P.S. Dunkels ma również świetną stronę internetową z wieloma useful resources & software dla programistów embedded - sprawdź to (Contiki, stosy protokołów itp.)

1

Chciałbym również przejść do ram programowania Quantum!