ŚRODOWISKO URUCHOMIENIOWE DLA PROCESORÓW ARM7

Jarosław Emilianowicz Marek Jarycki

Instytut Telekomunikacji, Teleinformatyki i Akustyki Politechnika Wrocławska

jaroslaw.emilianowicz@pwr.wroc.pl emdej@emdej.com

ŚRODOWISKO URUCHOMIENIOWE DLA PROCESORÓW ARM7

Streszczenie: W artykule zostały przedstawione wyniki

prac [2], których celem było opracowanie kompletnego dydaktycznego systemu uruchomieniowego dla proceso-rów ARM7, na potrzeby Laboratorium Techniki Mikro-procesorowej. W artykule omówiono jedynie część pro-gramową przedstawiając kolejno: oprogramowanie za-rządzające interfejsem JTAG, oprogramowanie umoŜli-wiające edycję kodu i jego kompilację, a takŜe przedsta-wiając oprogramowanie realizujące debugowanie.

1. WSTĘP

Z dydaktycznego punktu widzenia bardzo waŜnym aspektem jest umoŜliwienie szybkiego rozpoczęcia nauki programowania danego procesora. Aby osiągnąć ten cel, muszą być zapewnione odpowiednie warunki. Po pierw-sze musi być dostępna prosta i przejrzysta testowa plat-forma sprzętowa. Po drugie musi być dostępne proste środowisko programistyczne, na które, w minimalnej opcji, powinien składać się edytor, kompilator oraz apli-kacja ładująca napisany program do docelowego proce-sora. Po trzecie system powinien umoŜliwiać debugowa-nie, które pozwoli na śledzenie wykonywanego progra-mu w celu wychwycenia i naprawienia ewentualnych błędów w kodzie, oraz poznanie mechanizmów działania procesora.

Na potrzeby Laboratorium Techniki Mikroproceso-rowej opracowano kompletny dydaktyczny system uru-chomieniowy, pozwalający na naukę programowania procesorów ARM7. System uruchomieniowy oparto o procesor STR711FR2 produkcji ST Microelectronics.

2. JTAG

Obecnie prawie kaŜdy procesor ARM wyposaŜony jest w interfejs JTAG (formalnie IEEE 1149.1). Jest to interfejs stworzony do testowania połączeń na płytkach drukowanych, programowania układów programowal-nych oraz uruchamiania programów na systemach mi-kroprocesorowych. UmoŜliwia on odczyt i zapis pamięci wbudowanej w procesory ARM, w tym rejestrów proce-sora, umoŜliwia takŜe zatrzymywanie i wznawianie pracy procesora. Aby moŜliwe było wykorzystywanie interfejsu JTAG, procesor musi zawierać specjalizowany układ współpracujący z rdzeniem procesora, zwany kontrolerem TAP, który w przypadku procesorów ARM jest standardem. Szczegóły techniczne standardu JTAG są jednak zastrzeŜone, a dostęp do nich wymaga wnie-sienia opłaty.

Mając juŜ płytę uruchomieniową z wyprowadzo-nym złączem JTAG, naleŜy zastanowić się jak podłączyć

go do komputera-gospodarza, zwykle komputera PC. Aby połączyć się z procesorem poprzez interfejs JTAG, potrzebny jest układ tłumaczący sygnały JTAG na sy-gnały zrozumiałe dla komputera PC (rys 1). Układ taki nazywa się konwerterem protokołów lub emulatorem i występuje w bardzo wielu odmianach róŜniących się głównie szybkością i uŜywanym interfejsem po stronie komputera PC. Bardziej znanymi konwerterami są Wi-gler, Raven, Serial JTAG, MpDemon, LART i USB CrossConnect.

Rys 1. Połączenie komputera-gospodarza z ukła-dem docelowym poprzez interfejs JTAG Dla potrzeb systemu uruchomieniowego został wy-brany układ Wiggler. Przemawia za nim niski koszt wykonania oraz popularność, która z kolei przekłada się na ilość współpracującego z nim oprogramowania.

3. OPROGRAMOWANIE ZARZĄDZAJĄCE JTAG

