Niniejszy tekst ma za zadanie pomóc w przenoszeniu projektów ze środowiska IAR EmbeddedWorkbench do Atollic TrueSTUDIO. Dokument ten jest adresowany do projektantów systemów wbudowanych i menadżerów projektu, chcących zrozumieć proces migrowania projektów ze środowiska IAR EmbeddedWorkbench do środowiska Atollic TrueSTUDIO dla mikrokontrolerów z rdzeniem ARM.

Decyzja o migracji

Dokument ten został stworzony, aby pomóc zespołom projektowym w zrozumieniu jakie są przyczyny, mechanizmy i następstwa migracji z jednego zestawu narzędzi kompilacyjnych (toolchain) na inny dla wybranego mikrokontrolera lub rodziny mikrokontrolerów. Problem został w niniejszym tekście przedstawiony na przykładzie migracji z zestawu narzędzi firmy IAR Systems do środowiska Atollic TrueSTUDIO dla mikrokontrolerów z rdzeniem ARM. Ogólne zasady pozostaną jednak niezmienione dla innych rodzin układów oraz środowisk innych producentów.

Szczegółową dokumentację użycia narzędzi kompilacyjnych wykorzystanych w Atollic TrueSTUDIO i rozszerzeń, które obsługują, można znaleźć w dostarczanej ze środowiskiem dokumentacji kompilatora GNU C/C++. Ponadto, bezpośrednio na stronach firmy ARM Ltd. można znaleźć dokument opisujący Application Binary Interface (ABI) – niskopoziomowy interfejs między aplikacją czy biblioteką a systemem operacyjnym lub inną aplikacją; analogiczny do API, ale dotyczący programów w wersji skompilowanej. Informacje zawarte w niniejszym opracowaniu warto też weryfikować z tymi podanymi przez producenta używanego dotychczas kompilatora (w tym przykładzie: IAR Systems).

W niniejszym rozdziale omówione są kwestie „wysokopoziomowe”, na które należy zwrócić uwagę przed rozpoczęciem procesu migracji projektu, zorganizowane w postaci odpowiedzi na cztery pytania:

• Dlaczego migrować?
• Kiedy migrować?
• Co migrować i jakie są następstwa migracji?
• Jak uprościć proces migracji?

Dlaczego migrować?

Migracja do nowego zestawu narzędzi musi być powodowana konkretną potrzebą. Motywami mogą być: poprawa wydajności kodu, uzyskanie zgodności ze standardami, lepsza płynność prac (workflow) dzięki wykorzystaniu szerszego zestawu funkcji i bardziej zintegrowanego środowiska programistycznego i/lub dostęp do lepszej pomocy technicznej producenta narzędzi projektowych.

Decyzja może być powodowana względami inżynieryjnymi lub biznesowymi, ale idealne rozwiązanie powinno przynieść korzyści na obu tych polach. Dla przykładu, zalety środowiska Atollic TrueSTUDIO w stosunku do rozwiązań konkurencyjnych można streścić następująco:

• Koszta: Atollic TrueSTUDIO jest częściowo oparte na komponentach dostępnych jako wolne oprogramowanie (open source), które zostały rozszerzone tak, by dorównywać możliwościom wielu innych rozwiązań komercyjnych lub je prześcigać. Wykorzystanie komponentów open source pozwoliło na znaczne obniżenie ceny produktu w porównaniu do wielu innych dostawców.
• Wydajność: Kompilator GNU C/C++ to światowej klasy toolchain, rozwijany i utrzymywany przez tysiące programistów i wiele firm na całym Świecie.
• Standardy: Kompilator GNU C/C++ pozwala na tworzenie oprogramowania w C i C++ obsługując pełną składnię obu języków wraz z bibliotekami uruchomieniowymi (runtime library).
• Workflow: Atollic TrueSTUDIO to wysoce zintegrowane środowisko programistyczne, które pozwala na bezpośrednie stosowanie zaawansowanych narzędzi zarządzania postępem prac, takich jak systemy: kontroli wersji, śledzenia błędów (bug tracking), oceny i analizy kodu oraz rozproszonego projektowania opartego na zadaniach. Udostępnia także możliwość konfigurowalnego sterowania projektem i jego uruchamianiem oraz w pełni zintegrowany debuger.
• Model wsparcia technicznego: Atollic TrueSTUDIO jest dostępne w wielu wersjach, pozwalając klientowi wybrać potrzebne mu funkcje i model płatności najlepiej dopasowany do potrzeb. Jako że stanowiący serce systemu kompilator jest oparty na GNU C/C++, nie ma możliwości, żeby toolchain uległ dezaktualizacji czy stał się niedostępny. To samo dotyczy całego środowiska Atollic TrueSTUDIO, które oparte jest na frameworku Eclipse.

