• Nie Znaleziono Wyników

5.3 Wykonanie o p rogram ow ania

5.3.2 W skazania dotyczące techniki program ow ania

Poniżej przedstaw ione wskazania odnoszą się do techniki programowania i są wynikiem w iedzy autora, uzyskanej z analizy literatury oraz z doświadczeń praktycznych. Będzie się tu naw iązywać do punktu 5.3.1 Algorytm pierwszej części realizacji oprogramowania i w wielu miejscach do przykładów zamieszczonych w dodatkach. W skazania te pozw alają na sprawniejszą realizację oprogramowania.

Pojęcie ‘technika program ow ania’[G5] obejmuje pew ną całość trudnych zagadnień zw iązanych z konstruowaniem programu. Opracowywanie kolejnego oprogramowania jest w zasadzie zadaniem niepowtarzalnym. Tw orzenie oprogramowania jest działalnością bardzo mocno naznaczoną indywidualnymi cechami programisty, mimo że może się on posługiwać określonymi wzorcami. M ateriał zam ieszczony poniżej ma charakter związany z indywidualnym podejściem autora do program owania i ujm uje najważniejsze zagadnienia.

rozpisanie zad ań

Rozpisanie zadań m a związek z tym co zamieszczono w punkcie 4.3.2, w tabeli 4.3 czyli etapem doboru systemu m ikroprocesorowego. Były tam, poszczególnym ogólnym zadaniom, przypisane zadania cząstkowe oraz sformułowane wym agania układowe zapewniające ich realizację. Rozpisanie zadań oznacza tu zbudowanie warstwy programowej.

rozdział 5 - Konstrukcja sprzętu, oprogramowanie, ich testowanie i uruchamianie

Rozpisanie zadań jest procesem iteracyjnym, choć może być ustalona kolejność podejm owania określonych zadań cząstkowych. K olejność może być taka jak w tabeli 4.3. M etodyka rozpisywania zadań rzutuje na oprogramowanie sterownika. Niewłaściwe zaprojektowanie układu na tym etapie, powoduje potrzebę zmian na płycie sterownika.

Dla przykładu (dodatek 2) obsługa wyświetlaczy je st realizowana układowo za pom ocą bufora wyjściowego.

Programowo bufor je st obsługiwany sekwencyjnie z określoną częstotliwością (333Hz). Wymaga to odm ierzenia okresu wyświetlania jednego z wyświetlaczy (500ps) i zbudowania procedury pobierającej z pamięci informację o znaku jaki ma być wyświetlany na kolejnym wyświetlaczu. Do odmierzania czasu wyświetlania służy licznik, któiy może być obsługiwany w sposób programowy lub za pom ocą podprogramu obsługi przerwania.

W podobny sposób buduje się oprogramowanie realizujące inne zadania.

Rozpisanie zadań realizowanych przez sterownik, nie musi polegać na rysowaniu schematu blokowego całego programu, ale na wypisaniu zadań cząstkowych, jakie m uszą zostać zrealizowane w obrębie zadania głównego i określeniu czasu okresu ich wykonywania. Trzeba przy tym przypisać poszczególne elementy wewnętrzne systemu mikroprocesorowego (w wyżej wymienionym przykładzie przypisanie liczników do odmierzania czasu wyświetlania), dla odpowiedniego zadania.

Program należy budować tak aby istniała możliwość realizacji pewnych nie przew idzianych zadań cząstkowych. Trzeba pamiętać aby koncepcja ta była otwarta, bo żadnego z napisanych program ów nie należy uznawać za zakończony. Oznacza to, że musimy przewidzieć możliwości rozbudowy program u o nowe zadania, które pojaw dąsię w wyniku wymagań, powstałych w czasie uruchamiania sterownika lub które jako dodatkowe narzuca zleceniodawca.

Przykładem nieprzewidzianego zadania mógłby być sterownik cyklokonwertora 3-fazowego - dodatek 6. Po pierwszym uruchom ieniu okazało się, że istnieje potrzeba wyprowadzenia sygnału indykującego początek przetwarzania wewnętrznego przetwornika A/C. Zadanie rozwiązano, poniew aż układ posiadał nadm iarow e wyjścia cyfrowe, a struktura początkowo zbudowanego programu, umożliwiała łatw ąjego modyfikację.

