Podstawy technologii tworzenia oprogramowania BSP dla systemów wbudowanych (na przykładzie systemu operacyjnego QNX oraz narzędzi Lauterbach)

Transkrypt

1 Podstawy technologii tworzenia oprogramowania BSP dla systemów wbudowanych (na przykładzie systemu operacyjnego QNX oraz narzędzi Lauterbach) I. QNX Momentics praca z pakietami BSP. Poniższy artykuł ma na celu przybliżenie czytelnikowi tematyki tworzenia wbudowanych obrazów systemowych w oparciu o narzędzia zestawu programistycznego QNX Momentics. Główny nacisk położony został przede wszystkim na wykorzystanie pakietów BSP, stanowiących niezbędne, fundamentalne wsparcie przy opracowywaniu własnego projektu dla specyficznej platformy docelowej. Era Momentics a. Wprowadzenie do sprzedaży w czerwcu 2002 roku pierwszej komercyjnej wersji pakietu QNX Momentics okazało się trafionym posunięciem. Oprogramowanie odniosło duży sukces i obecnie ma spore szanse zostania jednym z najlepszych narzędzi programistycznych w kategorii systemów czasu rzeczywistego. Dynamiczny rozwój poparty szeregiem łatek, aktualizacji, nowych wersji oprogramowania oraz dodatkowych pakietów kreuje obraz godnego zaufania produktu, i to pomimo tak młodego wieku (na rynku nieco ponad rok). Obecnie swój rozkwit przeżywają kompletne, zintegrowane środowiska programistyczne (QNX Momentics, Tornado II,...). Trwa nieustający wyścig w ulepszaniu oraz rozbudowywaniu narzędzi, a producenci dokładają wszelkich starań, aby ich programy narzędziowe były jak najbardziej uniwersalne oraz łatwe w użyciu i nauce. I tak dla przykładu suita programistyczna QNX Momentics zawiera: system operacyjny QNX Neutrino (obecnie w wersji 6.2.1), środowisko graficzne Photon wraz z programem do tworzenia aplikacji okienkowych (phab), zintegrowane środowisko programistyczne IDE, narzędzia do pisania własnych sterowników DDK, pakiety BSP, biblioteki i narzędzia GNU, instruktażowe klipy wideo, obszerną dokumentację (przeszło 11 tys. stron) oraz szereg kodów źródłowych. Naszą uwagę, w dalszej części artykułu skupimy na dedykowanych zestawach BSP. Co to jest BSP? Pakiet BSP (Board Support Package) jest zestawem kodów źródłowych, plików binarnych, konfiguracyjnych oraz kreatorów mających za zadanie zainicjowanie oraz uruchomienie systemu operacyjnego wraz z kompletną obsługą większości bądź wszystkich urządzeń dedykowanej platformy sprzętowej. Począwszy od QNX Momentics (17 pakietów dla 25 popularnych platform), liczba zestawów stale rośnie i aktualna ich lista znajduje się pod następującym linkiem: Zanim przejdziemy do omawiania przykładowego pakietu BSP musimy zatrzymać się na chwilę przy analizie sekwencji bootowania systemu operacyjnego. Bootowanie systemu operacyjnego QNX Neutrino. Co dzieje się podczas bootowania? Jakie komponenty są wymagane dla poprawnego załadowania systemu? W odpowiedzi na te pytania pomoże nam schemat inicjacji systemu operacyjnego QNX Neutrino przedstawiony na rys.1. Rys.1 Sekwencja inicjowania systemu QNX Neutrino Po włączeniu zasilania, resecie sprzętowym bądź programowym procesor zaczyna wykonywać instrukcje kodu spod specyficznego dla danej architektury adresu (reset vector). Kodem tym może być BIOS, ROM monitor, ewentualnie inicjujący program ładujący IPL (Initial Program Loader). Pierwszy scenariusz, typowy dla komputerów klasy PC jest najłatwiejszy w realizacji, ponieważ wszystkie czynności konfiguracyjne wykonywane są z poziomu BIOS-u. BIOS zwykle przeprowadza wstępną diagnostykę oraz ustawia poszczególne urządzenia sprzętowe. W następnym etapie znajduje on swoje rozszerzenia (kontroler dysku twardego, boot ROM karty sieciowej itp.) oraz skacze do nich w celu wykonywania dalszego kodu. Po wykonaniu skoku następuje załadowanie obrazu systemowego do pamięci (np. z dysku twardego) i przekazanie kontroli programowi startup. QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 1

