Programowanie zoptymalizowane pod względem wykorzystania czasu procesora

Z pewnością wiele z przedstawionych poniżej sposobów i sposobików będzie Wam znanych, część być może bedzie nowych - generalnie chodzi jednak o całościowe uświadomienie sobie takiej koncepcji programowania tak, aby później można ją było świadomie stosować w praktyce (programowanie: od koncepcji do realizacji). Opisane tu sposoby będą przydatne zwłaszcza przy pisaniu większych programów, gdzie się "wiecej dzieje jednocześnie", ale mogą być również stosowane przy prostszych programach. Tyle tytułem wstępu - chciałbym jednocześnie zachęcić wszystkich programujących do opisywania własnych sposobów na programowanie - zwłaszcza o opisy koncepcji, podejścia do problemu i jego rozwiązania, bo dostępne jest mnóstwo przykładów, fragmentów procedur, etc ,etc, ale brak jest bardziej ogólnych zasad programowania, a wydaje mi się że zapotrzebowanie na tego rodzaju literaturę jest bardzo duże.

Przeważnie piszący programy skupiają się na sposobie rozwiązania problemu - jak najprościej (jeśli nie "jak w ogóle") napisać programik, który będzie realizował przewidziane przez nich zadanie. Jest to podejście słuszne, aczkolwiek "mikroskopowe". Trochę na zasadzie: " bierze się procedurę obsługi I²C, do tego dodaje obsługę klawiatury, wyświetlacza LCD, łączy sie razem i mamy programik". Potrzebne jest również myślenie "makroskopowe", które będzie nadrzędne, będzie obejmowało całość koncepcji programu. Jednym słowem - planowanie. Oczywiście ma to szczególnie sens przy większych programach, gdzie łatwo się jest pogubić w gąszczu procedurek, etykiet, skoków itp.

Częstokroć skupiając się na problemie bieżącym zapominamy o całości programu i o tym jaki wpływ na pozostałe procedury i programy bedzie miala opracowywana przez nas procedura. W skrajnym przypadku może to prowadzić do powstania sytuacji, kiedy napisane przez nas programy - każdy oddzielnie, działają prawidłowo, ale kiedy połączymy je wszystkie razem, to okazuje się, ze wzajemnie zakłócaja sobie pracę. W rezultacie program nie działa albo działa "skokowo", gubiąc po drodze dane. Jak temu przeciwdziałać - poniżej.

Dla ułatwienia zrozumienia działania procesora przygotowałem przykład opisowy - tzw. "łopatologiczne przedstawienie". Jednym z głównych zadań jakie wykonuje procesor jest tzw. pętla główna. Wyobraźmy ją sobie jako dośc duży, kwadratowy pokój. Pośrodku pokoju stoi człowieczek, który jest odpowiednikiem bieżącego procesu wykonywanego przez procesor.

Wlączamy zasilanie procesora - teraz nasz czlowieczek zaczyna chodzic sobie wokól pokoju zupelnie nic nie wykonując - po prostu chodzi w kólko. Aby dać mu jakieś zajęcie wprowadzamy do akcji podprogramy.   Wyobraźmy je sobie jako pokoje umieszczone wokól naszego głownego pomieszczenia.   Nasz czlowieczek idąc wokół scian, gdy napotyka  pokój, wchodzi do niego i wykonuje znalezione tam przez niego zadanie. Po czym wraca do pokoju głownego, idzie dalej wzdłóż sciany, do nastepnego pokoju i wykonuje następne zadanie.... I tak dalej, w kółko Macieju...

Na razie sytuacja jest prosta, ale jak to w życiu bywa, zaczynaja sie utrudnienia. Okazuje się bowiem, że nie zawsze jest możliwa natychmiastowa realizacja zadania przez procesor (czyli naszego czlowieczka).  Nie dowieźli danych i nasz człowieczek musi czekać na nie.   Siada więc sobie gdzieś na krzeselku albo chodzi w kólko po pokoiku podprogamu. Wyglada to tak:

