Pisanie kodu źródłowego aplikacji

Po wygenerowaniu za pomocą Processor Experta interfejsu programistycznego do peryferiów mikrokontrolera praca z tym narzędziem jest zakończona. Można w tym momencie przejść do drugiego etapu tworzenia aplikacji, którym jest pisania kodu źródłowego aplikacji. W tym celu należy zmienić perspektywę programu Kinetis Design Studio z Hardware na C/C++. Tu programista posługuje się przede wszystkim dwoma narzędziami: menedżerem projektu oraz edytorem. Omówmy je po kolei.

Menedżer projektu znajduje się w oknie Project Explorer i jak sama nazwa wskazuje służy do zarządzania projektami programistycznymi oraz plikami tychże projektów. Narzędzie to pozawala między innymi na dodawanie plików do projektu, usuwanie plików z projektu i wybieranie, które z nich mają zostać otwarte do edycji. Widok okna CodeWarrior Projects z przykładowym projektem pokazano na rysunku 14.

Rys. 14. Okno zarządzania projektami i plikami projektów

Drzewo projektu składa się z sześciu folderów (katalogów) fizycznych (istniejących fizycznie na dysku twardym) i dwóch wirtualnych. Pierwszym folderem wirtualnym jest Binaries. Zawiera on plik wykonywalny (z rozszerzeniem .elf), który powstaje po skompilowaniu i zlinkowaniu projektu. Drugim folderem wirtualny jest Includes. Po jego otworzeniu programista uzyskuje dostęp do listy różnych plików nagłówkowych projektu. Foldery fizyczne to:

• Debug – folder z różnymi plikami związanymi z procesem debugowania. Szczególnie ważny jest tu plik o nazwie makefile określający reguły kompilacji i linkowania programu.
• Documentation – folder z automatycznie tworzoną przez CodeWarrior dokumentacją projektu,
• Generated_Code – folder z zawierającymi kod źródłowy plikami wygenerowanymi przez Processor Experta,
• Project_Settings – folder z plikami konfiguracyjnymi projektu oraz plik startup.c zawierający kod uruchomieniowy dla mikrokontrolera,
• Sources – folder, który zawiera najważniejszy plik projektu – main.c,
• Static_Code – folder z plikami, w których zdefiniowane są nazwy rejestrów i bitów rejestrów mikrokontrolera, jak również nazwy własne używane w plikach generowanych przez Processor Experta,

Dodatkowo do projektu dołączony jest plik ProcessorExpert.pe. Jest to plik, który przechowuje listę wybranych za pomocą Processor Experta komponentów oprogramowania wraz z ich konfiguracją. Poprzez wywołanie tego pliku programista może w każdej chwili wrócić do wykonanej wcześniej konfiguracji interfejsu programistycznego peryferiów mikrokontrolera i ją edytować według potrzeb.

Warto w tym miejscu bliżej przyjrzeć się plikowi main.c, który powyżej określony został jako najważniejszy plik projektu. Jest tak, gdyż to w nim bezpośrednio, lub poprzez odwołania do innych plików są implementowane zadania przewidziane do realizacji przez mikrokontroler. Zawartość pliku main.c tuż po stworzeniu projektu, a więc jeszcze przed ingerencją weń programisty, można podzielić na dwie części. Pierwsza część to dyrektywy #include z odwołaniami do innych plików projektu.

#include "Cpu.h"
#include "Events.h"
#include "RTC1.h"
#include "PE_Types.h"
#include "PE_Error.h"
#include "PE_Const.h"
#include "IO_Map.h"

Na tym można zakończyć opis pierwszego z narzędzi perspektywy C/C++, a więc menedżera projektu. Drugim kluczowym narzędziem do tworzenia kodu źródłowego aplikacji jest edytor. Jest to narzędzie, które umożliwia edycję plików projektu programistycznego. Programista chcąc przejść do trybu edycji danego pliku wyszukuje go w oknie Project Explorer, a następnie dwukrotnie na niego klika. W efekcie plik zostanie otworzony do edycji w polu edytora, które znajduje się w centralnej części okna Kinetis Design Studio. W edytorze może być otwarty więcej niż jeden plik. Każdy z otwartych plików ma przyporządkowaną zakładkę, dzięki czemu można się między nimi w wygodny sposób przełączać. Samo narzędzie edytora ma standardową funkcjonalność. Otwarte w nim pliki mają postać tekstu, na którym można wykonywać standardowe operacje np. dopisywania, usuwania, modyfikowania itp. Tekst w edytorze jest kodem źródłowym przeważnie napisanym w C. Programista używając elementów tego języka takich jak np. zmienne, tablice, struktury, wskaźniki, funkcje czy też instrukcje warunkowe może rozwijać kod źródłowy aplikacji. Edytor oferuje różne mechanizmy, które ułatwiają czytanie kodu. Są to między innymi: kolorowanie składni języka programowania i numerowanie linii kodu. Jako przykład rysunek 15 pokazuje plik main.c otworzony w edytorze.

Rys. 15. Widok edytora z otwartym plikiem main.c

Gdy czynność tworzenia kodu źródłowego aplikacji jest zakończona, należy skompilować projekt (menu programu CodeWarrior: Project -> Build Project) . Przebieg procesu kompilacji widoczny jest w oknie Console (rysunek 16).