Oprogramowanie zarządzające interfejsem JTAG powinno pozwalać na pełne korzystanie z udogodnień oferowanych przez sprzęt, a ponadto powinno posiadać typowe cechy dobrego oprogramowania. Do cech tych moŜna zaliczyć m.in. przenośność, dostępność (w tym cenę), stabilność, skalowalność i względnie niewielkie wymagania dotyczące zasobów. Do analizy wybrano kilka najpopularniejszych wśród amatorów programów zarządzających układami ARM7 podłączanymi do inter-fejsu JTAG poprzez konwerter Wiggler. Pominięto przy tym większość zamkniętych rozwiązań firmowych, głównie z uwagi na ich cenę, ale takŜe na to, iŜ niewiele jest tego typu rozwiązań. Rozwiązania firmowe mają równieŜ tę wadę, Ŝe zazwyczaj współpracują tylko z konwerterem protokołów danego producenta, co wyklu-cza uniwersalność takiego rozwiązania. Ponadto, produ-cenci specjalistycznego oprogramowania zazwyczaj tworzą programy typu „wszystko w jednym”.

3.1. JTAGER

Program jtager jest projektem, którego twórcą jest chiński programista Rongkai Zhan. Pozwala on na za-trzymywanie procesora, oraz odczytywanie jego

aktual-PC Konwerter

protokołów ARM

2006

Poznańskie Warsztaty Telekomunikacyjne Poznań 7 - 8 grudnia 2006

nego statusu oraz identyfikatora, a następnie wznawianie jego działania z dowolnym wskazaniem rejestru PC. Ponadto zawiera pełną paletę funkcji słuŜących do wy-konywania operacji na pamięci. Pozwala na jej zapis, odczyt, porównywanie i kopiowanie bloków pamięci o dowolnym rozmiarze. Ponadto oferuje on moŜliwość obliczenia sumy kontrolnej MD5 bloku pamięci. Jest to jednak funkcja niezwiązana bezpośrednio z samym inter-fejsem JTAG, którą w razie potrzeby moŜna z łatwością zrealizować poza programem obsługującym interfejs JTAG. Jtager pozwala równieŜ na odczyt i zapis reje-strów procesora, oraz, co jest unikalną cechą, pozwala na bezpośredni odczyt i zapis rejestrów układów logiki EmbeddedICE. W przypadku, gdy chcemy wykonywać wiele takich samych operacji, jtager oferuje moŜliwość pracy w trybie wsadowym.

Program ten działa pod kontrolą kaŜdego systemu zgodnego z POSIX, a więc m.in. z systemami Unix, BSD, Linux. MoŜliwe jest takŜe uruchomienie go na platformie MS Windows, ale wymagana jest wtedy in-stalacja zestawu bibliotek POSIX dla systemu Windows znanego jako Cygwin. Program ten jest dostępny na licencji GPL w wersji 2, co jest bardzo duŜą zaletą z punktu widzenia uŜytkownika amatora, ale w niektórych przypadkach moŜe być ograniczeniem. Licencja GPL (General Public License) gwarantuje uŜytkownikowi końcowemu pełną wolność. UŜytkownik ma zagwaran-towany dostęp do źródeł programu, co powoduje, Ŝe mamy kontrolę nad tym co dany program robi. Ponadto, licencja GPL gwarantuje, Ŝe uŜytkownik końcowy moŜe dowolnie zmieniać i wykorzystywać kod programu lub dowolną jego część. Jedynym ograniczeniem jest to, Ŝe oprogramowanie stworzone na bazie takiego programu musi równieŜ zostać wydane na licencji GPL. W przy-padku korporacji tworzących zaawansowane oprogra-mowanie obsługujące JTAG moŜe to być trudne do za-akceptowania, ale w kaŜdym innym przypadku jest to wielki atut. Dostępność źródeł wykorzystujących stan-dardowy zestaw funkcji systemu (POSIX) pozwala rów-nieŜ na bardzo łatwe tworzenie portów danego oprogra-mowania dla praktycznie dowolnego systemu.

