Praktyczne korzyści jakie przenosi projektantom ARM CoreSight
Jest kilka praktycznych udogodnień w pracy z mikrokontrolerami opartymi o rdzenie Cortex-M3 i M4, które niesie ze sobą architektura CoreSight oraz kilka wad i problemów, które trzeba mieć na uwadze.
Korzyści to:
- mniejsza liczba niezbędnych wyprowadzeń w układzie scalonym niż przy tradycyjnym JTAG’u,
- możliwość podglądu danych w czasie rzeczywistym, w trakcie pracy aplikacji, bez wprowadzania zmian w jej zachowaniu,
- możliwość wykorzystania niezbyt kosztownego debugowania za pomocą funkcji printf() poprzez kanał instruction trace macrocell (ITM),
- możliwość statystycznego profilowania aplikacji,
- możliwość debugowania w trybach obniżonego poboru energii,
- wykorzystanie mało kosztownych obliczeniowo tzw. próbników debugujących (ang. debug probes),
- możliwość raportowania przerwań i innych zdarzeń,
- łatwość pomiarów czasu wykonywania sekcji kodu dzięki wykorzystaniu znaczników czasowych.
Do wad natomiast można zaliczyć:
- transfer danych z wykorzystaniem pojedynczego pinu SWO skutkujący pewnymi ograniczeniami przepustowości (w niektórych układach dostępne są interfejsy 4-bitowe, przy ich wykorzystaniu koszta debugowania wzrastają jednak znacznie),
- monitorowanie stanu danych w czasie rzeczywistym jest ograniczone przez liczbę dostępnych w układzie komparatorów (typowo czterech),
- śledzenie wykonanych instrukcji jest możliwe w układach z 4-bitowym interfejsem debugingowym, nie ma w nich jednak możliwości śledzenia danych.
Aby porównać środowiska do debugowania wykorzystujące architekturę CoreSight i tradycyjnego JTAG’a warto prześledzić rysunki 2 i 3 zamieszczone poniżej.
Rys. 2. Widok okna programu w czasie debugowania z wykorzystaniem tradycyjnej metody run/stop
Rys. 3. Widok okna programu w czasie debugowania z wykorzystaniem Serial Wire Viewer
Na rysunku 3 widoczne jest wiele dodatkowych informacji, wliczając w to:
- wykresy wartości zmiennych w pamięci aktualizowane w czasie rzeczywistym, bez ingerencji w pracę układu (na rysunku są to wartości zmiennych X-Y-Z akcelerometru),
- statystyczny profil czasu, jaki aplikacja „spędza” w różnych miejscach kodu,
- komunikaty realizowane za pomocą funkcji printf() poprzez ITM z funkcji obsługujących akcelerometr,
- indeksowany czasem wystąpienia spis wszystkich przerwań systemowych wraz z opisami,
- statystyki dotyczące przerwań i wyjątków.
Podstawową cechą wszystkich tych informacji jest sposób ich prezentacji. W mgnieniu oka projektant może zwizualizować stan aplikacji i uzyskać odpowiedź na podstawowe pytania:
- czy dane z czujników zmianiają się na bieżąco zgodnie z przewidywaniami?
- czy przerwania są uruchamiane w odpowiednich momentach i w odpowiedniej kolejności?
- czy aplikacja spędza znaczne okresy czasu w konkretnych miejscach?
Są to bardzo wartościowe informacje w momencie gdy wszystkie części systemu, np.: sterowniki peryferiów, kod aplikacji, RTOS, stos TCP/IP, system plików użyty w pamięci Flash oraz stos USB są już połączone. Problemy z jednym z fragmentów kodu mogą wtedy być spowodowane przez problemy w innym, pozornie nie związanym, fragmencie. W takim wypadku, konkretne dane przekształcone w informację wizualną pozwalają szybko zlikwidować wiele potencjalnych kłopotów.
