Cze,
Od jakiegoś czasu rozwijam swoją konstrukcję sterownika do stacji pogodowej. Projekt robi się coraz większy i większy i w końcu dotarłem do etapu, w ktorym rozważam użycie jakiegoś RTOSa. Mam dużą bibliotekę własnego kodu obejmującą takie rzeczy jak kompleksowa obsługa komunikacji po USART czy I2C, mam pełną obsługę konsoli tekstowej. Do tego używam LwIP do zapewnienia komunikacji przez TCP/IP, oraz FatFS. Na koniec jest tam programowy radiomodem AFSK.. W chwili obecnej program jest realizowany w przerwaniach i w pętli for(;
, tak naprawdę można by go podzielić na kilka zasadniczych wątków
1. 9600x na sekundę ma się uruchamiać algorytm DSP obsługujący radiomodem. Musi to nastąpić bez względu na to co aktualnie robi procesor, ponieważ zabużenia tego tempa będą uniemożliwiały poprawne dekodowanie danych. Z tąd teraz jest to wyzwalane w przerwaniu o najwyższym priorytecie
2. Podczas nadawania do sieci radiowej, 1200x na sekundę ma się uruchamiać algorytm DSP wyliczający i aktualizujący wartość DAC. Zaburzenie wykonywania tej procedury kończy się błędami w transmisji, co czyni całe nadawanie jedynie marnowaniem cennych zasobów radiowych.
Pozostałe wątki nie wymagają już tak ścisłego czasu rzeczywistego i są wywoływane z pętli for
3. Wywoływanie LwIP_Packet_Handle(), który sprawdza czy z PHY od Ethnernetu nie napłynęły jakieś nowe dane do przetworzenia. Z racji szybkości transmisji to powinno wywoływać się bardzo często
4. Sprawdzanie czy nie zakończyła się transmisja po I2C czy USART, oraz czy w z wiązku z tym nie trzeba wywołać obsługi np. konsoli tekstowej (bo użyszkodnik wcisnał ENTER)
5. Sprawdzanie czy nie trzeba załadować do gadaczki pogodowej następnego pliku dźwiękowego z karty SD. To ma najniższy priorytet
A teraz przechodząc do meritum. Zakładam, że na chwikę obecną nie potrzebuje obsługi wyjątków, ani dynamicznej alokacji pamięci. Chodzi mi o napisanie własnego shedulera, który będzie obsługiwał te 5 w/w zadań i przy okazji zabezpieczał całe urządzenie przed przywieszaniem się w jednym z nich (np timeouty na magistrali I2C). Oczywiście mógłbym użyć gotowca typu FreeRTOS, czy nasz lokalny DistortOS ale chciałbym się przy okazji czego nauczyć, ot trochę sztuka dla sztuki.
Pytanie, jak ma w tej sytuacji wyglądać najproszy możliwy kernel? Jak rozumiem muszę głównie zadbać o przerzucanie zawartością PC i rejestrów pomiędzy procesami, bo sama organizacja pamięci jest już ustalana na etapie kompilacji (bo nie mam dynamicznej alokacji).. O czym jeszcze muszę wiedzieć?
Od jakiegoś czasu rozwijam swoją konstrukcję sterownika do stacji pogodowej. Projekt robi się coraz większy i większy i w końcu dotarłem do etapu, w ktorym rozważam użycie jakiegoś RTOSa. Mam dużą bibliotekę własnego kodu obejmującą takie rzeczy jak kompleksowa obsługa komunikacji po USART czy I2C, mam pełną obsługę konsoli tekstowej. Do tego używam LwIP do zapewnienia komunikacji przez TCP/IP, oraz FatFS. Na koniec jest tam programowy radiomodem AFSK.. W chwili obecnej program jest realizowany w przerwaniach i w pętli for(;
1. 9600x na sekundę ma się uruchamiać algorytm DSP obsługujący radiomodem. Musi to nastąpić bez względu na to co aktualnie robi procesor, ponieważ zabużenia tego tempa będą uniemożliwiały poprawne dekodowanie danych. Z tąd teraz jest to wyzwalane w przerwaniu o najwyższym priorytecie
2. Podczas nadawania do sieci radiowej, 1200x na sekundę ma się uruchamiać algorytm DSP wyliczający i aktualizujący wartość DAC. Zaburzenie wykonywania tej procedury kończy się błędami w transmisji, co czyni całe nadawanie jedynie marnowaniem cennych zasobów radiowych.
Pozostałe wątki nie wymagają już tak ścisłego czasu rzeczywistego i są wywoływane z pętli for
3. Wywoływanie LwIP_Packet_Handle(), który sprawdza czy z PHY od Ethnernetu nie napłynęły jakieś nowe dane do przetworzenia. Z racji szybkości transmisji to powinno wywoływać się bardzo często
4. Sprawdzanie czy nie zakończyła się transmisja po I2C czy USART, oraz czy w z wiązku z tym nie trzeba wywołać obsługi np. konsoli tekstowej (bo użyszkodnik wcisnał ENTER)
5. Sprawdzanie czy nie trzeba załadować do gadaczki pogodowej następnego pliku dźwiękowego z karty SD. To ma najniższy priorytet
A teraz przechodząc do meritum. Zakładam, że na chwikę obecną nie potrzebuje obsługi wyjątków, ani dynamicznej alokacji pamięci. Chodzi mi o napisanie własnego shedulera, który będzie obsługiwał te 5 w/w zadań i przy okazji zabezpieczał całe urządzenie przed przywieszaniem się w jednym z nich (np timeouty na magistrali I2C). Oczywiście mógłbym użyć gotowca typu FreeRTOS, czy nasz lokalny DistortOS ale chciałbym się przy okazji czego nauczyć, ot trochę sztuka dla sztuki.
Pytanie, jak ma w tej sytuacji wyglądać najproszy możliwy kernel? Jak rozumiem muszę głównie zadbać o przerzucanie zawartością PC i rejestrów pomiędzy procesami, bo sama organizacja pamięci jest już ustalana na etapie kompilacji (bo nie mam dynamicznej alokacji).. O czym jeszcze muszę wiedzieć?