Jak widzimy nasz czlowieczek uzależniony jest od przeplywu danych, musi siedzieć w pokoiku i czekać na nie. A przecież ma do wykonania prace takze w innych pokojach.  Może akurat w ktorymś z nich są juz wszystkie potrzebne dane, a on siedząc tutaj marnuje tylko czas, podczas gdy moglby wykonać inne zadania. I tu dochodzimy do sedna problemu. Są to wlaśnie tzw. martwe pętle, podczas których procesor testuje jakiś warunek i czekając na niego nie wykonuje nic więcej. Wprowadźmy więc usprawnienie. Nasz człowieczek po wejściu do każdego pokoju będzie sprawdzał czy są dla niego dane - jeśli będą -  wykona zadanie, jeśli nie - opuści on pokój i pójdzie sprawdzać następne pokoje. Jeśli w którymś z nich bedą dane, będzie wykonywał tam swoje zadanie. A oto jak to wyglada w praktyce:

W ten sposób nie mamy blokady  podprogamów w oczekiwaniu na dane. Nawet gdyby z jakiś powodów dana ta nie nadeszła nigdy, to program nie zawiesi się w martwej pętli - pozostałe podprogramy będą się dalej wykonywać bez zakłoceń. Oczywiście, bywają pewne krytyczne czasowo operacje, które muszą zangażowac całą moc obliczeniową procesora, gdyż obsługa w tym czasie innych zadań spowodowałaby utratę części danych.  W tej sytuacji rozsądnym rozwiązaniem tego problemu jest wykorzystanie przerwań - zwłaszcza, gdy dane przychodzą asynchroniczne.  

Najprostszym sposobem na sygnalizacje czy nadeszły ważne dane są flagi. Flaga jest bitem, ktorego ustawienie lub wyzerowanie informuje procesor o stanie danych. W postaci programu wygląda to nastepująco:

W ten sposób, jak widzimy, następuje dwustronna wymiana informacji pomiedzy podprogramami - jednocześnie są one na tyle niezależne, że nawet w wypadku błędu (przerwa w dopływie nowych danych do programu 2) nie następuje zawieszenie się pracy programu głównego (tak czy tak podprogram zawsze wyskakuje). To pozwala np. na utworzenie dodatkowego podprogramu monitorujacego, który w wypadku wystąpienia błedu przywraca normalną pracę systemu (restart programowy, czyszczenie zmiennych, ponowna inicjalizacja otoczenia itp.). Flagi mogą być sprawdzane, ustawiane lub zerowane przez kilka programów, jeśli podprogramy korzystają z tych samych danych.

Czasami zdarza się, że chcielibyśmy mieć kontrolę nad wykonywaniem sie pewnych podprogramów w odniesieniu do innych podprogramów.  Na przykład taka sytuacja:  jeśli wykonuje się poprogram nr 1, to w tym czasie nie powinien wykonywać się podprogram nr 2, bo oba korzystają ze wspólnych zmiennych i mogą wystąpić błedy. Taka sytuacja zdarza się, gdy jeden z podprogramów wykonuje się w pętli głównej, a drugi w przerwaniu.  Podczas obsługi przerwania, program z pętli głownej zostaje przerwany "w trakcie" i jest wykonywany program z przerwania. Jeśli istnieje niebezpieczeństwo zamazania danych przez program z przerwania, należy również uzyć flag dla zapobieżenia niechcianej modyfikacji.  

W ten sposób jeden podprogram jest zsynchronizowany z drugim - sa wzajemnie powiazane i nie nastapi nigdy "zderzenie danych".

Za pomocą flag można też przekazywać programom informacje o upływie czasu - są to tzw. znaczniki czasowe. Zasada jest prosta - jeden z programów (najczęściej jest to program obsługi przerwania, wywoływany cyklicznie co określony odcinek czasu) po obliczeniu zadanego odcinka czasu, ustawia flagę informującą pozostałe programy, że "czas upłynął". Podprogram z pętli głównej, testuje cały czas tą flagę i gdy wykryje jej ustawienie - wykonuje określoną sekwencję działań. Oto przykład:

W ten sposob nasz podprogram z pętli głównej wykonuje się np. co 1 s, zamiast wielokrotnie szybciej - nie obciąża to nadmiernie procesora i pozwala na wykonywanie innych podprogramów w tym czasie. Tego typu zwolnione wykonywanie się programów ma sens w wypadku np.odczytu pomiarów, gdy nie zależy nam na dużej ilości próbek na sekundę - zwłaszcza, gdy do tego dochodzą opóźnienia związane z czasem konwersji wyników przez urządzenia zewnętrzne.