Po wielu testach w programie tym znaleziono jeden błąd. Polega na tym, Ŝe procesor będący w stanie za-trzymania, przy odczycie zawartości rejestrów, wykonu-je 68 instrukcji, podczas gdy nie powinien ich wykony-wać. Prawdopodobnie problem ten wynika z błędnej implementacji funkcji sprawdzającej stan procesora. NaleŜy jednak zwrócić uwagę, Ŝe błąd ten nie jest kry-tyczny i mając jego świadomość moŜna wykorzystywać ten program do amatorskich zastosowań.

W przypadku zamiaru wykorzystania funkcji pro-gramu jtager w innym projekcie warto skorzystać z bar-dzo obszernej dokumentacji technicznej tego projektu. Dokumentacja ta dzieli się na część przeznaczoną dla uŜytkownika, która opisuje działanie samego programu, oraz część przeznaczoną dla programistów, która opisuje działanie poszczególnych funkcji na poziomie kodu. Warto takŜe zauwaŜyć, Ŝe mimo, iŜ jtager jest aplikacją autonomiczną, to bardzo łatwo moŜna go wykorzystać w innych programach, zarówno wykorzystując osobne funkcje z kodu programu, jak i wykorzystując to, Ŝe jest on aplikacją terminalową, a więc moŜna komunikować się z nią poprzez standardowe wejście i wyjście.

Największą wadą programu jtager jest słaby kon-takt z autorem oraz fakt, iŜ przestał on rozwijać swoją aplikację. Ostatnia wersja, oznaczona numerem 0.3, pochodzi z października 2004 i nie obsługuje trybu Thumb.

3.2. ARMTOOL

Armtool jest kolejnym narzędziem na licencji GPL, zatem posiada wszystkie związane z tym zalety, o któ-rych była mowa przy okazji programu jtager. Autorami tej aplikacji są Erwin Authried oraz Phil Wilshire. Pro-gram ten działa wyłącznie w trybie wsadowym, a jego funkcje ograniczają się do odczytu i zapisu bloków pa-mięci oraz uruchamiania programu spod zadanego adre-su. Niestety twórcy tego programu nie ustrzegli się błę-dów. Problem polega na tym, Ŝe niekiedy dane zapisy-wane do pamięci, zapisyzapisy-wane są błędnie. Ten problem moŜe wynikać ze sposobu implementacji kasowania pamięci przed zapisem, bowiem występowanie tego błędu jest zaleŜne od poprzedniej zawartości pamięci.

Program ten ma jeszcze jedną wadę, a mianowicie nie ma do niego dołączonej Ŝadnej dokumentacji. O ile uŜytkowanie programu nie sprawia Ŝadnych trudności, bowiem nie posiada on wielu funkcji, to edycja kodu moŜe juŜ sprawić pewne trudności. Na korzyść progra-mu armtool przemawia, iŜ jest on napisany w bardzo przejrzysty, modularny sposób. Kod jest opatrzony bar-dzo obszernymi komentarzami. Ponadto, dołączone są do niego biblioteki libjtag i libarm (równieŜ w postaci źródeł), w których zaimplementowanych jest znacznie więcej funkcji niŜ oferuje sama aplikacja uŜytkownika. W związku z powyŜszym, moŜna powiedzieć, Ŝe jest to bardzo dobra baza do tworzenia własnych aplikacji za-rządzających procesorami ARM7 podłączanymi do in-terfejsu JTAG. Natomiast sensowność uŜywania pro-gramu armtool jako samodzielnej aplikacji wydaje się wątpliwa.

3.3. OCDCOMMANDER

Aplikacja OCDCommander jest darmowym pro-gramem okienkowym udostępnianym przez firmę Ma-craigor [3]. Producent nie zapewnia Ŝadnego wsparcia do tego programu, bowiem traktuje go jako wersję demon-stracyjną swojego większego, płatnego programu. Apli-kacja OCDCommander ma jednak bardzo duŜe moŜli-wości, podobne do aplikacji jtager. Potrafi wykonywać operacje na pamięci, na rejestrach procesora, potrafi odczytywać i zmieniać stan procesora przy pomocy rejestrów EmbeddedICE. Program ten co prawda nie umoŜliwia bezpośredniego dostępu do rejestrów Embed-dedICE, ale udostępnia funkcje wykorzystujące te reje-stry: moŜna nakazać procesorowi wykonanie jednej lub większej, określonej, liczby instrukcji.

