JTAG, a może … interfejs PDI?

Autor: Tmf
Redakcja: Dondu

W poprzednim artykule pokazałem korzyści płynące z zastosowania interfejsu JTAG, trochę pomijając jego wady.

A jakie wady JTAG posiada? Nie są one duże, ale na trzy warto zwrócić uwagę:

• nie wszystkie AVRy posiadają JTAG. Nie jest to problemem, gdyż zazwyczaj program pisze się i tak na „większym” procku, potem otrzymany kod przenosi się na procesor docelowy. Ma to kilka zalet – przede wszystkim wygodne debuggowanie kodu, co ma związek z możliwością wykorzystania JTAGa i możliwość lepszego doboru procesora docelowego – w końcu wiemy już jakie zasoby będą wykorzystane i dokładnie wiemy ile jest potrzebne pamięci FLASH i SRAM.
• interfejs ten wymaga kilku sygnałów (TMS, TDO, TCK, TMS), które są współdzielone z pinami IO procesora. W efekcie, jeśli odblokowany jest interfejs JTAG to nie możemy używać współdzielonych pinów IO i vice versa.
• kolejna wada wynika z wielkości złącza – jak pokazałem w poprzednim artykule typowe złącze JTAG ma 10 pinów, a więc jest spore. Oczywiście osoby korzystające z elementów przewlekanych powiedzą – żaden problem. Lecz co raz częściej stosujemy małe elementy do montażu powierzchniowego, przy których złącze JTAG ma monstrualne rozmiary.

Oczywiście możemy wykorzystać złącze typu „gold pin” o rozstawie np. 50 milsów, które jest znacznie mniejsze, ale możemy także zrezygnować z JTAGa, bez rezygnowania z możliwości jakie daje.

PDI, czyli prostsze jest lepsze

Czytelnicy moich książek już spotkali się z interfejsem PDI. Co to takiego? Tym razem sama nazwa (The Program and Debug Interface) już nam dużo mówi – jest to interfejs programowania i debuggowania. W interfejs ten wyposażone są nowsze procesory firmy Atmel – XMEGA. Umożliwia on zarówno programowanie układów, jak i ich debuggowanie, oferując takie same możliwości jak interfejs JTAG.

Posiada on więc wszystkie zalety interfejsu JTAG, lecz do jego realizacji potrzebujemy tylko dwóch pinów IO – RESET oraz PDI. I tu dobra wiadomość. RESET zwykle nie jest wykorzystywany jako pin IO, w związku z tym nie ma problemu z jego wykorzystaniem do realizacji interfejsu PDI.

Drugi wymagany pin – PDI jest zazwyczaj również oddzielnym wyprowadzeniem procesora (aczkolwiek nie zawsze), niedostępnym w roli zwykłego pinu IO. Stad też interfejs ten nie koliduje z pinami IO, w efekcie jego użycie nie blokuje nam części portu mikrokontrolera, tak jak to było w przypadku JTAG. A nawet jeśli koliduje – to tracimy tylko jeden pin IO, a nie cztery.

Interfejs ten jest też elektrycznie prostszy w realizacji:

Złącze PDI

Jak widzimy wykorzystuje on 6-pinową wtyczkę – identyczną z nowym standardem gniazda ISP proponowanym przez Atmela. Dzięki temu, jeśli dysponujemy nowym programatorem, np. AVRISP MkII ten sam kabelek możemy wykorzystać do programowania układów poprzez interfejs ISP (starsze mikrokontrolery firmy Atmel), jak i przez PDI (mikrokontrolery XMEGA). Wyboru interfejsu dokonuje się programowo – a nawet to nie jest potrzebne, gdyż, po wyborze w Atmel Studio używanego procesora, IDE samo przełącza programator we wspierany przez procesor tryb programowania.

Zaletą PDI jest prostota – wykorzystujemy tylko 4 przewody:

• PDI_DATA (PDI), 
• PDI_CLK (RESET), 
• Vcc,
• GND.

Zacznijmy od końca, czyli Vcc i GND. Wykorzystując ISP zawsze łączyliśmy GND programatora i programowanego układu (chyba, że dysponujemy programatorem z optoizolacją, co zdarza się niezmiernie rzadko). Natomiast połączenie Vcc było opcjonalne – zazwyczaj służyło możliwości zasilania programowanego układu z programatora.

W przypadku PDI Vcc programatora i programowanego układu musimy połączyć zawsze. Dlaczego? Dlatego, że programowany mikrokontroler (na razie jest to jakiś AVR z rodziny XMEGA) może pracować z napięciem 1,6-3,6 V. Aby programator mógł dostosować poziomy napięć do wymogów programowanego układu musi wiedzieć jakie napięcie w nim panuje – stąd też musimy podłączyć Vcc.