Flagi ze wzgledu na swoją jednobitowość nadają się do sygnalizacji  sytuacji dwustanowych - "jest" albo "nie ma". Czasami potrzebujemy zasygnalizowac więcej stanów - wówczas z pomocą przyjdą nam zmienne. W jednym bajcie możemy przekazać do 256 stanów, co jest wystarczające w większości wypadków.

Należy odróżnić tzw. zmienne sterujące procesami od zmienych przekazujących bezpośrednie dane - np. o temperaturze otoczenia. Odpowiednia budowa podprogramów pozwala na zbudowanie pewnych zespołów decyzyjnych - sterujących wykonaniem podprogramu w zależności od wartości zmiennej sterujacej. Innymi słowy, podprogram składa się z kilku - kilkunastu ścieżek wykonania, a wybór konkretnej ścieżki zależy od wartości naszej zmiennej sterujacej. Taki podział podprogramów na kilka - kilkanascie sekcji ułatwia programowanie ze względu na pewną modularność programu, przyporzadkowanie ścieżek programu różnym sytuacjom w systemie i wreszcie - co najwazniejsze - pozwala na dokonywanie wstrzymań działania podprogramu wewnątrz niego, bez stosowania pętli martwych. Nasz podprogram zostaje jakby "zamrozony" w jednym ze stanów (określanym przez zmienną sterującą) na dowolnie długi czas. W tym czasie może on czekać na pojawienie się danych, skończenie wykonywania się innego programu czy inną sytuacje. Jednocześnie nie jest wstrzymywana praca procesora - cały czas przeskakuje on od jednego podprogramu do drugiego wykonując powierzone mu zadania. Ale oto przykład programu:

Napisany w ten sposób podprogram, wywoływany cyklicznie w pętli, bedzie kolejno przechodził wszystkie swoje stany, w każdym bedąc tak długo, jak to potrzebne, a jednocześnie nie będzie martwego oczekiwania na dane.

Jak widzimy, podprogram w każdym ze swoich stanów dokonuje modyfikacji zmiennej sterującej - może to być inkrementacja, dekrementacja, wpisanie bezpośredniej wartości, skoki po kilka stanów na raz. To pozwala na dużą elastyczność naszego podprogramu. W pewnym sensie jest to samomodyfikacja programu, choć wykonana w sposób dozwolony (w przeciwieństwie do modyfikacji kodu programu w pamięci). 

W przerwach na oczekiwanie na dane procesor może wykonywać obsługę innych programów nie tracąc przy tym kontroli nad bieżąco wykonywanym podprogramem. Jednocześnie w każdej chwili możemy stwierdzić na jakim etapie wykonywania jest nasz podprogram. Wystarczy w tym celu sprawdzić zmienną sterującą.  

Ale pójdźmy jeszcze dalej - ten popdprogram będzie się wykonywał cyklicznie, po kolei przechodząc swoje stany od 0 do n i tak w kółko. Czasami jednak chcemy, aby podprogram wykonywał się tylko raz (podobnie, jak to ma miejsce w przypadku zwykłych podprogramów). Dodajmy zatem jeszcze jeden stan - stan spoczynkowy, w ktorym nasz podprogram, mimo że wywoływany cyklicznie, nie wykonuje nic. Będzie to wygladało następująco:

W tej sytuacji - po jednorazowym przejściu przez wszystkie stany, nasz podprogram zatrzymuje się w stanie 0, gdzie praktycznie nic nie robi (minimalnie obciążając przy tym procesor). Jedynym sposobem wyprowadzenia go z tego stanu jest wpisanie do zmiennej sterującej wartości 1 (albo też i innej, różnej od 0, bo możemy skakać do dowolnego fragmentu naszego podprogramu). W ten sposób dowolny, inny program może wyzwalać nasz podprogram jedynie zmieniając wartość zmienej sterującej. Po jednorazowym wyzwoleniu naszego podprogramu zaczyna on już jakby "żyć samodzielnie", aż do jego pełnego wykonania. Można to porównać do lawiny kamieni poruszonej rzutem jednego kamienia. 

Jest to bardzo wygodne np. przy obsludze klawiatury i wyzwalanych przez nacisnięcie klawiszy działaniach - we fragmencie odpowiadajacym danemu klawiszowi wpisujemy tylko wartośc, którą ma przyjąć nasza zmienna sterująca i gotowe. Dodatkową korzyścią (i często koniecznością) jest możliwość sprawdzenia czy nasz podprogram nie jest już w stanie "wyzwolenia" przez jakiś proces. Wystarczy sprawdzić zmienną sterującą i jeśli jest ona różna od zera, to nasz podprogram jest w trakcie wykonywania się.

