Kod aplikacji i firmware

Większość kodu aplikacji jest zwykle napisana w języku wysokiego poziomu (C lub C++) i zwykle wykorzystuje typowe rozszerzenia kompilatora, takie jak obsługa przerwań w języku C, dzięki czemu możliwe jest napisanie prawie całego programu bez użycia asemblera.

Także fragmenty pisane w asemblerze można relatywnie łatwo przekonwertować, gdyż większość asemblerów ma podobne możliwości, różniąc się jedynie nieznacznie jeśli chodzi o składnię (np. w sposobie oznaczania niektórych trybów adresowania lub implementacji makr i innych cech wysokopoziomowych). Proste „wyszukaj i zamień” lub plik mapujący jedne symbole na drugie mogą wystarczyć do konwersji.

Zewnętrzny system operacyjny i biblioteki

Najlepiej jest, gdy istnieje wersja wykorzystywanego systemu operacyjnego i/lub bibliotek dla narzędzi GNU oraz dostępne jest stosowne wsparcie techniczne. Pliki Make i sterowanie uruchomieniem można wówczas stosunkowo łatwo skonfigurować w środowisku TrueSTUDIO.

Inna możliwość to sprzedaż przez producenta licencji na kod źródłowy i dostarczanie systemu/bibliotek w postaci przenośnego kodu wysokiego poziomu. W takim wypadku, trzeba wykonać taką samą pracę, jak zwykle przy pierwszym zakupie licencji, czyli konfigurację, kompilację i testowanie. Ostatnią możliwością jest dostępność systemu/bibliotek tylko w formie binarnej, bez wersji dla narzędzi GNU.

Nawet w takim przypadku prawdopodobna jest jednak możliwość wykorzystania plików w postaci binarnej, o ile nie jest zmieniany używany typ mikrokontrolera. Dla rdzeni  ARM istnieje standardowy Application Binary Interface (ABI), zdefiniowany przez ARM, który jest zaimplementowany w większości kompilatorów.

Nie jest wykluczone, że uda się skonsolidować (zlinkować) biblioteki w formie binarnej i uruchomić je bez problemu, ale może też być konieczne dokładne sprawdzenie różnic między kompilatorami, jeśli chodzi o zgodność z ABI. W razie wystąpienia różnic, istnieje możliwość napisania w asemblerze dodatkowego modułu uzgadniania, tzw. wrappera, zapewniającego, że po przejściu z funkcji GNU na inne ich wersje program będzie działał poprawnie.

Sprawdzenie poprawności

Jednym z najważniejszych zadań w procesie migracji jest powtórne sprawdzenie poprawności działania programu. Jest to konieczne, niezależnie od tego czy w kodzie zostały wprowadzone jakiekolwiek zmiany. Przeniesienie programu z jednego kompilatora na inny zawsze oznacza bowiem wygenerowanie minimalnie zmienionego kodu wyjściowego, jako że dwa kompilatory (a nawet dwie wersje tego samego kompilatora) dokonują nieco innej optymalizacji.

Dla projektów nierozpoczętych wysiłek włożony w opracowanie nowych testów nie powinien być większy niż przy wcześniej wykorzystywanych narzędziach. Dla projektów już istniejących, infrastruktura testująca może wymagać przeniesienia wraz z resztą projektu, co trzeba wziąć pod uwagę przy opracowywaniu planu migracji.

Jak uprościć proces migracji?

Na potrzeby tego tekstu założono, że migracja nie dotyczy zmiany architektury mikrokontrolera oraz że wykorzystywany w przeniesionym projekcie układ najprawdopodobniej jest tego samego producenta i należy do tej samej rodziny, co ten sprzed migracji.

Przy takich założeniach można uznać, że problem migracji ogranicza się do przeniesienia projektu, plików z kodem źródłowym i firmware’u oraz konfiguracji kompilacji i budowania.

Zautomatyzowane tworzenie projektu

Środowisko Atollic TrueSTUDIO udostępnia automatyczną, opartą o kreator typu wizard generację szkieletu projektu, co pozwala na szybkie utworzenie go oraz dokonanie koniecznej konfiguracji budowania.

W trakcie tworzenia projektu użytkownik może wybrać wykorzystywany układ (producenta i rodzinę), co pozwala na automatyczną generację kodu firmware’u zgodnego z bibliotekami dostarczanymi dla danego mikrokontrolera lub producenta.