2 ROM monitor (nazywany również firmware) jest specjalnym oprogramowaniem sprzętowym, zapisywanym do pamięci FLASH w procesie produkcji urządzenia. Przeważnie oprogramowanie to obsługuje: transfer danych przez port szeregowy (protokół Xmodem/Ymodem), sieć ethernet (klient TFTP), proste operacje na pamięci (wyświetlanie, usuwanie i zapis) oraz kilka wariantów debugowania niskiego-poziomu. ROM monitor wgrywany jest z reguły za pomocą programatora pamięci bądź też interfejsu JTAG. Zarówno w pierwszym jak i drugim przypadku większość czynności konfiguracyjnych zostaje wykonana przez BIOS bądź ROM monitor. Taki rodzaj inicjacji nazywamy gorącym startem. Start systemu z wykorzystaniem inicjującego programu ładującego IPL Podczas zimnego startu systemu nic nie jest zainicjowane oraz ustawione. Procesor i cała reszta sprzętu jest po prostu ponownie przywracana do swoich ustawień domyślnych. W jaki zatem sposób dokonywana jest inicjacja systemu? Procedura konfiguracji oraz ładowania systemu została podzielona na dwa etapy: IPL, startup. Pierwszym krokiem wykonywanym przez oprogramowanie jest wgranie obrazu systemu przez program ładujący IPL. Ponadto zadaniem IPL-a jest dokonanie minimalnej konfiguracji sprzętowej, która umożliwi w konsekwencji przejście do drugiego etapu - uruchomienia programu startup. Kod programu IPL został rozbity na dwa programy, które to w procesie kompilacji łączone są w jeden plik wynikowy. Pierwszy z nich (napisany całkowicie w Asemblerze) jest odpowiedzialny za utworzenie środowiska dla programu startup, a mianowicie konfiguracji: zegarów, GPIO, kontrolera pamięci i/lub kontrolera PCI. Ostatecznie program ładujący skanuje pamięć FLASH w poszukiwaniu obrazu, weryfikuje go oraz wgrywa do pamięci RAM. W przypadku nie znalezienia obrazu systemowego IPL umożliwia jego wgranie poprzez port szeregowy (protokół sendnto). Po przekazaniu kontroli do programu startup, wykonywane są dalsze czynności konfiguracyjne sprzętu: jednostki MMU, czasomierza systemowego, kontrolera przerwań oraz strony systemowej (czas, data, ilość pamięci, typ procesora, koprocesora i szyny sprzętowej). Gdy już wszystkie urządzenia są poprawnie ustawione startup przekazuje kontrolę następnemu programowi obrazu systemowego procnto, czyli po prostu uruchamia system operacyjny. Mikrojądro systemu QNX Neutrino wraz z Zarządcą Procesów uruchamiają pozostałe pliki wykonawcze (aplikacje, sterowniki, protokoły itp.) wyszczególnione w skrypcie startowym. Uproszczony proces ładowania systemu został zamieszczony na rys.2 Rys.2 Start systemu z wykorzystaniem programu ładującego IPL Praca z pakietem BSP. Przykładowy pakiet BSP dla platformy Intel a PXA250TMDP zawiera: - kod źródłowy: IPL, startup, sterownika kontrolera dźwięku, systemu plików flash oraz wszystkich dodatkowych bibliotek, - sterowniki do pozostałych urządzeń (w postaci binarnej): portu szeregowego, karty sieciowej, graficznej oraz ekranu dotykowego, - szereg kreatorów (pliki makefile) oraz dodatkowe pliki konfiguracyjne np. plik na podstawie którego generowany jest obraz systemowy (Buildfile) W jaki sposób należy rozpocząć pracę z pakietem BSP? Schemat ideowy pracy z zintegrowanym zestawem programistycznym QNX Momentics przedstawia rys.3. QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 2