Każdy z fragmentów podprogramu odpowiadający jednemu ze stanów, na które dzielimy nasz program powinien spełniać pewne kryteria, aby ten podział po prostu miał sens.

Po pierwsze, jeśli w podprogramie ma występować odwoływanie się do sprzętu, układów zewnętrznych (np. zewnętrznych pamięci EEPROM itp.), to kolejne stany powinny być tak uporządkowane, aby podczas każdego z nich następowało tylko jedno odwołanie do układów zewnętrznych, tak aby okres oczekiwania na dane przypadał na czas pomiędzy stanami (inicjalizacja transmisji w jednym stanie/wyskok ze stanu/odczyt danych w następnym stanie).  

Po drugie, jeśli nasz program jest dość skomplikowany, zawiera wiele instrukcji itd., itp., to należy starać się, aby zostały one podzielone na kilka fragmentów o zbliżonym czasie wykonania, tak aby uniknąć spiętrzania się obciążenia procesora w jednym ze stanów, podczas gdy w innych obciążenie to będzie bardzo małe. Generalnie należy dążyć, aby stany były dość krótkie czasowo. Umożliwi to dostęp do procesora innym podprogramom (ich stanom).   

Przy odwoływaniu się do układów zewnętrznych, przy różnego rodzaju transmisjach występują pewne sekcje krytyczne, które muszą sie wykonywać w pewnym, ściśle określonym czasie - zakłócenie tego czasu spowoduje błąd transmisji. Natomiast pomiędzy tymi sekcjami mogą występować przerwy - zazwyczaj o dowolnie długim czasie trwania, bez obaw o zakłócenie transmisji. W zależności od rodzaju protokołu przerwy te mogą występować pomiędzy pojedyńczymi bitami danych, pomiędzy bajtami lub większymi zespołami bitów. To doskonale nadaje się do wykorzystania w naszych programach dzielonych na stany - w jednym ze stanów wykonujemy sekcje krytyczną dostępu do danych (1 bit, bajt lub wiecej bitów), pomiędzy nimi wyskakujemy ze stanu i mogą się wykonywać inne podprogramy, a następnie wchodzimy w następny stan, gdzie wykonuje się następna sekcja krytyczna itd, itd. W ten sposób transmisja danych, mimo, że stosunkowo wolna w porównaniu z szybkością wykonywania instrukcji procesora, nie zwalnia działania procesora, nie ma żadnych wstrzymań na czas transmisji danych (z wyjątkiem sekcji krytycznych) - dzieje się ona jakby "w tle", "w wolnych chwilach procesora". W ten sposób można w jednym układzie połączyć np. obsługę transmisji I²C, RS232, 1-wire, obsługę przetwarzania A/C, klawiatury, wyświetlacza, beeper'a i jeszcze kilku innych urządzeń i transmisji, a mimo to nie następuje żadne zazębianie się tych programów. Z punktu widzenia obserwatora wykonują się one równocześnie.     

Oto przykłady praktyczne realizacji w/w sposobu programowania - w  języku ASM dla procesorów 8051 i PIC. Proszę zwrócić uwagę na jedną rzecz - jesli procedurę wywołujemy poleceniem CALL, to wówczas każda ze ścieżek musi się kończyc poleceniem RET (RETURN). Jeśli natomiast procedurę wywołujemy poleceniem GOTO (SJMP), to każda ze scieżek musi się kończyć również GOTO (SJMP). Procedury te możemy stosować zarówno w pętli głownej, jak i w przerwaniach - przy przerwaniach powrotem z procedury bedzie oczywiscie rozkaz RETI.

Programy tego typu można dosyć mocno rozbudowywać, chociaż w praktyce nie zdarzyło mi się wyjść poza kilkanaście stanów zmiennej sterującej dla jednego podprogramu. Dzieląc w ten sposób kilka czy kilkanaście swoich podprogramów mamy pewność, że będą się one wykonywały niemalże równolegle, wzajemnie przeplatając swoje stany i nie nastąpi blokowanie jednego podprogramu przez drugi. Oczywiscie, nie wszystkie programy da się wykonać w opisany sposób - to już wymaga indywidualnego rozpatrzenia sytuacji.