Produkt występuje w dwóch binarnych wersjach: dla systemów MS Windows i Linux. Wersja dla syste-mów Windows pracuje z wersjami 98, ME, NT, 2000, oraz XP. Wersja ta pozwala na zarządzanie wieloma rodzinami procesorów, w tym procesorów ARM. Wy-mienić tu naleŜy przede wszystkim wszystkie rodziny ARM7 oraz niektóre procesory z innych rodzin, np. ARM920T i ARM922T. Wersja ta pozwala ponadto na

wykorzystanie róŜnych konwerterów protokołów i do-stępne są tu Wiggler, Raven oraz kilka zamkniętych rozwiązań firmy Macraigor z rodziny mpDemon. Z uwagi na to, iŜ jest to zamknięta aplikacja okienkowa, moŜliwy zakres jej wykorzystania jest bardzo ograniczo-ny i sprowadza się do wykorzystywania tej aplikacji w takiej formie jaką przewidział i dostarczył producent.

Wersja dla systemu Linux została przygotowana w formie pakietu rpm dla dystrybucji Red Hat Linux w wersjach 7.2, 9.0 oraz Fedora Core 2 i 3, ale moŜliwe jest jej uruchomienie takŜe na innych dystrybucjach (testowano z systemami Gentoo Linux oraz Slackware Linux 10.1). Niestety wersja OCDCommander dla sys-temu Linux nie spełnia podstawowego warunku uŜy-teczności, a mianowicie nie współpracuje z konwerterem Wiggler. Jedyne konwertery obsługiwane w środowisku Linuksa to Raven oraz rozwiązanie mpDemon (dostęp tylko poprzez ethernet).

3.4. OCDREMOTE

Program OCDRemote podobnie jak OCDCom-mander jest zamkniętą aplikacją firmy Macraigor Sys-tems LLC, dostępną dla systemów MS Windows oraz Linux. RównieŜ w tym przypadku producent nie oferuje Ŝadnego wsparcia dla swojego produktu. Konwertery protokołów wspierane przez wersje programu OCDRe-mote odpowiadają konwerterom wspieranym przez od-powiednie wersje programu OCDCommander, zatem tu równieŜ mamy do dyspozycji tylko system MS Win-dows. Program OCDRemote pozwala jednak na duŜo więcej niŜ OCDCommander. Jego zadaniem jest nawią-zanie połączenia z docelowym układem oraz udostęp-nianie funkcji zarządzających tym układem dla innego programu. OCDRemote jest serwerem gdb, co oznacza, Ŝe, jak kaŜdy serwer, nasłuchuje on na określonym por-cie tcp (domyślnie jest to port 3333) i oczekuje połączeń od aplikacji chcących skomunikować się z docelowym procesorem. Serwer gdb udostępnia takie funkcje jak załadowanie i odczyt danych spod zadanego adresu, zatrzymanie i wznowienie pracy procesora od zadanego miejsca w programie, odczyt i zapis danych do reje-strów, wykonanie pojedynczego kroku, pośredni dostęp do rejestrów logiki EmbeddedICE, i inne. Są to funkcje, które pozwalają aplikacji klienckiej na realizację prak-tycznie dowolnego zadania z puli moŜliwych do wyko-nania na danym procesorze. NaleŜy zwrócić uwagę, iŜ OCDRemote nie pozwala na bezpośrednie zapisywanie do pamięci Flash — konieczne jest emulowanie zapisu poprzez uruchamianie na docelowym procesorze pro-gramu zapisującego.

3.5. OPENOCD

Program openOCD (Open On–Chip Debugger) jest rozwijany przez społeczność berlios [10]. Pierwsza jego wersja została napisana przez Dominica Ratha i zareje-strowana w serwisie berlios w lipcu 2005. Jest to pro-gram udostępniany na licencji GPL w wersji 2, o funk-cjonalności podobnej do OCDRemote, bowiem równieŜ jest to program typu serwer gdb. openOCD nie jest jed-nak pozbawiony wsparcia jak jego zamknięty odpowied-nik – autor programu w miarę moŜliwości odpowiada na