3 Rys.3 Praca z zestawem QNX Momentics Interfejs JTAG może być wyprowadzony poprzez port równoległy LPT bądź też za pomocą specjalnego złącza na platformie docelowej. W pierwszym przypadku za pomocą typowego kabla one-to-one oraz prostego programu możemy zapisywać własne oprogramowanie w pamięci flash, np. program ładujący. Bardziej popularny jest drugi wariant, który to wymaga pracy z dedykowanymi debbugerami sprzętowymi i dodatkowym oprogramowaniem. Więcej informacji na ten temat zostało przedstawionych w dalszej części artykułu. Przykładowo dla środowiska programistycznego QNX Neutrino zestawy BSP zainstalowane są w następującym katalogu: /usr/src/bsp oraz podzielone są na dwa obszary: specyficznej platformy /usr/src/bsp-6.2.1/procesor/platforma i bibliotek (n.p. biblioteka IPL, biblioteka startup) /usr/src/bsp-6.2.1/libs. Ponadto dla każdej platformy wyróżniamy: /usr/src/bsp-6.2.1/procesor/platforma/src -> katalog z kodami źródłowymi: IPL, startup, systemu plików flash, serwera pci itp., /usr/src/bsp-6.2.1/procesor/platforma/scratch -> katalog ten zawiera pliki wynikowe utworzone poleceniem make install wywołanym w katalogu src, /usr/src/bsp-6.2.1/procesor/platforma/images oraz dodatkowe skrypty, -> katalog zawierający Makefile, pliki buildfiles, pliki opisowe /usr/src/bsp-6.2.1/procesor/platforma/prebuilt -> katalog ten używany jest podczas pierwszego wywołania komendy make na poziomie katalogu procesor/platforma. Tak więc pliki źródłowe pakietu PXA250TMDP BSP umieszczone są w następujących katalogach: /usr/src/bsp-6.2.1/arm/pxa250tmdp/src/hardware/ /flash /ipl /startup Praca z pakietem BSP w zintegrowanym środowisku programistycznym IDE. Korzystając z kreatora należy utworzyć nowy projekt (Standard Make C Projekt) oraz zaimportować do niego całą zawartość katalogu /usr/src/bsp-6.2.1/procesor/platforma/ (w przypadku pracy ze źródłami danej platformy) bądź też /usr/src/bsp-6.2.1/libs (praca z bibliotekami). Po zaimportowaniu w łatwy sposób możesz zarządzać całym projektem, modyfikując oraz kompilując odpowiednie pliki źródłowe drzewa pakietu BSP. Wynikowe pliki binarne (IPL, obraz systemowy) mogą być przesyłane do urządzenia za pomocą portu szeregowego (protokół sendnto). Ponadto IDE posiada wbudowany serwer TFTP umożliwiający transfer danych poprzez sieć Ethernet. Tworzenie własnych, bootowalnych obrazów systemowych dla pamięci flash w dużym stopniu wspomaga narzędzie System Builder. Wystarczy kliknąć na żądanym komponencie, a System Builder sprawdzi zależności oraz automatycznie dołączy wszystkie wymagane elementy składowe (biblioteki, itp.) do obrazu. Istnieje również możliwość redukcji rozmiaru obrazu całego systemu jak i danej biblioteki do pliku zawierającego minimalny zbiór funkcji używanych w naszym systemie docelowym. Plany na przyszłość. Z początkiem lipca ukazał się nowy, poszerzający możliwości systemu pakiet QNX Momentics PE Patch B. Nowością jest zestaw narzędzi wspomagających zarządzanie energią (Power Management). QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 3

