ARM powiększa arsenał

Rys. 1. Technologia debugowania i śledzenia CoreSight implementowana w strukturach ARM Cortex

Projektowanie współczesnych urządzeń elektronicznych jest walką z problemami technicznymi, aby urządzenie zaczęło działać oraz walką z czasem, aby jak najszybciej wdrożyć je do produkcji. Pierwszy dostawca na rynku stosunkowo łatwo zajmuje wolne pole, które odbić później konkurentowi jest dużo trudniej, a niedopracowane w pośpiechu urządzenie zawsze można usprawniać w kolejnych aktualizacjach.

Powtarzany powszechnie slogan "time to market" stał się niestety podstawowym kryterium naszych poczynań, działającym jednak na szkodę niezawodności samych urządzeń. Chcąc oferować dobry i sprawdzony produkt, musimy więc wyposażyć się w odpowiednie środki pozwalające szybciej i efektywniej pracować.

Praw rynku nie zmienimy, a musimy w nim egzystować i walczyć o to, by być pierwszym z możliwie najlepszym produktem. W przypadku techniki mikroprocesorowej prawidłowe działanie urządzenia jest zdeterminowane jego programem. Dlatego w walce z czasem oraz w walce o jak najwyższą jakość produktu podstawowego znaczenia nabierają dobre i niezawodne narzędzia projektowe pozwalające przygotować program i wszechstronnie go przetestować.

Co mamy do dyspozycji? Współczesne mikrokontrolery obok rdzenia mają wbudowane w strukturę półprzewodnikową mechanizmy wspomagające debugowanie i śledzenie wykonywanych przez jednostkę centralną rozkazów. W przypadku procesorów Cortex realizują je następujące bloki funkcjonalne określane zbiorczą nazwą technologii CoreSight.

Bloki debuggera:

• RCU (Run Control Unit) - odpowiedzialny za uruchomianie, zatrzymywanie i krokowe wykonywanie programu,
• BPU (Break Point Unit) - umożliwiający zastawienie 8 sprzętowych pułapek na cyklu pobrania instrukcji,
• MAU (Memory Access Unit) - monitorujący dostęp do pamięci. Bloki śledzenia:
• DWT (Data Watchpoint & Trace Unit) - umożliwiający śledzenie zmiennych i zastawianie pułapek na dostępie do nich,
• ITM (Instrumentation Trace Macrocell) - umożliwiający śledzenie zmiennych programu na zasadzie odbierania po interfejsie ,szeregowym SWV (Serial Wire Viewer) ich wartości wysyłanych wstawianymi w kod rozkazami "printf",
• ETM (Embedded Trace Macrocell) - wysyłający ślad wykonywanych instrukcji po 4-liniowym porcie TP (Trace Port) uzupełniającym standardowe porty SWD (Serial Wire Debug) i SWV na złączu Cortex Debug,
• DIU (Debug Interface Unit) - wysyłający do komputera nadrzędnego dane z bloków debuggera w standardzie JTAG lub SWD
• TPIU (Trace Port Interface Unit) - wysyłający do komputera nadrzędnego dane z bloków śledzenia w standardzie SWV i ETP (ETM Trace Port).

Rys. 2. Wizualizacja stanu procesów systemu RTX w środowisku μVision

Wykorzystując funkcjonalność Core-Sight i zapewniając odpowiednio szybkie odbieranie danych zbieranych "w locie", możemy mieć, za relatywnie małe pieniądze, narzędzie co najmniej klasy dawnych sprzętowych emulatorów układowych, umożliwiające w ogólnym zarysie uruchamianie kodu w docelowym środowisku poprzez zatrzymywanie programu w dowolnym wybranym miejscu lub czasie oraz rejestrowanie stanu zmiennych i śladu wykonywanego programu. Reszta to kwestia liczby zaimplementowanych bloków CoreSight oraz interpretacji i wizualizacji zebranych danych.

Spójrzmy na podstawowe elementy współczesnego systemu uruchomieniowego:

• kompilator C/C++ - decydujący o jakości kodu, jego wielkości i efektywności przetwarzania,
• debugger - obsługujący maksymalną liczbę wbudowanych w strukturę układu mechanizmów śledzenia wykonania programu,
• sprzętowy adapter debuggera - zapewniający maksymalnie szybki "download" programu i odbiór danych zbieranych w trakcie wykonywania programu w rzeczywistym układzie docelowym i w rzeczywistym czasie,
• środowisko IDE - decydujące o sposobie wizualizacji danych i wygodzie obsługi.

Oczywiście z użyciem tych narzędzi można przygotować kod i zatrzymać program w dowolnej chwili lub we wskazanym tzw. pułapką miejscu, a następnie obejrzeć stan rejestrów, pamięci czy wartości zmiennych programu. Niemniej w aplikacjach czasu rzeczywistego w wypadku błędów dynamicznych trudnych do wykrycia konieczna jest rejestracja w długim oknie czasowym śladu wykonania instrukcji programu (Instruction Trace) w celu jego analizy.

Często też ze względów bezpieczeństwa lub formalnych wymagań certyfikacyjnych potrzebna jest pewność, że wszystkie ścieżki i rozgałęzienia programu zostały prześledzone. Ze względów optymalizacji szybkości działania i czasu reakcji na krytyczne zdarzenia zewnętrzne potrzebna jest wiedza, gdzie w programie traci się najwięcej czasu, aby mieć obraz rozkładu czasów wykonania poszczególnych procedur. Wszystko to jest w najnowszych narzędziach projektowych.

Nowe środki w starym MDK-ARM

Rys. 3. Oznaczanie wykonanych instrukcji: instrukcje wykonane, rozkazy bez kodu, instrukcje niewykonane, skoki warunkowe niewykonane, skoki warunkowe wykonane

Najpopularniejszy na rynku pakiet Microcontrollers Development Kit MDK-ARM firmy KEIL obsługujący rdzenie ARM7, ARM9, Cortex-M, Cortex-R nie będzie w artykule szczegółowo omawiany, gdyż jest powszechnie znany. We wszystkich dostępnych wersjach obejmuje on system operacyjny czasu rzeczywistego RTX z następującymi funkcjami: zarządzanie zadaniami i zasobami systemu, alokację pamięci i stosu, komunikację i synchronizację między procesami.

Przedstawiona specyfikacja techniczna daje obraz możliwości funkcjonalnych sytemu RTX i wskazuje na wyjątkowo mały zakres absorbowanych zasobów pamięci. RTX jest przy tym w pełni zintegrowany z debuggerem środowiska μVision, co pozwala monitorować stan poszczególnych zadań: m.in. aktywne procesy, zajętość stosu i innych zasobów systemu oraz tworzyć statystyki.

Podobnie μVision obsługuje system MQX - RTOS firmy Freescale. Kolejną zmianą w pakiecie KEIL-a jest włączenie dotychczas oddzielnie oferowanych bibliotek RL-ARM do pakietu MDK-ARM w wersji Professional. Nowością jest długo oczekiwana biblioteka graficzna GUI, ułatwiająca implementację interfejsu graficznego użytkownika w systemach zintegrowanych.

Obsługuje wyświetlacze monochromatyczne, ze skalą poziomów szarości i kolorowe. Zawiera drivery wielu standardowych wyświetlaczy i ich kontrolerów. Menedżer okien umożliwia zarządzanie wieloma oknami. Wiele elementów grafiki jest predefiniowanych, tak jak np.: przyciski, ikony, checkboxy.

Rys. 4. Wizualizacja analizatora pokrycia w środowisku μVision

Z biblioteką jest dostarczana aplikacja GUI Builder, pozwalająca graficznie zaprojektować wygląd i rozkład okien na wyświetlaczu, a następnie automatycznie wygenerować kod C. Biblioteka jest zoptymalizowana pod kątem zajętości pamięci. Podobnie jak reszta bibliotek stanowi wyważony kompromis możliwości funkcjonalnych, zajętości zasobów systemu i szybkości działania.