kaŜde pytanie. Ponadto wiele informacji moŜna znaleźć na stronach projektu. Program openOCD oprócz funk-cjonalności serwera gdb, oferuje takŜe moŜliwość połą-czenia z nim poprzez protokół telnet. Interfejs telnet pozwala na niskopoziomowe debugowanie oraz zarzą-dzanie aplikacją openOCD, np. moŜna zaŜądać, aby uŜywane były tylko breakpointy programowe, albo tylko sprzętowe. Zalecane jest, aby przed wykonaniem połą-czenia przez klienta gdb włączyć obsługę breakpointów programowych (domyślnie są wyłączone), bowiem mo-Ŝemy szybko wykorzystać pulę dostępnych breakpoin-tów sprzętowych, a w konsekwencji gdb moŜe nie dzia-łać prawidłowo. Aby włączyć obsługę breakpointów programowych naleŜy zalogować się do openOCD po-przez interfejs telnet i wydać odpowiednie polecenie.

Unikalną cechą najnowszych wersji programu ope-nOCD jest moŜliwość zapisywania pamięci Flash proce-sorów STR7, co czyni go najlepszą aplikacją na rynku oprogramowania zarządzającego procesorami ARM poprzez interfejs JTAG.

4. KOMPILATOR

W poprzednich rozdziałach przedstawiono opro-gramowanie zarządzające interfejsem JTAG, warto teraz zastanowić się, jak wygenerować program dla procesora ARM. Istnieje kilka kompilatorów stworzonych przez firmy produkujące środowiska programistyczne dla procesorów ARM (np. środowisko CrossWorks posiada własny kompilator), ale większość programistów korzy-sta z kompilatora GCC (GNU Compiler Collection). Głównymi przyczynami takiego stanu rzeczy są: moŜli-wość bezpłatnego otrzymania kompilatora GCC oraz jego bardzo duŜa funkcjonalność.

GNU Compiler Collection to zbiór oprogramowa-nia tworzonego na licencji GPL przez programistów z całego świata w ramach projektu GNU. W skład GNU Compiler Collection wchodzą kompilatory wielu języ-ków programowania w tym m.in. C, C++, Objective-C, Fortrana i Javy oraz biblioteki programistyczne dla tych języków. GCC przy pierwszym uŜyciu moŜe wydać się nieco ascetyczny i trudny we wdroŜeniu, bowiem udo-stępniane źródła nie są ani trochę skonfigurowane do pracy z jakąkolwiek platformą. NaleŜy zauwaŜyć jednak, Ŝe cecha ta jest w istocie zaletą, bowiem oznacza, Ŝe kompilując GCC moŜemy go dostosować do własnych potrzeb. GCC oferuje moŜliwość krzyŜowej kompilacji (cross compilation), co oznacza, Ŝe podczas kompilacji moŜna skonfigurować go tak, aby działał na jednej plat-formie sprzętowej, a efekty jego działania (kompilaty) były przeznaczone dla zupełnie innej platformy. Praw-dopodobnie, w naszym przypadku będziemy potrzebo-wać GCC działającego na platformie x86 lub ew. AMD64, a kompilującego programy dla platformy ARM [1, 6].

Standardowo GCC dostępny jest w postaci źródeł przygotowanych dla systemu Linux, ale moŜliwe jest skompilowanie go takŜe na innych systemach, w tym na MS Windows. Najłatwiejszą metodą aby stać się posia-daczem GCC dla Windows jest ściągnięcie stosownych paczek binarnych wykorzystujących MinGW lub Cy-gwin. JeŜeli zdecydujemy się na tę metodę, naleŜy zwró-cić baczną uwagę na to, aby wszystkie ściągane paczki

były skompilowane przy uŜyciu tej samej wersji kompi-latora i tych samych bibliotek. W przeciwnym razie kompilator moŜe nie działać. Inną metodą, która oferuje większe moŜliwości konfiguracyjne oraz nie naraŜa nas na ryzyko niezgodności bibliotek, jest skompilowanie źródeł GCC w środowisku Cygwin. Cygwin jest imple-mentacją środowiska linuksowego na platformę Win-dows. NajwaŜniejszym składnikiem Cygwin jest biblio-teka cygwin1.dll, która dostarcza warstwę emulacji API linuksa w środowisku Windows. Po uruchomieniu śro-dowiska Cygwin moŜemy dokonać kompilacji GCC w sposób identyczny jak w systemie Linux [4].

