Zaloguj
Rysunek 43. Okno konfiguracji protokołu Parallel (pierwsza strona)
Dotarliśmy do ostatniego odcinka cyklu artykułów o analizie protokołów. Do omówienia pozostał protokół równoległy (parallel), a więc taki, w którym informacja jest przekazywana równolegle kilkoma liniami tworzącymi interfejs. Dodatkowa linia strobująca wyznacza moment zapisu/odczytu danych. Zdarzenie to zachodzi w chwili występowania wybranego zbocza sygnału strobującego.
Pamiętamy, że jako przyrząd wzorcowy przyjęto do niniejszego cyklu artykułów oscyloskop Rigol DS2202. Jest on wykorzystywany we wszystkich eksperymentach i pomiarach. Niestety, ten typ oscyloskopu ma tylko dwa kanały analogowe, więc jego przydatność w badaniu interfejsów równoległych jest bardzo ograniczona. Fragment firmware’u realizujący funkcję analizatora protokołów równoległych jest jednak wykorzystywany również w oscyloskopach 4-kanalowych, a także w modelach z 16 kanałami cyfrowymi. Za pomocą tych oscyloskopów można dokonywać pełnej analizy protokołu Parallel.
Konfiguracja analizatora protokołu Parallel
Jak zatem badać interfejs równoległy oscyloskopem DS2202? Liczba fizycznych linii danych musi być oczywiście ograniczona do... 1, drugi kanał jest natomiast wykorzystywany do obsługi linii strobującej. Przypisanie kanałów pomiarowych do linii interfejsu jest dowolne, a odpowiednią konfigurację przeprowadza się po naciśnięciu przycisku Decode1/ Decode2 i wybraniu opcji "Decode"=Parallel (rysunek 43). Wyświetlanie dekodowanego stanu interfejsu równoległego jest możliwe po ustawieniu opcji "BusStatus"=On.
Rysunek 44. Okno konfiguracji protokołu Parallel (druga strona)
Z kolei opcja "ClkChannel" definiuje kanał oscyloskopu przypisany do linii strobującej. W artykule przyjęto, że będzie to kanał 2. Opcja "Slope" określa zbocze sygnału strobującego (zegarowego), na którym następuje odczyt linii danych i ich interpretacja (dekodowanie). Możliwe są wszystkie przypadki, tzn. odczyt na: narastającym zboczu, opadającym zboczu, narastającym lub opadającym zboczu. Następna pozycja menu konfigurującego "BusBits" określa liczbę linii danych w badanym interfejsie.
W przypadku oscyloskopu DS2202 jedyną sensowną nastawą jest "BusBits"=1, gdyż tylko jedną linię interfejsu równoległego można analizować. Firmware nie ogranicza jednak tego parametru i nawet w DS2202 może być on różny od jedności. O tym, jakie będą konsekwencje takiej nastawy będzie mowa w dalszej części artykułu.
Następne dwie opcje, tj.: "CurrentBit" i "Channel" przypisują kanały pomiarowe do kolejnych linii interfejsu równoległego. Ponieważ wcześniej przyjęliśmy, że do linii strobującej jest dołączony kanał 2, ustawiamy "CurrentBit"=0 i "Channel"=CH1 (rysunek 43). Oznacza to, że kanał 1 oscyloskopu jest dołączony do linii 0 interfejsu.
Druga strona menu konfigurująca protokół Parallel (rysunek 44) zawiera ponadto opcje formatu wyświetlanych wyników - "Format" (Hex, Decimal, Binary, a nawet ASCII), ustalenia poziomu progowego - "Threshold", pionowego przesuwu dekodowanych informacji - "Offset", a także włączenia stablicowanej postaci wyników - EventTable". Opcja ASCII dla 1-bitowego interfejsu wygląda dość kuriozalnie, ale przymykamy na to oko. Pewnego komentarza wymaga też opcja "Threshold". Po jej rozwinięciu pojawia się kilka pozycji do wyboru. Każda z nich oznacza przyjęcie predefiniowanego poziomu progowego. I tak:
- TTL ma próg 2,5 V, a więc oznacza starą, 5-woltową technologię TTL,
- CMOS ma próg 1,65 V, a więc nadaje się również dla innych technologii 3-woltowych, np. LVTTL,
- ECL ma próg -1,3 V.
Możliwe jest też ręczne ustawienie progu o dowolnej wartości.
Analiza protokołu Parallel
Zasadę działania interfejsu równoległego przedstawiono na rysunku 45. Przyjęto, że jest to interfejs składający się z 4 linii danych i linii zegarowej (strobującej). Stany linii danych są zmieniane na narastających zboczach sygnału zegarowego, natomiast odczyt linii następuje na zboczach opadających. Takiego interfejsu nie da się zbadać oscyloskopem DS2202, gdyż jak wiemy, nie ma on wystarczającej liczby wejść. Można natomiast badać pojedyncze linie danych.
Rysunek 45. Przebiegi w przykładowym interfejsie równoległym |
Rysunek 46. Przykładowy wynik analizy protokołu Parallel |
Na rysunku 46 przedstawiono przykładowy oscylogram analizy protokołu Parallel. Kanał 1 dołączono do linii danych, kanał 2 do linii sygnału zegarowego. Interpretacja danych następuje na opadającym zboczu sygnału zegarowego. Zdekodowane dane są umieszczane na wykresie B1 ("Parallel") za zboczem strobującym.
Nasuwa się tu pytanie, jak analizator zinterpretuje dane, jeśli będą się one zmieniały na zboczach odczytu. Przypadek taki przedstawiono na rysunku 47. Jak widać w opcji "Slope" menu, do pomiaru wybrano zbocze narastające, i na tym zboczu następują zmiany stanów na linii danych. Jest to sytuacja nieprawidłowa, ale analizator musi ją jakoś zinterpretować. Na wykresach z rysunku 47 widać, że analizator dekodował stan, jaki występował na linii danych tuż za zboczem zegarowym. Nie musi to być jednak reguła.
Analizator protokołu Parallel może być skonfigurowany również tak, aby dekodował dane na obu zboczach. Wynik będzie wówczas poprawny jedynie wtedy, gdy stany linii interfejsu nie będą się zmieniały na zboczach sygnału zegarowego. Trudno podać przykład interfejsu równoległego pracującego zgodnie z tym założeniem, nie mniej jednak konstruktorzy oscyloskopu DS2202 przewidzieli taką możliwość (rysunek 48).
Rysunek 47. Interpretacja danych zmieniających się na zboczu odczytu |
Rysunek 48. Interpretacja danych na obu zboczach zegarowych |
Podstawową formą wizualizacji danych dekodowanych przez analizator protokołów, przy tym najczęściej stosowaną, są wykresy czasowe. Niekiedy bardziej czytelne są jednak informacje przekazywane w postaci tabelarycznej. Wiemy, że możliwość taka istniała dla wcześniej omawianych protokołów, dla protokołu równoległego również ją zachowano. Tabelę zawierającą zdekodowane dane przedstawiono na rysunku 49. Można ją eksportować w formacie CSV do pliku zapisywanego na pendrivie, a następnie analizować np. w Excelu.
Na zakończenie pozostało jeszcze rozwikłanie pewnej wątpliwości, mianowicie: co będzie się działo, jeśli liczba linii interfejsu równoległego zostanie określona nieprawidłowo? Popełnienie błędu od dołu nie jest możliwe, gdyż najmniejsza wartość parametru "BusBits" jest równa 1, a jeden kanał zawsze jest dostępny w oscyloskopie. Jednak już przy wartości "BusBits"=2 pojawia się wątpliwość, gdyż w oscyloskopie DS2202 nie ma możliwości fizycznej analizy dwóch linii danych. Analizator nie będzie jednak sygnalizował błędu. Wszystkie linie zostaną wirtualnie ze sobą połączone, a ich stan będzie taki sam, jaki występuje na linii, do której jest dołączony fizyczny kanał oscyloskopu. Przykład przedstawiono na rysunku 50. Przyjęto, że interfejs ma dwie linie danych i że są one przypisane do kanału 1 oscyloskopu. W zaznaczonym na oscylogramie impulsie zegarowym odczytano stan wysoki na wejściu CH1, zatem analizator interpretuje stan wysoki na obu liniach interfejsu (D0 i D1), czemu odpowiada heksadecymalny zapis 0x03.
Rysunek 49. Tabelaryczna forma wyników analizy protokołu Parallel |
Rysunek 50. Interpretacja danych w przypadku zadeklarowania nieprawidłowej liczby danych interfejsu równoległego |
Uwagi
W cyklu artykułów o analizie protokołów ograniczono się do opcji dostępnych w oscyloskopie Rigol DS2202. Ogólnie zasada pracy z tego typu urządzeniami jest podobna, niezależnie od producenta i od rodzaju oscyloskopu (stacjonarny, USB czy analizator stanów logicznych z opcją analizy protokołów). Mogą oczywiście występować drobne różnice wynikające z rozwiązań konstrukcyjnych czy przyjętych założeń, ale nie powinny mieć istotnego wpływu na obsługę tych urządzeń. Jest jednak jeden warunek konieczny - użytkownik powinien dobrze znać i rozumieć badany protokół, by móc prawidłowo interpretować analizowane zdarzenia.
Jarosław Doliński, EP
Dodatkowe informacje:
NDN
www.ndn.com.pl
