UART/RS232 - Analiza protokołów szeregowych oscyloskopami Rohde & Schwarz

Tabela 1. Zestawienie opcji wykorzystywanych do analizy protokołów w oscyloskopach Rohde&Schwarz rodzin RTO, RTE i RTM

Możliwość badania komunikacyjnych interfejsów szeregowych mają oscyloskopy wszystkich rodzin, a więc: RTO (najbardziej funkcjonalna), RTE i RTM (podstawowa). Analiza protokołów jest też dostępna w oscyloskopach HMO znanych wcześniej jako wyroby Hamega, obecnie sprzedawanych z logo R&S.

W artykule jako model odniesienia przyjęto oscyloskop RTE1034, ale oprogramowanie firmowe wszystkich rodzin jest na tyle do siebie podobne, że przedstawione tu informacje będą przydatne dla wszystkich oscyloskopów RTO, RTE i RTM. Analiza poszczególnych protokołów może być prowadzona pod warunkiem zainstalowania opcji R&S RTE-Ki (lub analogicznych opcji dla innych rodzin - tab. 1) udostępniających odpowiednie funkcje wyzwalania i dekodowania.

Wyzwalanie protokołów I²C, SPI, UART/RS-232/RS-422/RS-485 jest objęte standardem w oscyloskopach RTO. Pomiary interfejsów szeregowych mogą być wykonywane z zastosowaniem standardowych sond analogowych. Obowiązują wówczas ograniczenia wynikające z takich parametrów technicznych oscyloskopu jak: pasmo, szybkość próbkowania, długość rekordu akwizycji itp.

Możliwości te są rozszerzane po zainstalowaniu opcji MSO obsługującej dodatkowo kanały cyfrowe. Mogą być one wykorzystywane również do analizy protokołów. Zestawienie możliwości poszczególnych rodzin przedstawiono w tabeli 1. W tabeli 2 zestawiono natomiast parametry pomiaru sygnałów cyfrowych oscyloskopem z opcją MSO.

Jak widać z danych zamieszczonych w tab. 1 możliwości analizy nieznacznie różnią się pomiędzy poszczególnymi rodzinami.Najszersze ma najbardziej zaawansowana technicznie rodzina RTO, mniejsze RTE i najmniejsze RTM. Należy zauważyć, że podstawowe interfejsy są obsługiwane przez wszystkie oscyloskopy R&S, a dodatkowo w rodzinie RTO zawarto w standardzie funkcje wyzwalania dla interfejsów SPI, I²C oraz UART/RS232/RS422/RS485.

Analiza protokołu UART/RS232

Rys. 1. Rozpoznawanie błędów parzystości w protokole UART/RS232

Przesyłane interfejsem UART/RS2232 informacje formowane są z ramek składających się z: bitu startu, 5, 6, 7 lub 8 bitów danych, bitu parzystości (opcjonalnego, zwykle pomijanego) i 1, 1,5 lub 2 bitów stopu.

Najczęściej stosowana jest ramka 8,n,1 (8 bitów danych, bez bitu parzystości, 1 bit stopu). Zwykle też jako pierwszy jest przesyłany zerowy, najmłodszy bit danej (LSB), ale dopuszczalna jest też kolejność odwrotna, tzn. od MSB do LSB. Interfejs UART/RS232 wykorzystuje transmisję asynchroniczną, co oznacza, że nie jest stosowana linia zegarowa.

Można uznać, że elementami synchronizującymi są znaki startu, a dokładność rozpoznawania pozostałych elementów ramki zależy od dokładności lokalnych zegarów po stronie nadawczej i odbiorczej. Choć teoretycznie częstotliwość takiego zegara może być dowolna, to w praktyce są stosowane znormalizowane wartości.

Analizę wszystkich protokołów prowadzoną przy użyciu oscyloskopów R&S należy rozpocząć od wybrania odpowiedniego interfejsu i zdefiniowania wszystkich jego parametrów. Czynności te wykonuje się na przykład po naciśnięciu przycisku PROTOCOL znajdującego się na płycie czołowej oscyloskopu. Na ekranie zostaje wówczas wyświetlona zakładka zawierająca wszystkie parametry badanego interfejsu, która dla UART-a/RS232 będzie wyglądała, jak na rysunku 1.

