Zaloguj
Rysunek 11. Wpływ czułości kanału pomiarowego na interpretację danych przy niedokładnie określonych progach napięciowych TxThreshold/RxThreshold
Kontynuujemy pomiary interfejsu RS-232 (UART) korzystając z funkcji analizatora protokołów oscyloskopu Rigol DS2202. Wiemy już, że do uzyskania stabilnego oscylogramu ważne jest ustawienie odpowiedniego warunku wyzwalania. Dla uchwycenia określonej sytuacji prawie zawsze będziemy korzystać z wyzwalania pojedynczego ("Single") lub "Normal" (jeśli poszukiwana sekwencja powtarza się co jakiś czas).
Przy dobieraniu nastaw oscyloskopu Rigol DS2202 pracującego jako analizator protokołów należy uwzględniać kilka ważnych zagadnień. Jednym z nich jest prawidłowe ustawienie progów napięciowych i czułości kanałów pomiarowych. Chociaż pozornie parametry te nie są ze sobą powiązane, może zdarzyć się, że niedokładne ustawienie progów napięciowych "TxThreshold" i "RxThreshold" będzie przyczyną powstawania błędów ujawniających się przy mniejszych czułościach kanałów. Sytuację taką przedstawiono na rysunku 11.
Rysunek 12. Błędy interpretacji danych wynikające ze zbyt wolnej podstawy czasu
Napięcie progowe dla logiki 3,3 V zostało niedokładnie ustawione na 912 mV. Jak widać, przy czułości kanału równej 2 V/dz analizator dekodował dane poprawnie, ale po jej przełączeniu na 5 V/dz zaczęły pojawiać się błędy.
Błędy mogą powstawać również wtedy, gdy zostanie ustawiona zbyt wolna podstawa czasu. Skłania nas do tego względnie długi rekord akwizycji (28 Mpunktów przy włączonych dwóch kanałach). Przy wolnej podstawie czasu w rekordzie jest zapisywany duży fragment transmisji, a jego szczegóły mogą być później powiększane funkcją Zoom. Dla użytkownika jest to więc wygodny sposób pracy.
Rysunek 13. Tabelaryczna forma prezentacji zdekodowanych danych
Niestety, po wybraniu zbyt wolnej podstawy czasu, w wynikach pojawia się sygnalizacja błędów, które w rzeczywistości nie występują (rysunek 12). Co gorsze, w pierwszej chwili trudno stwierdzić, czy błąd wynika ze złego działania urządzenia czy źle dobranych nastaw oscyloskopu. Zawsze więc warto wykonać kilka pomiarów z różnymi nastawami, w szczególności zmieniając podstawę czasu, długość rekordu akwizycji i czułość kanałów.
Do dalszych rozważań zakładamy, że oscyloskop jest prawidłowo skonfigurowany. Skorzystamy teraz z tabelarycznej prezentacji zdekodowanych danych. Każdemu zdarzeniu występującemu w interfejsie przypisywany jest stempel czasowy zapisywany następnie w tabeli wraz ze zdekodowaną daną i ewentualnymi informacjami o błędach.
Dzięki temu możliwe jest precyzyjne określanie relacji czasowych pomiędzy różnymi punktami transmisji. Punktem odniesienia jest moment wyzwolenia (rysunek 13). Tabele mogą być zapisywane w postaci plików CSV w pamięci zewnętrznej typu pendrive dołączanej do gniazda znajdującego się na płycie czołowej oscyloskopu.
Rysunek 14. Interpretacja danych jako: a) pojedyncze znaki, b) pakiety
Funkcja analizatora protokołów oscyloskopu DS2202 umożliwia także dekodowanie transmisji pakietowych. Pakiet jest złożony z ciągu danych zakończonych jednym z kilku zdefiniowanych znaczników. Są to: znak NULL (bajt o wartości 0), znak LF (0Ah), znak CR (0Dh), znak spacji (20h) lub znak FFh.
W normalnym trybie, przy wyłączonym dekodowaniu pakietów, każdy znak jest interpretowany niezależnie, włącznie ze znacznikiem końca pakietu (rysunek 14a). Po włączeniu opcji dekodowania pakietowego wszystkie znaki oprócz znacznika końca pakietu są interpretowane jako jeden komunikat (rysunek 14b). Najlepiej jest to widoczne, gdy przesyłane są informacje tekstowe.
Nieprawidłowe ustawienie parametrów transmisji protokołu RS-232
Rysunek 15. Błędy interpretacji danych wynikające z nieprawidłowo ustawionego parametru "Endian"
Analizator protokołów zachowuje się tak samo, jak każdy odbiornik dołączony do danego interfejsu komunikacyjnego. Oczywiste jest zatem, że parametry jego pracy powinny być zgodne z przyjętymi w badanym urządzeniu. Niektóre błędy w nastawach są zauważalne natychmiast po wyświetleniu wyników na ekranie, ale są też takie, które nie dają jednoznacznej informacji.
Przykładem może być nieprawidłowo określona kolejność nadawanych bitów (parametr "Endian"). W interfejsie RS-232 dane są wysyłane zwykle od najmłodszego do najstarszego bitu. Jeśli w konfiguracji analizatora zostanie wybrana opcja "Endian"= MSB, to oczywiście procedura dekodująca będzie działała zgodnie z tą regułą - bity będą interpretowane od najstarszego do najmłodszego. Dla analizatora będzie to jednak sytuacja normalna, żadne błędy nie zostaną zasygnalizowane. Przypadek taki przedstawiono na rysunku 15.
Rysunek 16. Błędy interpretacji danych wynikające z nieprawidłowo ustawionego parametru "Stop Bit"
Innym parametrem, który przy błędnym wprowadzeniu będzie generował błędy dekodowania jest "Stop Bit", czyli liczba bitów stopu. Jak już było powiedziane, parametr ten ma najczęściej wartość 1, ale interfejsy dopuszczają także inne nastawy: 1,5 lub 2. Wprowadzenie np. "Stop Bit"=2 nie musi jednak oznaczać sygnalizacji błędów po każdym znaku.
Zależy to od tego czy kolejne znaki są nadawane bezpośrednio jeden za drugim czy z niewielkimi przerwami. Może się zdarzyć, szczególnie przy dużych szybkościach transmisji, że procesor nie będzie nadążał z przygotowaniem kolejnych danych do wysłania, a ponieważ w stanie oczekiwania na znak wyjście nadajnika jest w stanie wysokim, to będzie on interpretowany jako ewentualny bit stopu. Przy nastawie "Stop Bit"=2 sygnalizacja błędu nie wystąpi.
Błędów po każdym znaku nie będzie także, gdy któryś z bitów danych zostanie zinterpretowany jako bit startu, a bit danych wysyłany w chwili odpowiadającej bitowi stopu będzie miał wartość "1". Przypadek taki jest dobrze widoczny na rysunku 16 (drugi znak został tu zdekodowany bez sygnalizacji błędu, chociaż jego interpretacja jest oczywiście nieprawidłowa, gdyż jest on przesunięty względem oryginału).
Rysunek 17. Błędy interpretacji danych wynikające z nieprawidłowo ustawionej szybkości transmisji ("Baud")
Podobnie może się zdarzyć, gdy w parametrach analizatora protokołów wprowadzimy nieprawidłową szybkość transmisji. Błędy na pewno pojawią się w zdekodowanych danych, ale tak jak poprzednio, nie przy każdym odebranym znaku. Interpretacja danych będzie jednak nieprawidłowa (rysunek 17).
Powyższe przypadki przedstawiono, w celu zwrócenia uwagi na znaczenie odpowiedniej konfiguracji oscyloskopu wykorzystywanego jako analizator protokołów. Źle dobrane nastawy będą przyczyną generowania błędów, których źródło może być utożsamiane z badanym urządzeniem, a przecież właśnie do sprawdzania poprawności jego działania jest wykorzystywany analizator protokołów. Zawsze przed przystąpieniem do pomiarów warto dokładnie upewniać się czy wszystkie parametry protokołu zostały zdefiniowane prawidłowo.
Metodyka pracy z analizatorem protokołów
Rysunek 18. Wynik przeszukiwania danych funkcją Seek dostępną w droższych oscyloskopach
Po analizator protokołów sięgamy zazwyczaj wtedy, gdy musimy zlokalizować przyczynę błędnego działania jakiegoś interfejsu komunikacyjnego. Przyczyną takiego stanu mogą być usterki techniczne urządzenia, albo błędy oprogramowania. Zwykle więc poszukiwane będą albo określone dane, albo inne zdarzenia charakterystyczne dla wykorzystywanego protokołu komunikacyjnego.
W droższych oscyloskopach, dysponujących dużymi rekordami, dostępne są bardzo rozbudowane funkcje przeszukiwania zdekodowanych danych. Dzięki nim użytkownik może zapisywać długie fragmenty transmisji w rekordzie akwizycji, a następnie, już w trybie off-line, lokalizować ewentualne nieprawidłowości.
Rysunek 19. Wyzwalanie szerokością impulsu przy pracy z analizatorem protokołów
Wprowadzanie warunków poszukiwania odbywa się w sposób zbliżony do definiowania zdarzenia wyzwalającego. Wszystkie znalezione miejsca są zaznaczane markerami, a specjalne narzędzie przeszukiwania, np. Wave Inspector w oscyloskopach firmy Tektronix, pozwala szybko przemieszczać się między nimi (rysunek 18). Szczegóły są pok azywane w oknie Zoom.
W oscyloskopie DS2202 Rigola niestety nie ma takich funkcji, wyszukiwanie zdarzeń jest więc trudniejsze i polega przede wszystkim na odpowiednim definiowaniu warunku wyzwalania. Była o tym mowa w pierwszej części artykułu. Można jeszcze dodać, że korzystając z analizatora protokołów warunek wyzwalania nie musi być związany z tą funkcją. Należy szukać takich zdarzeń, które będą na tyle charakterystyczne dla transmisji, że pozwolą uzyskać stabilny oscylogram. Na przykład, jeśli badamy transmisję bloków danych wysyłanych z pewnymi odstępami czasu, korzystne może być ustawienie warunku wyzwalania impulsem o szerokości dobranej do przerw między blok ami (rysunek 19).
Rysunek 20. Badanie dwóch niezależnych interfejsów komunikacyjnych
Użytkownicy oscyloskopu DS2202 mogą badać dwa takie same (nie koniecznie te same) lub dwa różne interfejsy. Wynika to z dostępnych kanałów analizatora protokołów w tym przyrządzie. Z kolei w każdym interfejsie może występować kilka linii sygnałowych, tu jednak ograniczeniem jest liczba kanałów pomiarowych (dwa w oscyloskopie DS2202).
Na rysunku 20 przedstawiono badanie dwóch interfejsów RS232. Pierwszy kanał oscyloskopu dołączono do linii TxD, czyli do nadajnika pracującego z szybkością 38400 b/s. Drugi kanał wykorzystano do badania odbiornika interfejsu pracującego z szybkością 115200 b/s (linia RxD). Oba przebiegi są dla siebie asynchroniczne, więc na ekranie nie będą stabilnie wyświetlane. W zależności od potrzeb należy zdecydować czy wyzwalanie ma być określone dla kanału 1 czy 2.
W następnym odcinku omówimy badanie interfejsu SPI.
Jarosław Doliński, EP
Dodatkowe informacje:
NDN
www.ndn.com.pl