Oprócz samego kompilatora, potrzebujemy takŜe bibliotek języka C oraz kilku dodatkowych narzędzi, takich jak linker, czy konwerter formatów plików wyni-kowych (zazwyczaj gdy ładujemy program do mikro-kontrolera uŜywamy plików binarnych, czyli odzwier-ciedlających rzeczywisty zapis kodu w pamięci proceso-ra, ale uŜywa się równieŜ plików w intelowskim forma-cie hex, w formaforma-cie s19 motoroli, czy formaforma-cie elf po-zwalającym na ponowne linkowanie). Wspomniane biblioteki noszą nazwę newlib, a pakiet pozostałych narzędzi binutils. Dla skompilowania GCC wraz z new-lib oraz binutils konieczne jest, aby w systemie obecne były standardowe narzędzia programistyczne GNU. Dostępne są one w kaŜdej dystrybucji systemu Linux, jak równieŜ w środowisku Cygwin.

5. DEBUGGER 5.1. GDB

W rozdziale 3 opisano dwa rozwiązania serwerów gdb, czyli programów łączących się z docelowym śro-dowiskiem sprzętowym i oferujących standardowy inter-fejs komunikacyjny gdb wskazując, Ŝe rozwiązanie ope-nOCD jest najlepszym programem słuŜącym do łączenia się z układami ARM. NaleŜy zatem przyjrzeć się opro-gramowaniu zdolnemu do łączenia się z takim serwerem gdb.

Podstawowym oprogramowaniem klienckim wyko-rzystującym oprogramowanie typu openOCD jest oczy-wiście GNU Debugger (GDB). GDB, prócz obsługi programów uruchamianych na zdalnych procesorach, potrafi takŜe debugować programy uruchomione na tej samej maszynie (praca natywna), jednak tą sytuacją nie będziemy się tutaj zajmować. GDB jest programem o tekstowym interfejsie uŜytkownika, w którym moŜna wpisywać polecenia, które następnie są przetwarzane i przesyłane do docelowego układu, a wyniki są odsyłane tą samą drogą i wyświetlane na ekranie.

Podstawowa obsługa GNU Debuggera jest zasadni-czo bardzo prosta, ale nie zmienia to faktu, Ŝe dostęp-nych jest wiele dziesiątek komend, co moŜe odstraszać początkującego uŜytkownika. Dokładne informacje na ich temat moŜna znaleźć na stronach projektu GDB [7].

GDB, podobnie jak GCC, jest bardzo uniwersal-nym projektem. UmoŜliwia on debugowanie aplikacji napisanych m.in. w językach C, C++, Objective-C i Pascal. Podobnie jak GCC, moŜna go skompilować na praktycznie kaŜdej platformie sprzętowej oraz na kaŜdej platformie programowej wspierającej POSIX. Podobnie jak w przypadku GCC istnieje równieŜ wersja GDB dla

systemów MS Windows. Funkcjonalności oferowane przez GCC moŜna podzielić na cztery grupy:

• startowanie programu w zadanym środowisku, • zatrzymywanie wykonywania programu pod

okre-ślonymi warunkami,

• testowanie środowiska pracy programu po jego zatrzymaniu (np. odczyt rejestrów procesora), • modyfikacja środowiska pracy oraz samego

pro-gramu.

Wśród funkcji GDB występują odczyt i zapis do-wolnego obszaru pamięci, na którym dozwolone są te operacje (pamięć odczytywalna i zapisywalna), ustawia-nie breakpointów i watchpointów, zarówno sprzętowych jak i programowych, deasemblowanie kodu, praca kro-kowa i inne.

Bardzo ciekawą cechą GDB jest umiejętność od-czytu informacji dla debugera, dołączanych przez kom-pilator do programu (tylko w formatach ponownie lin-kowalnych, jak elf ). Jest to bardzo przydatne, bowiem pozwala na względnie łatwe określenie, które instrukcje kodu maszynowego (asemblerowego) odpowiadają danej instrukcji języka wysokiego poziomu (np. C). Niestety dla początkującego uŜytkownika korzystanie z tych moŜliwości jest bardzo utrudnione w trybie tekstowym. Z tego powodu powstały liczne nakładki graficzne na program GDB. Nie naleŜy ich mylić z osobnymi debuge-rami – korzystają one z GDB, a stanowią jedynie inter-fejs graficzny. W dalszej części niniejszego rozdziału zostaną przedstawione tego typu nakładki.