m odu larn ość p rogram u

Właściwie skonstruowany program ma być zbudowany z modułów. M odułom przypisuje się określone zadania. Zwykle są to:

- procedury wstępne (ustawieniem początkowych wartości komórek pamięci i przygotowanie do pracy urządzeń peryferyjnych,

- program główny (odwołania do podprogram ów realizujących zadania), - zbiór podprogramów i procedur.

Taka konstrukcja daje przejrzystość programu, typow ą dla strukturalnych języków program owania (np.Pascal), ale m ożliw ą do uzyskania także w asemblerze. M a to znaczenie zwłaszcza w czasie modyfikacji programu, jego rozbudowy itp. Konstrukcja m odułowa jest odzwierciedlona w listingu programu, gdzie wyróżnione są poszczególne podprogramy-procedury, które realizują wyodrębnione zadania. Zmiany w obszarze danego podprogramu nie w pływ ają na inne części programu. Jeśli modyfikujemy np. działanie klawiatury, to nie musimy szukać wszystkich odwołań do niej, rozproszonych w całym programie, tylko sięgamy do podprogram u obsługi klawiatury (np. inne przypisanie funkcji poszczególnym klawiszom).

Przy pisaniu podprogramów należy pilnować, aby nie były zbyt długie, bo stają się nieczytelne. N ie można podać jednoznacznie długości maksymalnej podprogram u (podanej jako liczba rozkazów), bo wiele zależy tu od sprawności samego programisty.

Należy pamiętać, aby w rejestrach ogólnego przeznaczenia nie przechowywać informacji, które pow inny być przechowywane dłużej, niż jednokrotne działanie danej procedury. Np. w podprogramie sekwencyjnej obsługi wyświetlaczy je st przechowywana informacja o aktualnie zapalonym elemencie. Jest ona m odyfikow ana za każdym wywołaniem tego podprogramu, ale nie może być zmieniona przez żaden urny fragment program u.

Oznacza to, że nie należy przechowywać tej informacji w rejestrze ogólnego przeznaczenia. W rejestrach ogólnego przeznaczenia można przechowywać tylko dane do jednokrotnego w ykorzystania w procedurze.

Zasadą w tworzeniu programu powinno być to, że przejście pomiędzy procedurami nie je st w ykonywane rozkazem skoku i nie może tu być uzasadnieniem możliwość skrócenia programu.

M ożliwe jest natomiast wykorzystanie pewnych procedur, wywoływanych z kilku podprogram ów z odpowiednio jasno ustalonymi parametrami wejściowymi i określonym wyjściem. Takim przykładem może być procedura przetwarzania wartości binarnej na cyfry, które należy później przesłać na w yśw ietlacz LCD.

rozdział 5 - Konstrukcja sprzętu, oprogramowanie, ich testowanie i uruchamianie

• w sp ółb ieżn ość zad ań i p rzerw an ia

Współbieżność zadań oprogramowania systemu mikroprocesorowego oznacza jego rozdział na dwa wyodrębnione tory:

- ciąg procedur i podprogramów, wykonywanych cyklicznie w programie głównym oraz - podprogramy obsługi przerwania.

Podprogramy obsługi przerw ania są wykonywane na żądanie pochodzące od źródeł wew nętrznych lub zewnętrznych mikroprocesora. Wtedy wykonywanie pętli głównej je st zawieszane i układ sterowania mikroprocesora powoduje przejście do wykonania odpowiedniego podprogram u obsługi przerwania.

Czynnościami tymi zarządza kontroler przerwań.

Przerwania zewnętrzne są skutkiem pojawienia się zdarzeń zewnętrznych względem mikroprocesora.

Przykładami m ogą być impulsy synchronizacji, sygnały awarii itp.

Przerwania wewnętrzne generowane są zdarzeniami zachodzącymi wewnątrz mikroprocesora. S ą to odpowiednie sygnały pochodzące od wewnętrznych liczników, od układu transmisji szeregowej i in.

Ich przyjęcie i wykonanie podprogramu obsługi przerwania je st realizowane różnie, przez różne mikroprocesory. M ikrokontrolery posiadają priorytetowy system obsługi przerwania. Hierarchizuje on zadania, określając wagę danego źródła przerwana wg. priorytetu, pozwalając na program ow ą blokadę i wygodne umiejscowienie podprogram u obsługi przerwania w przestrzeni adresowej. Jeżeli wykorzystuje się więcej niż jedno źródło przerwania, to każdemu ze źródeł należy przypisać określony priorytet. Program obsługi przerwania wykonuje oprócz swego głównego zadania, pew ną liczbę niezbędnych zadań pomocniczych. Dla przykładu w m ikrokontrolerach z rodziny MCS51 każdemu przerwaniu przypisuje się określony bank rejestrów.

Ponadto jeżeli dane przerw anie wymaga wykorzystania innych komórek pamięci (np. akum ulator) to należy przechować ich zawartość na stosie na czas podprogramu obsługi przerwania.

Ze względu na to, że przerw ania są ingerencją w ciąg wykonywanych rozkazów program u głównego, ich podprogramy obsługi m uszą być jak najkrótsze. O czasie ich wykonania decyduje nie tylko wykonanie podstawowych operacji, ale także zabezpieczenie na stosie pewnych danych, przełączenie banku rejestrów roboczych i inne czynności związane z ustaleniem możliwości przyjęcia innego przerw ania, w czasie wykonywania dotychczasowego. Rzeczywisty czas obsługi przerwania jest wydłużony o czas potrzebny na przyjęcie przerwania.

Pew ną alternatyw ą dla systemu przerwań opisanego powyżej, może być układ obsługi transmisji peryferyjnych (PTS) m ikrokontrolera Intel 80C196KC [MF9]. Pozwala on na wykonywanie w yszczególnio­

nych operacji obsługi urządzeń wewnętrznych mikrokontrolera bez udziału programowego. M ogą to być:

- transmisja pojedynczej danej (bajtu lub słowa), - transmisja bloku danych, wykonane do w ywołania podprogram u obsługi kończącego operację.

Przykładem wykorzystania PTS może być obsługa przetwornika analogowo-cyfrowego. Po zainicjalizo­

waniu pierwszego cyklu przetwarzania przetwornika A/C i zainicjalizowaniu układu PTS (odblokow anie, ustawienie priorytetów, określenie wektora i typu cyklu PTS), układ sterowania m ikrokontrolera oczekuje na sygnał przerwania, generowany po zakończeniu przetwarzania na danym kanale przetw ornika A/C. Po pojawieniu się przerwania, praca procesora zostaje wstrzymana i wykonywany je st następnie cykl PTS. W cyklu tym do przygotowanego obszaru RAM -u ładowany jest wynik z przetwornika. N astępnie przetw ornik A/C je st inicjalizowany do kolejnego przetwarzania, rozkazem z tego samego obszaru pam ięci (wcześniej przygotowany). Dalej procesor podejmuje wykonywanie programu aż do następnego cyklu.

W porównaniu z podprogram em obsługi przerw ania nie ma tu operacji na stosie (m.in. adres pow rotny), co znacznie skraca czas zatrzymania wykonywania programu głównego. O wzrastającym znaczeniu i w adze tego systemu świadczy to, że znajduje się on we wszystkich kolejnych wersjach m ikrokontrolerów Intel z serii MCS96.

rozdział 5 - Konstrukcja sprzętu, oprogramowanie, ich testowanie i uruchamianie

op tym alizacja

Jest to zagadnienie rozumiane jako proces zmniejszania określonego (lub wielu) w skaźnika jakości. D la oprogramowania systemów mikroprocesorowych w urządzeniach energoelektronicznych m ożna w ydzielić tu dwie grupy zagadnień.

Pierwsza grupa zagadnień jest związana z minimalizacją czasowa lub objętościowa programu. W ynika ona ze zwykle istniejących ograniczeń czasowych jakie s ą narzucone procesowi sterowania w yrażonych szybkością realizowania określonych procedur i podprogramów lub wielkości dostępnej pamięci. Jeśli szybkości procedur byłyby mniejsze od założonych, to należy znaleźć sposób przyśpieszenia działania programu. Racjonalne jest jednak przeprowadzanie tego po napisaniu w pełni sprawnych procedur.

Pojemność pamięci w przeważającej liczbie zadań nie stanowi ograniczenia w oprogramowaniu. M ogą się one zdarzyć w przypadku konieczności gromadzenia dużej ilości danych, których wykorzystanie jest warunkiem koniecznym realizacji określonego algorytmu sterowania, funkcjonującego z zadaną szybkością (zamiast liczenia korzysta się z danych stablicowanych).

Jak widać programy czasowo optymalne nie są zwykle optymalne ze względu na sw oją długość. W praktyce rozwiązania bazują na kompromisach.

Zmniejszanie czasu wykonywania pewnych procedur ma sens tylko dla procedur często wykonywanych, których udział w łącznym czasie pracy procesora jest największy. Tak jest dla podprogram ów obsługi przerwania np. wykonywanych dla realizacji przełączeń zaworów przekształtnika łub regularnie wywoływanych czasochłonnych procedurach obserwatorów, czy regulatorów wielkości szybkozmiennych.

W rozdziale 7 został przedstawiony przykład rozwiązania zagadnienia optymalizacji, związanego ze sterowaniem falownika napięcia MSI.

Druga grupa zagadnień dotyczy poszukiwania parametrów pracy przekształtnika i sterownika, które pozwalają na bezawaryjne jego działanie, a w pływ ają na objętość programu, czy szybkość jego wykonywania.

Takim parametrem może być częstotliwość przełączeń przekształtnika (podpunkt 4.2.3.2), ja k ą je st w stanie wygenerować sterownik mikroprocesorowy.

Jako przykład sterowania, gdzie ograniczeniem je st sterownik, może służyć przekształtnik typu BUCK, który może być wprawdzie przełączany z częstotliwością 20 kHz i wypełnieniem 50%. Chcąc zmieniać w ypełnienie w dużym zakresie, należy zmniejszyć częstotliwość przełączeń. Przykład rozwiązania podobnego zagadnienia został zamieszczony także w rozdziale 7.

• d oku m entacja program u

Można stwierdzić, że sam program, nawet dobrze działający jest bezwartościowy, jeśli nie jest do niego dołączona pełna dokumentacja. Trudno znaleźć sytuację, kiedy można uznać program za zakończony. Zwykle przez dłuższy czas po zakończeniu wstępnej fazy budowy oprogramowywania sterownika, następuje okres wprowadzania zmian i korekt, wynikających z wykrywanych błędów oraz pojawiających się now ych wymogów.

Wszystko to powoduje, że program musi być czytelny dla dokonującego zmiany przez odpowiednio długi okres czasu. Doświadczenie mówi, że po kilkunastu dniach od ostatniego kontaktu z programem, autor ma trudności z przypomnieniem sobie konstrukcji i sensu poszczególnych procedur. Dużym ułatwieniem s ą wtedy umieszczane w czasie pisania programu komentarze, w zwięzły sposób opisujące wykonywane kroki procedury.

Nie należy oszczędzać na umieszczanych komentarzach, zwłaszcza cenne są informacje zamieszczane na wstępie każdego podprogram u i procedury, opisujące jakie są ich zadania, parametry wejściowe i formę wyjścia.

W artościową inform acją je st także podanie które z rejestrów roboczych są zmieniane przez procedurę.

Właściwa forma graficzna listingu programu zwiększa jego czytelność, zw łaszcza gdy w yodrębnione są podprogramy, określone pola na etykiety, rozkazy i komentarze. Przy nadawaniu nazw etykietom i komórkom pamięci należy używać takich, które jak najdokładniej oddają znaczenie obiektu, bez obawy, że będ ą wydawać się zbyt długie.

Po wykonaniu program u należy wykonać w łaściw ą dokumentację końcow ą programu, n a k tó rą m ogą się składać wytyczne dla zadań sterownika, listing program u z bogatymi komentarzami, schem aty blokowe programu i opis słowny procedur. Taka dokumentacja pozwala w każdej chwili wrócić do program u przy wykonywaniu jakichś modyfikacji, a także umożliwia wykorzystanie pewnych procedur przenoszonych do innego programu. Dokumentacja ta powinna zostać wykonana w postaci wydruków i odpow iednich zbiorów na dyskietkach.

rozdział 5 - Konstrukcja sprzętu, oprogramowanie, ich testowanie i uruchamianie