Pamiętaj, że programator pracujący w trybie PDI nigdy nie zasila programowanego układu – Vcc służy tylko do pomiaru napięcia w układzie.

Oprócz zasilania musimy jeszcze podłączyć linie samego interfejsu tak jak to pokazano na rysunku:

Programator PDI

Tu też musimy zwrócić uwagę na parę rzeczy. Przede wszystkim powinniśmy zrezygnować z rezystora podciągającego RESET do Vcc. Rezystor ten nie jest potrzebny (procesor ma własne, o wiele lepsze układy monitorowania RESET), a jeśli się uprzemy go wstawić to powinien mieć on rezystancję >10 kΩ. Jeśli będzie miał mniejszą to niektóre debuggery (AVR Dragon) będą odmawiały współpracy.

Rzeczą, której absolutnie powinniśmy unikać to wszelkich kondensatorów obciążających linię RESET i PDI_DATA. Uniemożliwią one poprawną komunikację z procesorem.

Jak wspomniałem, układy XMEGA posiadają o wiele bardziej rozbudowane układy monitorowania sygnału RESET, stąd też zamiast stosować różne, znane z wcześniejszych AVRów sztuczki, lepiej poprawnie skonfigurować dostępne w nich układy monitorujące. Taka konfiguracja zazwyczaj nie jest potrzebna, gdyż ustawienia fabryczne są optymalne w większości zastosowań.

Musimy też pamiętać, o tym, aby sygnał RESET nie rozprowadzić jako sygnał zerowania do innych układów na płytce. PDI wykorzystując RESET by je okresowo inicjalizował, w efekcie debuggowanie procesora byłoby co prawda możliwe, ale ciągłe resety pozostałych urządzeń uniemożliwiłyby w praktyce debuggowanie w układzie.

Ponieważ wykorzystujemy tylko 4 sygnały, stąd też możemy użyć w programowanym układzie gniazda 4-pinowego, które jest jeszcze mniejsze. Ja w praktyce, jeśli mam naprawdę mało miejsca w ogóle nie używam gniazda, lecz robię 4 punkty stykowe na PCB – takie punkty można też wyprowadzić w postaci pasków (coś na kształt złącza krawędziowego) na brzeg płytki – grubość standardowego laminatu odpowiada rozstępowi pinów na listwie goldpin, można ją więc nasunąć na płytkę uzyskując w miarę pewny kontakt. Mniej więcej zasadę tą ilustruje poniższy rysunek:

Zącze krawędziowe

I to wszystko. Nie pozostaje nic innego jak zacząć korzystać z nowego, prostego i szybkiego interfejsu. W tym celu jeśli posiadamy programator kompatybilny z Atmel Studio wybieramy okienko programowania i wybieramy interfejs PDI:

Programowanie via PDI

Warto zaznaczyć, że musiałem dokonać wyboru PDI, gdyż użyty mikrokontroler ATxmega256A3BU posiada zarówno interfejs JTAG, jak i PDI. Gdyby posiadał tylko PDI – wybór dokonałby się automatycznie. Jak widzimy po wybraniu interfejsu możemy bez problemu nawiązać połączenie z procesorem.

Warto zwrócić uwagę na jeszcze jedną sprawę. Jeśli procesor oprócz PDI jest także wyposażony w interfejs JTAG, to ten ostatni jest domyślnie odblokowany. W niczym nam to nie przeszkadza, lecz jak pamiętamy, piny JTAG są współdzielone z pinami IO, stąd też przy odblokowanym JTAG nie będziemy mogli wykorzystać odpowiednich pinów IO. Jeśli musimy z nich skorzystać wygodnie jest zablokować JTAG, pozostawiając odblokowany wyłącznie interfejs PDI. W tym celu przestawiamy odpowiedni fusebit:

Wyłączenie interfejsu JTAG

Aby zablokować JTAG wystarczy odhaczyć fajkę przy fusebicie JTAGEN (JTAG enable). To samo możemy oczywiście uzyskać programowo – w XMEGA mamy programowy dostęp do bitów konfiguracyjnych procesora, stąd sama aplikacja może sobie je skonfigurować wedle życzenia programisty.

Możliwości i szybkość działania

Na koniec pozostaje jeszcze porównać szybkość działania i możliwości obu interfejsów. Porównanie to jest krótkie – są one takie same. Podobnie - szybkość programowania, czy też responsywność w czasie debuggowania są praktycznie identyczne (subiektywnie wydaje mi się, że PDI jest dużo szybszy, ale nie testowałem tego zbytnio).

Po co więc stosować PDI?
Wystarczy rzucić okiem na rozpis sygnałów na poszczególnych interfejsach:

Od lewej: PDI, ISP i JTAG.

Jak widzimy PDI jest po prostu prostszy – stąd wygodniejszy w zastosowaniu go we własnych układach.