Z łatwością rozpoznawane są na niej poszczególne pola i listy rozwijane definiujące parametry interfejsu, a więc: typ interfejsu, prędkość transmisji, liczba bitów stopu, długość ramki, opcje parzystości, kolejność transmitowania bitów. Okno konfiguracji jest bardzo czytelne, w czym pomagają zdefiniowane kolorami bloki wyboru parametrów oraz graficzna interpretacja analizowanego protokołu.

W wielu analizatorach protokołów uwzględniane są tylko opcje parzystości: None, Odd i Even, czyli bez parzystości, nieparzystość i parzystość. W oscyloskopach R&S w analizie protokołów można ponadto wybierać opcje Mark, Space i Don’t Care. Mark i Space to obecnie bardzo rzadko stosowane metody kontroli poprawności transmisji.

Przypomnijmy, że jeśli wybrano kontrolę parzystości (Even), to bit parzystości w prawidłowo odebranym znaku powinien mieć wartość "0", jeśli wystąpiła parzysta liczba jedynek w znaku (rys. 1). Analogicznie jest po włączeniu kontroli nieparzystości (Odd). Bit kontrolny powinien być równy "0" tylko wtedy, gdy w przesyłanym znaku jest nieparzysta liczba jedynek.

Rys. 2. Transmisja blokowa, w której końcem bloku jest znak "*" lub przerwa czasowa

Jeśli więc włączono kontrolę nieparzystości (Odd) i w bajcie o nieparzystej liczbie jedynek bit kontrolny jest równy "1", to mamy przypadek wykrycia błędu transmisji. Załóżmy, że nadajnik wysyła bajt z parzystą liczbą jedynek. Przy włączonej kontroli Even ustawia dla niego bit parzystości na "0". Jeśli odczytany przez odbiornik bit kontrolny będzie miał wartość "1", to będzie oznaczało, że któryś z bitów w tym bajcie został przekłamany (rys. 1). Niestety, w takiej metodzie kontroli nie ma możliwości identyfikacji tego bitu. Jak na ironię przekłamany może być sam bit kontrolny.

Bity parzystości na oscylogramie przypisanym do danego interfejsu są wyodrębnione od całego znaku. Ich nieprawidłowa wartość jest sygnalizowana kolorem czerwonym, prawidłowa natomiast kolorem pomarańczowym. Błędny znak jest wyświetlany kolorem fioletowym w odróżnieniu od żółtego znaku interpretowanego jako bezbłędny. Symbolami "<" i ">" opisywane są bity startu i stopu.

Opcja Mark stanowi dość specyficzną i niestety bardzo nieskuteczną kontrolę transmisji. Bit kontrolny powinien być w tym przypadku zawsze transmitowany i niezależnie od liczby jedynek w znaku zawsze ma wartość "1". Analogicznie jest z opcją Space, tylko teraz bit kontrolny ma zawsze wartość "0". Wybierając opcję Don’t Care analizator pomija badanie bitu parzystości, który oczywiście powinien być nadawany zgodnie z którąś z powyższych metod.

Warto jeszcze zwrócić uwagę na kilka dodatkowych parametrów zawartych w opcjach analizy protokołu UART/RS232. Są to:

• "Polarity", określający poziom logiczny występujący na liniach TxD i RxD w stanie Idle, a więc wtedy, gdy nie są przesyłane żadne dane. W większości rozwiązań praktycznych jest to poziom wysoki.
• "Packets", określający czasami stosowaną metodę organizowania danych w większe bloki (pakiety). W rozwiązaniu takim przyjmowana jest zasada, że każdy blok danych zawierający powiązane ze sobą dane, np. wyniki pomiarów wykonanych w jednej sesji, jest kończony umownym znakiem. Z oczywistych powodów, jako znak końca bloku powinna być wybierana dana niewystępująca w samym bloku. Znak końca bloku jest ustalany w opcji "End word", po wybraniu której wprowadza się stosowny wzorzec. Znakiem końca pakietu może też być określona przerwa czasowa pomiędzy kolejnymi blokami. Zatem po wybraniu opcji "Timeout" należy wprowadzić długość tej przerwy w odpowiednich jednostkach czasu. Przykład transmisji, w której jest przesyłany blok danych kończony znakiem "*" (0×2A) przedstawiono na rysunku 2. Dodatkowo widoczne są tu przerwy między blokami, które mogą być również interpretowane jako koniec bloku.

Rys. 3. Tabelaryczna postać wyświetlania danych zdekodowanych przez analizator protokołów

Analizator protokołów zamieszcza interpretację danych na wykresie BUS, który wygodnie jest umieścić bezpośrednio pod przebiegiem, np. tak jak na rysunku 2. Jeżeli zdefiniowano transmisję blokową, to dodatkowo w zwartej postaci jest wyświetlany cały odczytany komunikat przesyłany w bloku. Możliwe są różne formaty prezentacji danych (np. hex, dec, octal, ASCII itp.).

Przy dużej ilości danych, tak prezentowane wyniki stają się mało czytelne, dużo wygodniejsza jest forma tabelaryczna (rys. 3). W tabeli z łatwością można odnaleźć interesujące miejsce transmisji. Po kliknięciu na odpowiadający mu numer widoczny w kolumnie "Word", ponownie zostaje wyświetlony wykres, przy czym jego centralny punkt będzie odpowiadał wybranej w tabeli chwili czasowej.

Wyzwalanie zdarzeniami w protokole UART/RS232

Rys. 4. Zakładka konfiguracji układu wyzwalania zdarzeniami występującymi w protokole UART/RS232

Podczas analizy danych transmitowanych badanym interfejsem bardzo przydatne są opcje wyzwalania zdarzeniami charakterystycznymi dla protokołu. Niezależnie od nich mogą być wykorzystywane i inne opcje dostępne w oscyloskopie, w tym standardowe.

Dobór zdarzenia wyzwalającego w wielu przypadkach decyduje o powodzeniu całego pomiaru. Po naciśnięciu przycisku Trigger na ekranie zostaje wyświetlona zakładka, na której dokonuje się konfiguracji układu wyzwalania (rys. 4). Pierwszą czynnością jest wybranie źródła wyzwalania, do czego służy lista rozwijana "Source".

Rys. 5. Zakładka konfiguracji układu wyzwalania od danej równej „%”, występującej w bloku na pozycji o indeksie 7

Ponieważ będzie badany protokół szeregowy, należy wybrać opcję "Serial bus". Następnie ustalany jest typ badanego protokołu z listy "Protocol" - opcja "UART/RS232". Pozostało jeszcze najważniejsze - wybranie samego zdarzenia.

Dla protokołu UART/RS232 jest to: bit startu, początek bloku danych, dana o zdefiniowanej wartości, błąd parzystości, przerwa w nadawaniu (stan przeciwny do Idle), bit stopu. Niektóre z tych opcji wymagają określenia dodatkowych parametrów. Pojawiają się one po zatwierdzeniu wybranego zdarzenia.

Wyzwalanie bitem startu, określoną daną, błędem parzystości i błędem znaku stopu jest dość oczywiste, podstawa czasu jest wyzwalana po stwierdzeniu wybranego zdarzenia. Opcja "Data" jest jednak szczególnie przydatna podczas badania transmisji blokowej. W oscyloskopach R&S zaimplementowano wyzwalanie po wykryciu określonej danej w bloku, nawet wtedy, gdy powtarza się ona w bloku wielokrotnie.

Rys. 6. Oscylogram po wyzwoleniu zdarzeniem zdefiniowanym na zakładce z rysunku 5

Na rysunku 5 przedstawiono zakładkę, na której widoczne są opcje wyświetlane po wybraniu wyzwalania typu "Data". Wcześniej w konfiguracji protokołu w polu "Packets" zaznaczono opcję inną niż "None" ("End word" lub "Timeout").