Kiedy migrować?

Gdy decyzja o migracji do nowego toolchainu zostanie podjęta, proces ten trzeba zaplanować zgodnie z potrzebami firmy/zespołu projektowego. Są trzy typowe scenariusze migracji:

• Na początku pracy nad projektem;
• Równolegle z postępującymi pracami nad projektem;
• W projekcie, który upada – aby przywrócić go do życia.

Prawdopodobnie najłatwiejsze jest przeprowadzenie migracji w początkach procesu projektowania, gdy obmyślić można plan przydziału zasobów i czasu jeszcze przed przystąpieniem do prac.

Jeśli założymy jednak, że wysiłek włożony w migrację da się należycie ocenić, a korzyści, które z niej płyną są wymierne, nie ma powodu, by nie przeprowadzić jej, gdy prace nad projektem są już w toku. W takim wypadku można albo przydzielić pewne zasoby na potrzeby migracji, pozostawiając część zespołu przy pracach w innych obszarach, albo chwilowo skoncentrować siły wszystkich członków grupy projektowej na migracji, aby umożliwić szybkie przeniesienie.

Jeśli firma używa systemu kontroli wersji, sensowne jest wydzielić osobną „gałąź” z istniejącego projektu, aby wszystkie zmiany związane z migracją zawierały się w jednym strumieniu, co pozwala na późniejsze włączenie do przeniesionego już projektu wszelkich zmian w oryginalnym kodzie. Jako że środowisko Atollic TrueSTUDIO współpracuje z systemami kontroli wersji, wykorzystanie takiej strategii nie jest trudne.

Co migrować i jakie są następstwa migracji?

Środowisko Atollic TrueSTUDIO poza standardowymi modułami, takimi jak: toolchain, debuger i edytor kodu, jest wyposażone w bogaty zestaw funkcji. Migrację można podzielić na fazy, wykorzystując konkretne funkcje środowiska. Kluczowe zagadnienia procesu migracji zostały wymienione poniżej. W dalszej części tekstu niektóre ze wspomnianych tutaj zagadnień, zostaną omówione szerzej.

Kontrola nad projektem i procesem kompilacji

Środowisko Atollic TrueSTUDIO daje możliwość automatycznego generowania projektów dedykowanych dla mikrokontrolerów, które obsługuje. Takie automatycznie wygenerowane projekty stanowią szkielet dalszych prac, zapewniając opisy plików z kodem źródłowym i bibliotek wchodzących w skład projektu oraz dają możliwość wygenerowania skryptów automatyzujących proces budowania go.

Infrastruktura i przebieg prac

Środowisko Atollic TrueSTUDIO zapewnia pełną infrastrukturę do prac nad projektem i kompilacją dla narzędzi GNU, włączając w to interfejs graficzny do konfiguracji opcji specyficznych dla mikrokontrolera docelowego.

Środowisko daje możliwość automatycznej generacji oraz ręcznej edycji skryptów kompilacyjnych i plików z komendami dla linkera, a proces budowania można kontrolować w pełni przez GUI. IDE udostępnia też mechanizmy pozwalające na używanie posiadanych już plików Make i jest wyposażone w edytor takich plików. Analogicznie, jeśli jako system kontroli wersji lub śledzenia błędów były wcześniej używane zewnętrzne aplikacje, nie ma konieczności korzystania z nich poprzez środowisko. Wykorzystanie narzędzi zintegrowanych z IDE można wprowadzać do projektu etapami, w razie potrzeby.