Wyzwalanie zdarzeniami 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. 6). Pierwszą czynnością jest wybranie źródła wyzwalania, do czego służy lista rozwijana „Source”. 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.

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

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. Na rys. 7 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 rys. 8.

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

Rys. 8. Oscylogram po wyzwoleniu zdarzeniem zdefiniowanym na zakładce z rys. 6

Błędy dekodowania

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 rys. 9. Rozpatrywany jest tu blok danych składający się m.in. z kolejnych znaków ASCII: ABCD#s. Na rys. 9a. 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. 9b). Nadal wszystko jest w porządku, ale dalsze przesunięcie o 10 ms (rys. 9c) 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. 9d) 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. 9f).

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

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.

Następny artykuł z tego cyklu będzie poświęcony analizie protokołów SPI oraz I²C.