4 Zcentralizowana polityka zasilania umożliwia projektantom pełną kontrolę stanu zasilania całego systemu, jaki i poszczególnych jego komponentów składowych. Zestaw specjalnych funkcji pozwala przechwytywać interakcje pomiędzy jednostką zarządzającą a wszystkimi urządzeniami systemu. Producent systemu QNX Software Systems Ltd. zapowiada agresywną politykę rozwoju pakietów BSP. W III kwartale 2003 ukazały się zestawy wspierające nowe procesory Intel-a (IXCDP 1100, IXDP 425 oraz IXDP 2400), Broadcom a (BCM 91125E, BCM 91250E i BCM 5690) Motoroli itp. stworzone z myślą o segmencie sieciowym. Rynek motoryzacyjny również rozwija się w podobnym tempie i wkrótce możemy się spodziewać między innymi następujących zestawów BSP: Hitachi Big Sur/Amanta, Hitachi SH 7760, Hitachi SystemH, Motorola Redbox Power PC 823e, Motorola MGT W pierwszym kwartale 2004 roku zapowiadana jest kolejna wersja systemu QNX Momentics z nowymi kompilatorami GCC 3.3.1, obsługą USB 2.0, zewnętrznych urządzeń dyskowych podpinanych przez interfejs USB, środowisko programistyczne (Red Hat Linux 8.x/9.x) oraz nowe pakiety BSP. Jak widać QNX Momentics w wersji zapowiada się naprawdę interesująco. Zawartość CD QNX Momentics NC (Non-Commercial). Na bootowalnym cd-rom ie znajduje się najnowsza, przeznaczona do zastosowań nie komercyjnych wersja zestawu programistycznego QNX Momentics NC. W skład pakietu wchodzą: system operacyjny QNX Neutrino 6.2.1, środowisko graficzne Photon wraz z programem Photon Application Builder, narzędzia do tworzenia własnych sterowników DDK s (z kodami źródłowymi po jednym na daną klasę), biblioteki ANSI C oraz narzędzia wiersza poleceń GNU dla platformy docelowej x86 oraz ARM (kompilator GCC v2.95x, GDB 5.x, Binutils 2.10.x). Dla wszystkich zainteresowanych tworzeniem własnych aplikacji dla platformy docelowej ARM interesujące uzupełnienie stanowi pakiet BSP przeznaczony do instalacji na komputerach podręcznych ipaq (ipaq Reference Platform) z procesorem StrongARM SA Sposób instalacji systemu oraz konfiguracji skrosowanej platformy programistycznej został opisany szerzej na stronie: II. Narzędzia firm trzecich jako wsparcie w procesie programowania dedykowanej platformy debuggery sprzętowe firmy LAUTERBACH. Komputer biurowy kontra wbudowany Tematyka wbudowanych systemów rozwija się w zaskakującym tempie, a ostatnie dwa lata przyniosły jej prawdziwy rozkwit. Coraz częściej producenci sprzętu sięgają po inną architekturę procesora (Power PC, Arm, XScale,..) niż klasyczne x86. Wbudowane komputery dzięki małym gabarytom, krótkiemu czasu podnoszenia systemu, szybkości działania (brak BIOS-u) oraz możliwości pracy w poszerzonym zakresie temperatur z dużym powodzeniem stosowane są w wielu nieraz specjalistycznych urządzeniach. Dynamiczny rozwój widoczny jest przede wszystkim w segmencie wojskowym (systemy łączności oraz obrony przeciwlotniczej), medycznym (specjalistyczna aparatura medyczna) oraz motoryzacyjnym (systemy wewnątrz samochodowe). Co to jest wbudowany komputer i czym różni się on od typowego rozwiązania biurowego? Zestawienie podstawowych cech obu komputerów zostało zamieszczone w tab.1. Tab.1 Komputer biurowy kontra wbudowany QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 4

