Mikrokontroler.pl – portal dla elektroników » Jak przenieść projekt ze środowiska IAR Embedded Workbench do Atollic TrueSTUDIO

11.06.2012

Jak przenieść projekt ze środowiska IAR Embedded Workbench do Atollic TrueSTUDIO – poradnik migracyjny

2. Kliknąć przycisk Advanced i zaznaczyć pole Link to folder in the file system.

Rys. 22. Tworzenie łącza do zewnętrznego katalogu

Rys. 22. Tworzenie łącza do zewnętrznego katalogu

3. Kliknąć przycisk Browse i wskazać katalog, który chcemy włączyć do projektu. Łącze do katalogu zostanie utworzone w drzewie katalogów projektu i pliki znajdujące się w wybranym katalogu zostaną skompilowane jako część projektu, mimo tego że nie znajdują się fizycznie w katalogu projektu.

Migracja plików z kodem źródłowym

Aby stworzone wcześniej pliki z kodem źródłowym mogły zostać skompilowane z użyciem zestawu narzędzi GNU, być może konieczne będzie wprowadzenie w nich zmian. Konieczność ta może być spowodowana wieloma czynnikami, które zostały opisane w niniejszym rozdziale podzielonym na podrozdziały:

Zmiany na poziomie kodu C/C++,
Zmiany kodu asemblerowego,
Kod startowy.

Zmiany na poziomie kodu C/C++

W zależności od dotychczasowego sposobu pisania kodu, zmiany w plikach z kodem mogą, ale nie muszą być konieczne.

UWAGA

Przed rozważeniem problemów wynikających z wykorzystywania rozszerzeń kompilatora warto przypomnieć, że miedzy kompilatorami występują różnice także jeśli chodzi o stopień zgodności ze standardami języków C i C++.

Narzędzia GNU można uznać za wysoce zgodne ze standardami, więc szanse na to, że przenoszony kod wykorzystuje jakieś cechy języka, które nie są przez nie obsługiwane, są małe. Wszystkie aspekty zgodności są opisane w szczegółach w dokumentacji kompilatora GNU, dostarczanej ze środowiskiem Atollic TrueSTUDIO; warto do niej sięgać w razie wątpliwości.

Dużo bardziej prawdopodobne jest wystąpienie różnic między kompilatorami, jeśli chodzi o komunikaty ostrzeżeń i błędów. Może się okazać, że kod, który kompilował się przy użyciu narzędzi IAR bez błędów oraz bez lub z niewielką liczbą ostrzeżeń nagle spowoduje wysyp ostrzeżeń lub nawet błędy przy kompilacji za pomocą narzędzi GNU.

Wiele pracy zostało włożone w ostatnich latach w kompilator GNU, aby poprawić kontrolę błędów i ostrzeżeń, co oznacza, że może ona być bardzie surowa niż w przypadku kompilatora środowiska IAR.

WSKAZÓWKA

Zalecane jest aby wszystkie błędy były traktowane poważnie i pociągały za sobą dokładną analizę kodu, pozwalającą na zrozumienie, dlaczego kompilator wygenerował błąd. Możliwe jest albo że błędny kod przed migracją „po prostu działał”, ale też może być tak, że nigdy wcześniej nie został uruchomiony, co spowodowało przeoczenie błędu.

Traktowanie ostrzeżeń jest kwestią gustu. Niektóre firmy wymagają, żeby aplikacje kompilowały się bez nich, ale może się okazać, że z powodu skomplikowania projektu nie jest to możliwe. W takim przypadku warto przyjrzeć się wszystkim ostrzeżeniom i te dotyczące spraw, które nie mają być poprawiane wyłączyć za pomocą opcji linii poleceń.

Na przykład, kod może wykorzystywać przestarzałą funkcję biblioteczną. Jeśli jest to działanie celowe, nie ma sensu zaśmiecanie logów powiadomieniami o nim. Rozsądne wykorzystanie opcji linii poleceń do redukcji ostrzeżeń polega na tym, że wszelkie wygenerowane ostrzeżenia można łatwo namierzyć, ocenić i prawidłowo sobie z nimi poradzić.

Preprocesor

Preprocesor pracuje przed kompilatorem i jego zadaniem jest tekstowe wstawienie do kodu plików nagłówkowych i definicji oraz rozwinięcie makr. Wszystkie zestawy narzędzi kompilacyjnych dla języków C/C++ obsługują standardowe dyrektywy preprocesora, ale każdy kompilator implementuje też specyficzne dla siebie definicje, pozwalające na pisanie kodu przeznaczonego do kompilacji warunkowej, w zależności od używanego kompilatora. Pozwala to na współdzielenie kodu i jest używane typowo przy tworzeniu bibliotek, systemów operacyjnych i oprogramowania wieloplatformowego. Jest więc istotne, aby zrozumieć specyficzne dla danego kompilatora dyrektywy preprocesora i oznaczenia, aby móc bezproblemowo przenieść kod źródłowy.

Niektóre rozszerzenia kompilatorów też są implementowane za pomocą dyrektyw preprocesora, nazywanych pragma. Takie rozwiązania są omówione w następnym rozdziale, opisującym rozszerzenia języków C i C++.

Każdy kompilator ma własny zestaw oznaczeń (symboli), których można używać do tworzenia kodu przeznaczonego do kompilacji tylko przez konkretny toolchain, a nawet konkretną jego wersję. Aby poznać te symbole można sięgnąć do dokumentacji kompilatora GNU C/C++ lub uruchomić preprocesor CPP celem wyświetlenia oznaczeń dla danej architektury za pomocą polecenia:

gcc –E –dM test.c

Predefiniowane oznaczenia specyficzne dla kompilatora środowiska IAR EmbeddedWorkbench, wraz z ich odpowiednikami w kompilatorze GNU (GCC) zostały zestawione w tabeli 1 (gwiazdką „*” wyróżnione zostały oznaczenia, które mają kilka wariantów).

Autor: Mikrokontroler.pl

Polski portal branżowy dedykowany zagadnieniom elektroniki. Przeznaczony jest dla inżynierów i konstruktorów, projektantów hardware i programistów oraz dla studentów uczelni technicznych i miłośników elektroniki. Zaglądają tu właściciele startupów, dyrektorzy działów R&D, zarządzający średniego szczebla i prezesi dużych przedsiębiorstw. Oprócz artykułów technicznych, czytelnik znajdzie tu porady i pełne kursy przedmiotowe, informacje o trendach w elektronice, a także oferty pracy. Przeczyta wywiady, przejrzy aktualności z branży w kraju i na świecie oraz zadeklaruje swój udział w wydarzeniach, szkoleniach i konferencjach. Mikrokontroler.pl pełni również rolę patrona medialnego imprez targowych, konkursów, hackathonów i seminariów. Zapraszamy do współpracy!