Dla GDB w wersji 5.0 powstał zestaw łat o nazwie Armulator pozwalający na uruchomienie go w trybie symulatora procesora ARM. Tak skompilowany GDB, podłączony do środowiska programistycznego moŜe symulować pracę na rzeczywistym procesorze ARM. Niestety projekt nie jest dalej rozwijany, a wersja 5.0 GNU Debuggera jest juŜ mocno przestarzała. Z projektu Armulator wywodzi się natomiast projekt skyeye. Jest to wolny symulator róŜnych procesorów, w tym rodziny ARM7. Program ten uruchamia się jako serwer gdb, do którego podłącza się właściwy debugger.

5.2. INSIGHT

Insight jest graficznym interfejsem do GDB napi-sanym w tcl/tk przez programistów Red Hat. Program ten jest rozwijany od 1994 roku, kiedy to nosił nazwę gdbtk. Do dziś niektóre pliki konfiguracyjne mają nazwy powiązane z tamtą nazwą. Po ściągnięciu pakietu Insight otrzymujemy graficzną nakładkę na GDB wraz z samym GDB, zatem nie potrzebujemy instalować go osobno. Kompilacja Insight przebiega tak samo jak GDB i GCC [8].

Po uruchomieniu programu Insight naleŜy skonfi-gurować połączenie z serwerem GDB, w tym celu w oknie dialogowym wybieramy target: Remote/TCP oraz podajemy adres komputera z serwerem GDB. Następnie wystarczy wybrać plik z programem w formacie elf i załadować go. Interfejs programu pozwala na jednocze-sny podgląd kodu programu w języku wysokiego po-ziomu, kodu asemblerowego, wartości zmiennych lokal-nych, a takŜe zawartości rejestrów, stosu i pamięci. Jest to prawdopodobnie najlepsza nakładka do zdalnego debugowania procesorów ARM.

5.3. KDBG

Autorem programu KDbg jest Johannes Sixt. Napi-sany on jest dla środowiska graficznego KDE przy uŜy-ciu bibliotek qt. Program ten oferuje podobną funkcjo-nalność do Insight, jednak nie zawiera w sobie gdb, więc naleŜy go osobno skompilować.

W opcjach programu naleŜy wskazać lokalizację GNU Debuggera, z którego będziemy korzystać. Inter-fejs KDbg jest bardzo prosty i przyjazny, co na pewno jest pozytywną stroną tego programu. Jego największą wadą jest dość duŜa niestabilność w przypadku debugo-wania programów na zdalnych procesorach ARM, bo-wiem program ten nie został stworzony do debugowania tej rodziny procesorów. NaleŜy jednak wyraźnie zazna-czyć, Ŝe po prawidłowym skonfigurowaniu, program ten jest dobrą alternatywą dla Insight [9].

5.4. DDD

Data Display Debugger (DDD), podobnie jak GCC i GDB, jest tworzony w ramach projektu GNU przez programistów z całego świata, w tym programistów Free Software Foundation. Jest to program o największych moŜliwościach z opisywanych w tym rozdziale. Prócz funkcjonalności opisywanych przy okazji omawiania Insight, oferuje takŜe moŜliwość graficznego przedsta-wienia danych zawartych w pamięci. Program ten potrafi interpretować struktury danych i wyświetlać je w formie wykresów 2D i 3D. DDD posiada takŜe wsparcie dla procesorów ARM. Pozwala on na graficzne skonfiguro-wanie GDB do pracy z określoną wersją architektury ARM, czy ustawienie opcji endianess. Ponadto warto wspomnieć, Ŝe DDD potrafi współpracować nie tylko z debugerami GDB, ale takŜe innymi jak DBX, WDB, XDB, JDB czy debugerem Perla [5]. Jego największą wadą jest dość nieprzyjazny interfejs. Program ten nie jest polecany dla początkujących programistów ARM, którym zaleŜy bardziej na tym, aby szybko i sprawnie uruchomić swój pierwszy program, niŜ na tym, aby dłu-go uczyć się bardzo funkcjonalnedłu-go środowiska.