5 Biorąc pod uwagę podzespoły jakie zainstalowane są w danym urządzeniu, możemy powiedzieć, że oba komputery na wstępie nie różnią się zbyt wiele. Przykładowo wbudowany komputer z procesorem Intel PXA 255 XScale 400 MHz, 64M pamięci RAM, 32 MB pamięci flash, kartą sieciową 10/100 Mbps, dwoma portami szeregowymi, portem USB, kontrolerem audio AC-97 w pełni może zastąpić typowego PC o podobnej konfiguracji sprzętowej. Jednak główna różnica przypada na oprogramowanie (z reguły zaszyte w pamięci stałej), które to jest odpowiedzialne za konfigurację podzespołów oraz inicjację i poprawny start systemu operacyjnego. Ponieważ wbudowane urządzenia nie posiadają BIOS-u, całą konfigurację musimy przeprowadzić samemu. Inicjacja urządzeń może zostać przeprowadzona na dwa sposoby: poprzez specjalne oprogramowanie sprzętowe (ROM Monitor) bądź własny program konfiguracyjny - dedykowany program ładujący (Initial Program Loader). ROM Monitor - oprogramowanie zaszyte w sprzęcie Wielu wykonawców aplikacji dla wbudowanych systemów korzysta ze specjalnego, rezydującego w pamięci ROM bądź flash oprogramowania. Niektórzy producenci dostarczają własne urządzenia z wgranym firmowym oprogramowaniem sprzętowym. Przykładem może być platforma programistyczna RPX-Lite firmy Embedded Planet. RPX-Lite posiada wgrany w pamięci flash specjalny program RPX-Lite Flash Menu, za pomocą którego użytkownicy mogą między innymi przeglądać, usuwać i zapisywać poszczególne rekordy pamięci flash oraz przesyłać pliki przez port szeregowy lub sieć do pamięci RAM. Obecnie dostępnych na zasadzie wolnego źródła jest kilka programów uruchomieniowych, takich jak: uboot, Blob oraz RedBoot. Ten ostatni ze względu na specyficzną budowę, mnogość opcji, łatwość konfiguracji oraz szybki rozwój warty jest poświęcenia mu nieco więcej miejsca. RedBoot, nazywany również Red Hat s Embedded Debug and Bootstrap Program jest samodzielnym, przeznaczonym do używania w wbudowanych aplikacjach programem ładowania początkowego. Odpowiedzialny jest on za inicjalizację procesora, pamięci RAM/flash oraz konfigurację urządzeń w celu zapewnienia komunikacji z systemem na tym właśnie poziomie. Pomimo iż, RedBoot używa modułów oprogramowania systemu operacyjnego czasu rzeczywistego ecos oraz często wykorzystuje się go do uruchamiania osadzonego systemu Linux, jest całkowicie niezależny od obu systemów. RedBoot może być użyty z dowolnym systemem operacyjnym, systemem czasu rzeczywistego, jak również może pracować całkowicie samodzielnie. RedBoot wspiera szeroką gamę procesorów włączając: ARM, Hitachi SHx, MIPS, PowerPC, SPARC, x86 oraz wiele innych. Ponieważ oparty jest na modułach systemu ecos, może zostać on zainstalowany na każdej platformie, która jest wspierana przez ten system. Pełna lista obsługiwanego sprzętu znajduje się na stronie: RedBoot zawiera namiastkę narzędzi GDB, których zadaniem jest dostarczenie mechanizmów komunikacji programowej po stronie platformy, umożliwiającej zdalne uruchamianie programu za pomocą standardowych komend protokołu GDB. Takie rozwiązanie pozwala używać RedBoot-a oraz hosta z uruchomionym debuggerem GNU do uruchamiania oraz wykrywania błędów w aplikacjach wbudowanych przez port szeregowy bądź sieć Ethernet. Niektórzy twierdzą, że dzięki możliwości: odczytu/zapisu rejestrów procesora, zrzucania zawartości pamięci oraz ładowania i uruchamiania aplikacji jest on w podobnym stopniu użyteczny jak specjalistyczne debuggery sprzętowe. Czy oby tak naprawdę mają oni rację? W pewnym sensie i tak i nie. Co zrobić, gdy np. nietypowa organizacja pamięci naszej platformy bądź specjalne wymagania pozwalają jedynie na umieszczenie w pamięci stałej dedykowanego programu ładującego zamiast ROM Monitor-a? A jak poradzić sobie w sytuacji, gdy sami musimy napisać własne oprogramowanie uruchomieniowe od podstaw? Techniki debugowania BDM, JTAG, Większość produkowanych obecnie procesorów dostarcza zaimplementowanego, całkowicie zintegrowanego z układem CPU systemu debugowania (on-chip debug). Typowymi przykładami są: interfejs BDM Motoroli, interfejs JTAG dla platformy ARM7 oraz interfejs JTAG dla rodziny PowerPC. Interfejs debugowania przeważnie wymaga kilku pinów procesora, które to używane są do komunikacji pomiędzy systemem debugowania on-chip a narzędziami programistycznymi firm trzecich. System on-chip debug dostarcza następujących podstawowych właściwości: - odczyt/zapis pamięci, - odczyt/zapis rejestrów CPU, - praca krokowa lub w czasie rzeczywistym, - sprzętowe punkty przerwań oraz wyzwalania (nie są wspierane przez wszystkie typy procesorów), - programowe punkty uruchamiania i zatrzymywania programów. Debuggery sprzętowo-programowe ICD Debugger, jest oprogramowaniem przeważnie zainstalowanym na stacji roboczej, którego to zadaniem jest dostarczenie (z reguły opartego o graficzny interfejs użytkownika) środowiska dla znajdywania błędów w twoim kodzie. Co to jest debbuger sprzętowy oraz jakie posiada możliwości? Debugger sprzętowy w połączeniu z odpowiednim oprogramowaniem oraz dzięki swojej specyficznej budowie znacznie poszerza możliwości klasycznego programu do wykrywania błędów kodu źródłowego. Cechą charakterystyczną jest to, iż debugger sprzętowy dostępny jest wraz z pakietem oprogramowania, tworząc kompletne środowisko uruchomieniowe (In-Circuit Debugger). Przykład sprzętowo-programowego środowiska uruchomieniowego bazującego na rozwiązaniu firmy Lauterbach został pokazany na rys.4. QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 5