Wykorzystanie kodu generowanego automatycznie przez Atollic TrueSTUDIO jest zalecane zarówno dla projektów budowanych przez środowisko, jak i opartych o zewnętrzne pliki Make, gdyż znacznie upraszcza to tworzenie nowych projektów i stanowi wygodny szkielet pozwalający porównywać nowe projekty z już istniejącymi.

CMSIS – Cortex Microcontroller Software Interface Standard

Firma ARM Ltd. w porozumieniu z producentami układów i narzędzi stworzyła standardową bibliotekę służącą do rozwoju firmware’u. Cortex Microcontroller Software Interface Standard (CMSIS) definiuje warstwę abstrakcji dla sprzętu, która jest dostępna jako biblioteka i została napisana by wspomagać kompilację w wielu kompilatorach, włączając GNU C/C++ oraz kompilator środowiska IAR EmbeddedWorkbench. Szczegóły można znaleźć na stronach ARM.

Firmware generowany przez środowisko Atollic TrueSTUDIO dla mikrokontrolerów z rdzeniem ARM serii Cortex zawiera całe niskopoziomowe sterowanie wykorzystujące bibliotekę CMSIS (wliczając kod startowy oraz obsługę przerwań i wyjątków) wraz ze sterownikami peryferiów dostarczanymi przez producenta.

Biblioteka do tworzenia firmware’u jest zestandaryzowana i została napisana tak, żeby współpracować zarówno z kompilatorem GNU, jak i z IAR EmbeddedWorkbench (przy użyciu kompilacji warunkowej), użytkownicy powinni się więc zorientować, że mają do dyspozycji podobne API, co ogranicza problem migracji do konfiguracji sterowania kompilacją i przeniesienia plików z kodem źródłowym aplikacji.

Migracja firmware’u

Jeśli pierwotna wersja projektu nie wykorzystywała bibliotek firmware’owych producenta, programista ma do wyboru dwie opcje:

1. Firmware można przenieść na kompilator GNU C/C++ (jeśli wersja przeniesiona nie jest już dostępna);
2. W przypadku rdzeni ARM Cortex, dotychczasowa biblioteka firmware’owa może zostać zastąpiona w wersji migrowanej przez standardową bibliotekę CMSIS, co daje wysokiej jakości warstwę abstrakcji sprzętu, która jest przy tym łatwo przenoszalna i ma dobre wsparcie techniczne.

Zgodność z ABI

Application Binary Interface (ABI) definiuje standardy tworzenia kodu dla danej rodziny mikrokontrolerów przez zestawy narzędziowe (m.in.: typy i rozmiary danych, konwencję wywoływania funkcji, użycie rejestrów). ABI jest zwykle dostarczany i utrzymywany przez producenta układu lub przez zewnętrzną firmę na jego zlecenie.

ARM Ltd. również dostarcza i utrzymuje serię dokumentów ABI, która obejmuje wszystkie aspekty tworzenia kodu dla rdzeni ARM na różnych platformach (wprost na mikrokontroler, pod kontrolą Linuksa lub dla systemów mobilnych). Zestaw dokumentacji ABI można pobrać ze strony firmy ARM.

W niniejszym tekście opisany jest problem migracji aplikacji napisanych wprost na mikrokontroler, działających bez systemu operacyjnego, co wymaga zrozumienia tylko części dokumentacji ABI.

Znajomość ABI nie jest wymagana, jeśli migracja ma być przeprowadzona tylko na poziomie kodu wysokiego poziomu (C/C++). ABI podaje niskopoziomowe informacje potrzebne do pisania funkcji asemblerowych, które są wywoływalne z poziomu C/C++ i potrzebne twórcom narzędzi kompilacyjnych, aby możliwa była współpraca miedzy różnymi zestawami narzędziowymi.

ABI jest zatem istotne na dwóch poziomach:

• Interfejs między asemblerem i C/C++ (wywoływanie procedur, powrót, definicja ram stosu),
• Format kodu plików obiektowych i operacje na nim.

Narzędzia IAR EmbeddedWorkbench oraz GNU obsługują standard wywoływania procedur dla rdzeni ARM (Procedure Call Standard for ARM, AAPCS), co oznacza iż użytkownicy mogą założyć, że funkcje napisane w asemblerze w projektach środowiska IAR można bez problemu przenosić do projektów GNU.

Aby obsłużyć mechanizm wywoływania procedur i powrotu z nich, nie są wymagane żadne zmiany na poziomie kodu źródłowego. Zmiany mogą być jednak konieczne, aby uzyskać zgodność ze składnią zdefiniowaną przez asembler GNU.