6. PODSUMOWANIE

W tabeli 1 przedstawiono zestawienie najwaŜniej-szych cech omówionych programów do zarządzania procesorami ARM poprzez interfejs JTAG. Aplikacją, która posiada najwięcej poŜądanych cech jest openOCD i jest to w istocie najlepsza aplikacja tego typu. Opinię tę potwierdza fakt, iŜ wiele firm produkujących oprogra-mowanie dla procesorów ARM wykorzystuje właśnie tę aplikację.

Warto równieŜ wyróŜnić aplikację jtager, która mimo, Ŝe nie jest juŜ rozwijana, jest bardzo dobrą bazą do nauki debugowania procesorów ARM. MoŜna przy jej pomocy „ręcznie” zapisywać rejestry logiki Embed-dedICE, oraz, co niemniej waŜne, moŜna wykorzystać uŜyte do tego procedury we własnych projektach.

Zasadniczo istnieją trzy rozwiązania środowiska uruchomieniowego dla procesorów ARM7. Pierwsze jest odpowiednie dla osób, które są w posiadaniu kompute-rów o duŜej ilości pamięci i względnie duŜych mocach obliczeniowych. W takim przypadku zalecane jest

uŜy-cie rozwiązania opartego o platformę Eclipse, w połą-czeniu z oprogramowaniem openOCD.

Drugie rozwiązanie przeznaczone jest dla osób chcących szybko rozpocząć pracę z projektem dla proce-sorów ARM i oparte jest o środowisko CrossWorks. NaleŜy tu jednak zaznaczyć, Ŝe uŜywanie tego oprogra-mowania wiąŜe się z restrykcjami narzuconymi przez Rowley Associates.

Tabela 1. Oprogramowanie zarządzające JTAG

Cecha jt a g er a rm to o l O C D C O C D R o p en O C D dla Windows • • • • • dla Linux • • cz. cz. • obsługa ARM7 • • • • • obsługa ARM9 • • • • licencja GPL • • • FLASH • EmbeddedICE • pułapki • • • • tryb wsadowy • • • serwer gdb • •

Ostatnie rozwiązanie przeznaczone jest dla osób, którym nie zaleŜy bardzo na czasie oraz nie posiadają mocnych komputerów, a chcą mieć bardzo funkcjonalne środowisko dostosowane do ich potrzeb. Rozwiązanie to polega na własnoręcznym skompletowaniu aplikacji składających się na całokształt środowiska. Wszystkie te rozwiązania dostępne są zarówno na platformę MS Win-dows jak i Linux (praktycznie dowolny system wspiera-jący POSIX). NaleŜy jednak zauwaŜyć, Ŝe zdecydowana większość oprogramowania opisanego w niniejszej pra-cy została stworzona dla systemu Linux. Wynika to z faktu, Ŝe Linux jest naturalną platformą programistyczną dla procesorów ARM. Jest to zgodne z ogólnym trendem polegającym na odchodzeniu od zamkniętych i monopo-listycznych rozwiązań, który daje się od paru lat zauwa-Ŝyć w krajach Unii Europejskiej.

SPIS LITERATURY

[1] W. Gatliff, A Tutorial Introduction Using the ARM Evaluator-7T.

[2] M. Jarycki, Optymalizacja środowiska uruchomie-niowego dla procesorów ARM, Praca Dyplomowa, Wrocław 2006.

[3] Strona firmowa Macraigor Systems LLC, http://www.macraigor.com

[4] Strona projektu Cygwin, http://www.cygwin.com [5] Strona projektu DDD,

http://www.gnu.org/software/ddd/ [6] Strona projektu GCC, http://gcc.gnu.org [7] Strona projektu GDB,

http://www.gnu.org/software/gdb/ [8] Strona projektu Insight,

http://sources.redhat.com/insight/

[9] Strona projektu KDbg, http://www.kdbg.org [10]Strona społeczności Berlios, http://www.berlios.de