Jest wystarczająca dla większości powszechnie spotykanych zastosowań. Pozostałe biblioteki są stale modyfikowane i rozwijane. Między innymi, obecnie oferowane są stosy USB w wersji Host i Device wspomagające klasy MSC (Mass Storage Class) i HID (Human Interface Device). Pozostałe to stos TCP/IP, Flash File System (FAT12/16/32) i drivery CAN.

To już nie te czasy, aby tracić czas na robienie wszystkiego własnymi siłami. Nawet jeśli samodzielnie można coś zrobić lepiej, rzadko kiedy da się zrobić szybciej. A czas to pieniądz. Nowe oprogramowanie wymaga też nowego sprzętu, czego przykładem jest Ulink-Pro.

Ulink-Pro - otwarcie na nowe analizy

Rys. 5. Wizualizacja analizatora przetwarzania w środowisku μVision

Ulink-Pro jest kolejnym wcieleniem powszechnie znanego adaptera firmy KEIL. Tak jak poprzednie, pozwala sprząc układ docelowy z komputerem nadrzędnym za pośrednictwem interfejsu JTAG i dodatkowo z użyciem interfejsu Cortex Debug obsługującego też sygnały bloku ETM.

Ulink-Pro pozwala w pełni kontrolować i śledzić wykonanie programu, a ponadto zrealizować pamięć śladu w oparciu o blok ETM. Jest też w stosunku do ULINK i ULINK-2 urządzeniem znacznie szybszym, co widać po jego parametrach:

• obsługuje ARM7, ARM9, Cortex-M do 200 MHz,
• interfejs USB 2.0, zasilanie przez USB,
• implementuje interfejsy i protokoły JTAG (50 MHz), SWD (Serial-Wire Debug) i SWV (Serial-Wire Viewer) + ETM,
• transmisja z bloku ETM do 800 Mb/s,
• szybkość ładowania kodu do układu docelowego do 1 MB/s,
• złącza układu docelowego: 20-pin (0,1") JTAG, 10-pin (0,05") Cortex Debug, 20-pin (0,05") Cortex Debug + ETM.

Dzięki szybkości, adapter Ulink-Pro jest w stanie obsłużyć odpowiedzialne za śledzenie bloki ETM, ITM i DWT pracującego z pełną szybkością procesora. Zastosowane rozwiązanie strumieniowego przesyłania danych polegające na zbieraniu przez USB danych z debuggera bez buforowania i zapisywaniu ich na twardym dysku komputera pozwala rejestrować dane rzeczywiście w czasie rzeczywistym.

Okres rejestrowania śladu ogranicza tylko szybkość komputera i pojemność dysku. Rejestrowane są przy tym: wartości licznika rozkazów, zapisy i odczyty danych, liczniki zdarzeń, obsługiwane wyjątki, cykle CPU, wykonywane instrukcje. Na podstawie zgromadzonych danych środowisko μVision pakietu MDK-ARM tworzy nowe statystyki i analizy.

Przede wszystkim pozwala zidentyfikować wykonane instrukcje programu i dokonać analizy pokrycia (Code Coverage), tzn. oznacza na kodzie źródłowym wykonane procedury i instrukcje, a tym samym pokazuje przetestowane obszary programu i daje statystyczny obraz stopnia przetestowania całego oprogramowania.

Pozwala też zidentyfikować niesprawdzone, a być może newralgiczne w działaniu odgałęzienia programu, które należałoby przejść, nawet sztucznie wymuszając odpowiednie warunki zewnętrzne. Należy też zwrócić uwagę, że analiza pokrycia jest podstawą do wszelkich certyfikacji oprogramowania. Kolejną opcją jest rejestracja łącznego czasu wykonywania poszczególnych instrukcji programu (Execution Profiling).

Jej rozwinięciem jest analiza przetwarzania (Performance Analyzes), która polega na pokazaniu czasu wykonania poszczególnych funkcji i procedur programu oraz ich procentowego udziału w całkowitym czasie przetwarzania. Te dane i statystyki czasowe pozwalają zidentyfikować w programie krytyczne obszary i dają podstawy do optymalizacji kodu. Jest to szczególnie istotne we wszystkich aplikacjach czasu rzeczywistego, gdzie konieczne jest zapewnienie określonego czasu reakcji na przerwania, zdarzenia, alarmy itp.

DS-5 - pełne uzbrojenie na Linuksa i Androida

Rys. 6. Streamline - przykładowa wizualizacja przetwarzania

MDK-ARM jest pakietem przeznaczonym do standardowych mikrokontrolerów oferowanych przez różnych producentów półprzewodników. Dopiero pakiet ARM Development Studio 5 (DS-5) jest kompletnym zestawem narzędzi dla procesorów ARM, również dla rdzeni Cortex-A, struktur ASIC i SoC. Środowisko IDE bazuje na platformie Eclipse i jest oczywiście kompatybilne z wtyczkami firm trzecich.

Można więc pracować z kompilatorem GNU lub oryginalnym ARM-a (tym samym co w MDK-ARM) - jedynym komercyjnym kompilatorem współprojektowanym z architekturą procesorów. Kompilator ARM-a, dzięki ścisłemu powiązaniu z organizacją procesora, zapewnia unikatową optymalizację kodu pod względem objętości i czasu przetwarzania.

Dla aplikacji wymagających redukcji wielkości kodu ma możliwość przełączenia na zminimalizowany podzbiór standardowej biblioteki ISO, tzw. bibliotekę microlib C. Potrafi ograniczyć wielkość kodu wynikowego do 40%. Poza tym firmowy kompilator ARM implementuje technologie wektorowe SIMD (Single Instruction Multiple Data) - NEON i VFP, istotne w zaawansowanych aplikacjach multimedialnych, graficznych, DSP, itp.

Wspomaga tworzenie oprogramowania na platformy Linux i Android. W IDE udostępniony jest też przyjazny użytkownikowi edytor C/C++ i menedżer projektów. Tym co decyduje o użyteczności pakietu DS-5 jest jednak profesjonalny debugger. Wspomaga on uruchamianie oprogramowania na wszystkich poziomach od firmware'u bezpośrednio działającego na sprzęcie, przez wielozadaniowość realizowaną za pomocą RTOS, do aplikacji Linux i Android.

Debugger w DS-5 jest nowoczesnym, wygodnym w użytkowaniu narzędziem. Konfiguracja debuggera dla danego typu procesora jest realizowana w formie dialogu, w którym użytkownik sam wybiera z menu odpowiednie opcje lub korzysta z predefiniowanych konfiguracji dla poszczególnych typów układów.

W trakcie uruchamiania stan debuggera jest monitorowany i wizualizowany na ekranie, przy czym dopuszczalne jest jednoczesne podłączenie kilku układów docelowych, a tym samym kilku rdzeni. Śledzenie wykonania programu i praca krokowa mogą być realizowane zarówno na poziomie kodu źródłowego, jak i asemblera.

Start, stop, step in, step out, step over to typowe komendy zarządzające wykonaniem programu w trakcie testowania. Podświetlenie zdeasemblowanej aktualnie wykonywanej instrukcji i zsynchronizowanej z nią linii programu w C pokazuje na bieżąco, gdzie w programie jesteśmy. Po wstrzymaniu wykonania programu na zdeasemblowanym kodzie lub na źródłowym w C można wstawać pułapki i punkty obserwacyjne, które dodatkowo można sprząc z licznikiem, warunkiem zatrzymania.

Rys. 7. Sposoby podłączenia debuggera DS-5 do systemu docelowego

Po dojściu do takiego miejsca program można automatycznie ponownie zatrzymać lub wykonać wcześniej zapisane skrypty i automatycznie dalej kontynuować przetwarzanie. Podobnie pułapki na dostępie do danych zastawia się, klikając w oknie wyświetlającym zmienne programu lub zawartość fizycznej pamięci.

Tu też można dodatkowo określić typ dostępu, dodać licznik i warunek. Powyższe cechy charakteryzują dobry standardowy debugger lub emulator mikroprocesora. Unikatowy w stosunku do znanych powszechnie narzędzi uruchomieniowych jest Streamline. Streamline - to narzędzie debuggera DS-5 do analizy przetwarzania i optymalizacji oprogramowania aplikacji na platformach Linux i Android.

Pozwala na optymalne wykorzystanie zasobów procesora do tworzenia wysokiej jakości urządzeń. Streamline nie wymaga adaptera. Zbiera dane za pośrednictwem Ethernetu z układu docelowego z zainstalowanym systemem Linux lub Android. Diagramy czasowe pokazują dynamikę zachodzących procesów i umożliwiają szczegółową analizę przetwarzania.

Wizualizacja i analiza są możliwe dla procesorów wielordzeniowych i systemów wieloprocesorowych. Przykładowo, w aplikacjach z rozbudowaną grafiką istotna jest zsynchronizowana analiza przetwarzania procesorów graficznego GPU i aplikacyjnego CPU. Integralną częścią Streamline jest tradycyjny analizator przetwarzania pokazujący czas, jaki zajmują poszczególne procesy, procedury i instrukcje.

Pozwala to określić krytyczne czasowo rejony programu aplikacyjnego w celu poddania ich dalszej optymalizacji. Dla aplikacji wrażliwych na pobór mocy ARM oferuje niezależną, podłączaną przez USB, trzykanałową sondę mierzącą pobór mocy, napięcie i prąd w wybranych punktach pomiarowych układu aplikacyjnego. Streamline synchronizuje pomiary z wykonaniem programu aplikacyjnego i wizualizuje je. Pozwala to statycznie i dynamicznie analizować pobór mocy i pod tym kątem optymalizować kod programu.

DSTREAM - wszystko co możliwe

Fot. 8. DStream - adapter debugera DS-5

DSTREAM to zaawansowany interfejs debuggera łączący za pośrednictwem złączy JTAG lub Cortex Debug komputer nadrzędny z uruchamianym układem docelowym bazującym na dowolnym procesorze ARM. Implementuje wszystkie mechanizmy i standardy zdefiniowane w technologii CoreSight.

Może współpracować z oryginalnym DS-5 oraz z debuggerami firm trzecich. Wykorzystuje zbudowany na FPGA akcelerator dla zapewnienia maksymalnej szybkości transmisji danych i maksymalnie płynnego śledzenia wykonania programu aplikacyjnego. Jest jednym z najlepszych urządzeń w swojej klasie, o czym świadczą jego parametry i cechy funkcjonalne:

• interfejsy USB 2.0 i 10/100 Ethernet umożliwiają bezpośredni lub zdalny nadzór komputera nad układem docelowym,
• otwarty protokół RDDI (Remote Device Debug Interface) umożliwia współpracę z debuggerami firm trzecich,
• implementuje interfejsy i protokoły JTAG, SWD i SWV+ETM,
• szybkość ładowania kodu do układu docelowego wynosi do 2,5 MB/s,
• 16-bitowe słowo śladu zapisywane z szybkością 300 MHz DDR (Double Data Rate) tzn. 600 Mb/s,
• bufor pamięci śladu o pojemności 4 GB umożliwia śledzenie przez długi czas.

Podsumowanie

Chcąc mieć coś do powiedzenia na rynku elektroniki, musimy nadążać za postępem. Dziś nikt nie "rzeźbi" już w asemblerze, tylko stosuje wszystkie metody programowania strukturalnego współczesnej informatyki.

Korzysta z wielozadaniowości RTOS, bibliotek, instaluje Linuksa lub Androida i tworzy aplikację jak na komputer osobisty. Zatrzymanie się w unowocześnianiu swoich narzędzi oznacza cofanie się i stratę czasu w wyścigu o klienta.

Tadeusz Górnicki
WG Electronics
www.wg.com.pl