W opisywanym przykładzie wyzwolenie powinno nastąpić po rozpoznaniu w bloku znaku "%" występującego na pozycji o indeksie 7. Przyjęto, że pierwsza dana ma indeks 0, druga 1 itd. Indeks 7 oznacza więc ósmy znak w bloku. Jeśli będzie on równy "%", nastąpi wyzwolenie. Sytuację taką przedstawiono na rysunku 6.

Błędy dekodowania

Rys. 7. Błędy dekodowania danych przez analizator protokołów, na które trzeba zwracać uwagę

Analizator protokołów dekoduje dane na podstawie próbek zapisanych w rekordzie akwizycji. Dekodowanie rozpoczyna od poszukiwania pierwszego bitu "0", który będzie traktowany jako bit startu (w typowej ramce). Problem polega na tym, że bity startu nie różnią się niczym od bitów danych. Co się więc zdarzy, gdy na początku rekordu akwizycji znajdzie się połowa danej z interfejsu?

Analizator zinterpretuje pierwszy napotkany bit "0" jako bit startu, gdy tymczasem może to być jakiś wewnętrzny bit danej. Dalsza interpretacja będzie oczywiście błędna, przynajmniej do wyraźnego zakończenia ramki i odnalezienia następnej. Przykład taki przedstawiono na rysunku 7. Rozpatrywany jest tu blok danych składający się m.in. z kolejnych znaków ASCII: ABCD#s.

Na rysunku 7a nie ma żadnych wątpliwości z interpretacją. Teraz przesuwamy oscylogram pokrętłem Position w lewo (w przykładzie o 330 ms), tak żeby początek znalazł się tuż przy lewej krawędzi ekranu (rys. 7b). Nadal wszystko jest w porządku, ale dalsze przesunięcie o 10 ms (rys. 7c) spowodowało, że pierwsza dana znalazła się poza ekranem, wypadła też z rekordu akwizycji.

Tu złożyło się szczęśliwie i analizator tylko wyciął tę daną, wyświetlając zdekodowany blok jako: BCD#s. Przy przesunięciu oscylogramu o kolejne 4 ms (rys. 7d) szczęście jednak się skończyło. Tym razem analizator zupełnie się pogubił. Pojawiły się błędy ramek, niektóre dane są oznaczone jako błędne, a co gorsze dane wyświetlone jako bezbłędne zupełnie nie odpowiadają temu, co jest przesyłane interfejsem. Sytuacja powtarza się przy dalszym przesuwaniu, aż w pewnym momencie znowu trafiamy na prawidłową lokalizację bitu startu i analizator poprawnie dekoduje dane (rys. 7f).

Tabela 2. Parametry pomiaru sygnałów cyfrowych

Podobne kłopoty mogą występować na końcu rekordu, o czym użytkownik musi zawsze pamiętać. Jeśli jakaś ramka wychodzi poza rekord, najczęściej jest zaznaczana na oscylogramie jako błędna, choćby dlatego, że dla grupy bitów nie znaleziono bitu stopu. Sygnalizacja błędów jest w tym przypadku informacją dla użytkownika, że powinien wykonać jakiś zabieg zapewniający umieszczenie w rekordzie akwizycji również tego fragmentu transmisji, który został oznaczony jako błędny. Rozwiązaniem może być zmiana podstawy czasu, albo odpowiednie przesunięcie punktu wyzwolenia (opóźnienie).

Przykład ten powinien wyczulić użytkowników na pewne nietypowe sytuacje występujące podczas wykorzystywania oscyloskopów do analizy protokołów. Jak widać, nigdy nie można bezkrytycznie podchodzić do wyników, zawsze należy zachować czujność. Są to zresztą efekty występujące w każdym oscyloskopie, niezależnie od producenta.

Artykuł pochodzi z portalu mikrokontroler.pl.

Jarosław Doliński
Rohde & Schwarz Przedstawicielstwo w Polsce
www.rohde-schwarz.com