6 Rys.4 Sprzętowo-programowe środowisko uruchomieniowe TRACE32-ICD In-Circuit Debugger TRACE32 dzięki obsłudze podstawowych właściwości systemu on-chip debug dostarcza silnego narzędzia debagowania, które umożliwia: - łatwe debagowanie asemblera oraz języka wysokiego poziomu, - wyświetlanie wewnętrznych oraz zewnętrznych urządzeń na poziomie logicznym, - obsługę wszystkich punktów przerwań i opcji wyzwalania, - pracę z szeroką gamą systemów RTOS, - programowanie pamięci flash, - debugowanie systemów wieloprocesorowych. TRACE32-ICD jest wysokowydajnym sprzętowo-programowym środowiskiem uruchomieniowym dla języków C, C++ oraz Java. Obsługuje on wszystkie aktualne standardy oraz techniki debugowania on-chip debug takie jak: JTAG, BDM, ETM, OCDS, itp. Ponadto TRACE32-ICD wspiera ponad piętnaście popularnych architektur mikroprocesorów., których to aktualny spis zamieszczony jest na stronie domowej firmy Lauterbach pod linkiem Warstwa programowa TRACE32 PowerView jest interfejsem użytkownika wykorzystywanym przez wszystkie narzędzia programowania wytwarzane w siedzibie firmy Lauterbach. Oferuje on intuicyjny oraz szybki dostęp do programu uruchomieniowego i jego wyników działania. PowerView obsługuje skomplikowane projekty dla wbudowanych platform pracujących często pod kontrolą systemu czasu rzeczywistego. Bez najmniejszego problemu TRACE32 radzi sobie z nietypowymi rozwiązaniami sprzętowymi, np. ze skomplikowanym zarządzaniem pamięcią, bądź z systemami wieloprocesorowymi. TRACE32 wspiera szeroką gamę kompilatorów a zaimplementowany debugger języka wysokiego poziomu obsługuje wszystkie popularne języki programowania. Ponadto dzięki wydajnemu językowi wsadowemu wszelkie sekwencje testowe mogą w łatwy sposób zostać zautomatyzowane w postaci makr uruchomieniowych. Z poziomu PowerView możemy przeglądać zawartość wszystkich rejestrów procesora włącznie z specjalnymi rejestrami statusowymi oraz wyświetlać aktualny stan wewnętrznych i zewnętrznych urządzeń na poziomie logicznym. Warstwa sprzętowa Podstawowa konfiguracja środowiska TRACE32-ICD składa się z urządzenia uruchomieniowego nazywanego inaczej modułem interfejsu głównego (moduł debuggera JTAG/BDM) oraz specjalistycznego kabla uruchomieniowego (kabel debuggera) przeznaczonego do pracy z daną platformą docelową. Tak uniwersalna koncepcja pozwala na szybką migrację z jednej platformy na drugą poprzez zamianę kabla debuggera oraz uruchomienie oprogramowania dedykowanego dla konkretnej architektury. Przykładowo kabel uruchomieniowy JTAG- XSCALE wspiera następujące typy procesorów: 80219, 80321, 80331, IOP321, IOP331, IXC1100, IXP2400, IXP2800, IXP2850, IXP420, IXP421, IXP422, IXP425, PXA210, PXA250, PXA255, PXA260, PXA261, PXA262, PXA263, PXA800F. Jeżeli w czasie programowania zamierzasz również rozpocząć pracę nad innym projektem, np. dla wbudowanej platformy rodziny SHx, po prostu zamień kabel debuggera na JTAG-SH4, a cały dalszy proces programistyczny oraz interfejs użytkownika pozostaje nie zmieniony. Moduł debuggera jest wspomagany przez wysokowydajny 32-bitowy mikrokontroler umożliwiający bardzo szybką komunikację z docelowym procesorem. Jak bardzo wydajny jest ten moduł, świadczą uzyskiwane przez niego wyniki. I tak makro zawierające cztery operacje: otwarcie pamięci flash, kasowanie pamięci flash, wgranie 32MB obrazu do pamięci RAM oraz zapisanie tego obrazu do pamięci flash wykonuje się w około 9 minut. Ponadto moduł może być połączony z komputerem roboczym za pomocą wielu popularnych interfejsów: LPT, USB lub Ethernet. Połączenie zapewnia krótki czas reakcji nawet przy skomplikowanych operacjach, a wykorzystując interfejs Ethernet można osiągnąć szybkość transmisji rzędu 1MB/s. QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 6