Rys. 16. Okno z logiem dotyczącym procesu kompilacji projektu programistycznego

Uruchamianie i debugowanie aplikacji

W pierwszym etapie tworzenia aplikacji wygenerowany został interfejs programistyczny do peryferiów mikrokontrolera. W ramach drugiego etapu programista napisał kod źródłowy aplikacji w oparciu o wygenerowany interfejs. W ostatnim, trzecim etapie poprawność działania aplikacji jest sprawdzana poprzez jej uruchomienie i debugowanie na platformie sprzętowej.

Zanim będzie można przystąpić do zdebugowania aplikacji, należy wybrać programator/debuger, który będzie używany. W tym celu należy z menu głównego Kinetis Design Studio wybrać Run -> Debug Configurations. Otworzone zostanie okno o nazwie Debug Configurations. W jego lewej części dostępna jest lista, w której każdy z rekordów oznacza inną konfigurację debugowania. Wybrać należy GDB PEMicro Interface Debugging, gdyż taki właśnie programator/debuger udostępnia płytka FRDM-KL25Z. W wyniku wybrania konfiguracji debugowania stworzona zostanie nowa jej instancja o nazwie <nazwa projektu> Debug. Po prawej stronie okna Debug Configurations wyświetlone zostaną opcje konfiguracyjne, podzielone na kilka zakładek. W zakładce Debugger należy ustawić dwa parametry w związku z używaniem płytki FRDM-KL25Z. W polu Interface (interfejs debugera) wybrać należy OpenSDA Embedded Debug – USB Port, a w polu Device Name (symbol mikrokontrolera) zaznaczyć KL25Z128M4. Zaakceptowanie zmian potwierdzić należy wciśnięciem przycisku Apply.

Teraz już można przystąpić do debugowania aplikacji na płytce FRDM-KL25Z. W celu rozpoczęcia tego procesu z menu głównego programu Kinetis Design Studio należy wybrać opcję Run -> Debug. W tym momencie środowisko programistyczne wymusi zapis pliku wykonywalnego aplikacji do pamięci mikrokontrolera. Następnie mikrokontroler zostanie zresetowany i przygotowany do rozpoczęcia wykonywania aplikacji. Jednocześnie w Kientis Design Studio perspektywa C/C+ zostanie zmieniona na Debug. Dzięki temu programiście udostępnione zostaną narzędzia sterujące procesem debugowania i wizualizujące stan systemu na różnych etapach debugowania. Do sterowania debugowaniem przewidziany jest mechanizm pracy krokowej, pozwalający wykonywać kod etapami, a nawet linia po linii. Komendy do pracy krokowej dostępne są w podmenu Run menu głównego Kinetis Design Studio. Najważniejsze z nich to: Resume (wznowienie), Suspend (wstrzymanie), Terminate (zatrzymanie), Step Into (wejście do wewnątrz bloku kodu np. funkcji), Step Over (wyjście na zewnątrz aktualnego bloku kodu), Run to Line (wykonanie kodu do miejsca oznaczonego kursorem). Komendy te wywoływać można nie tylko z poziomu menu Kinetis Design Studio. Są one również dostępne (częściowo) w formie ikon pod menu (rysunek 17).

Rys. 17. Ikony służące do sterowania pracą krokową

Uzupełnieniem dla pracy krokowej w sterowaniu procesu sterowania debugowanem jest narzędzie do ustawiania tak zwanych pułapek (breakpointów). Pułapka to wybrana przez programistę linia kodu źródłowego, po wykonaniu której działanie aplikacji zostanie wstrzymane. Aby ustawić pułapkę należy w edytorze kliknąć na linię kodu, której wykonanie ma wyzwalać pułapkę, a następnie z menu Kinetis Design Studio wybrać Run -> Toggle Breakpoint. Po ustawieniu pułapki obok wskazanej linii kodu pojawi się symbolizująca pułapkę niebieska kulka Pułapki można włączać i wyłączać bez konieczności trwałego ich usuwania. Zarządzanie pułapkami realizowane jest z poziomu okna Breakpionts (rysunek 18).

Rys. 18. Okno Breakpoints z listą pułapek ustawionych w kodzie źródłowym

Ważnym narzędziem wizualizacji stanu systemu podczas debugowania jest wgląd do wartości typów danych aplikacji (np. zmiennych i struktur). Dostęp do tego narzędzia daje okno Expressions (rysunek 19), przy czym każdy typ danych, który programista chce obserwować, musi zostać dodany do tego okna ręcznie. Czynność tą wykonuje się poprzez zaznaczenie w edytorze wybranego typu danych, wywołanie prawym przyciskiem myszy menu kontekstowego oraz wybranie w wyświetlonej listy opcji Add Watch Expression…

Rys. 19. Okno do podglądu wartości typów danych

Rys. 20. Okno edytora w trybie debugowania aplikacji

Ostatnim z głównych narzędzii debugowania jest edytor. Poprzez kolorowanie na zielono linii kodu i zaznaczanie jej dodatkowo strzałką edytor informuje programistę na jakim etapie wykonywania aplikacji jest w danej chwili debuger (rysunek 20).

Uwaga: jest pierwsza część artykułu, drugą opublikowalismy pod adresem.