7 Podsumowanie Rozpoczynając nowy projekt dla wbudowanej platformy sprzętowej musimy przede wszystkim zwrócić uwagę na to: - czy nasza płyta posiada wyprowadzony fizycznie (jakie sygnały/ilość pinów, typ łączówki) system debugowania CPU (on-chip debug), onieważ niektóre rozwiązania wymagają programowania nie tylko samego procesora jak również dodatkowych rejestrów, - jakiego typu pamięć zainstalowana jest na płycie: ROM/flash bądź pamięć tylko do odczytu, - jaka jest mapa pamięci (pod jakim adresem umieszczony jest adres zerowy reset vector ), - jaka jest docelowa architektura procesora, - jaka jest organizacja podzespołów na płycie (obecność dodatkowych kości, tzw. companion chipets). Na koniec chciałbym raz jeszcze powrócić do schematu pracy ze środowiskiem programistycznym QNX Momentics przedstawionym na rys.3 i uzupełnić go patrząc pod kątem wykorzystywania narzędzi firm trzecich o specjalistyczne debuggery sprzętowe. Ponieważ inicjujący program ładujący IPL oraz kod startup (patrz rys.1) wykonują się przed systemem operacyjnym, dlatego też w pełni profesjonalny proces debugowania ich może zostać przeprowadzony jedynie z użyciem dodatkowych narzędzi. Proces programistyczny może zostać podzielony na dwa etapy: a) tworzenia oraz testowania programu uruchomieniowego (konfiguracja sprzętu oraz wszystkich urządzeń dedykowanej platformy). Do tego celu możemy wykorzystać specjalistyczne programowo-sprzętowe środowisko uruchomieniowe, np. TRACE32-ICD, b) tworzenie wbudowanego specyficznego obrazu systemowego, tworzenie obrazu wbudowanego systemu plików, przenoszenie/pisanie sterowników, edycja kodów źródłowych, tworzenie aplikacji, analiza wydajności kodu oraz całego systemu może być przeprowadzona z użyciem narzędzi programistycznych pakietu QNX Momentics. Uproszczony schemat tworzenia projektu embedded został przedstawiony na poniższym rysunku. Rys.5 Współpraca debuggerów sprzętowych z środowiskiem programistycznym QNX Momentics Jacek Rudnicki, KTT Quantum jacek.rudnicki@quantum.com.pl Aby uzyskać więcej informacji proszę skontaktować się z działem technicznym firmy QUANTUM Sp. z o.o., ul. Skwierzyńska 21, Wrocław, info@quantum.com.pl QUANTUM Korporacja Transferu Technologii Sp. z o.o., ul. Skwierzyńska 21, Wrocław Str. 7