Jak odczytać dane szeregowe z oscyloskopu

Mam mikrokontroler (PICAXE 20X2) i miernik puli. Zaprogramowałem micro tak, aby wysyłać dowolną zmianę miernika puli do portu szeregowego komputera. Oczywiście jest to 8-bitowy ADC. Teraz interesującą rzeczą jest dla mnie możliwość dekodowania tych danych szeregowych na oscyloskopie.

Oto dwa zdjęcia, pierwsze to kiedy mikro wysyła „0” do komputera, a następne to „255”. Dane są przesyłane przy użyciu 9600 buad i mogę je odbierać na terminalu PC.

Pierwsze zdjęcie

Drugie zdjęcie

Moje pytanie brzmi: czy przechwyciłem odpowiednie dane w moim zakresie, a po drugie, jak można odczytać i zdekodować te impulsy do formatu szesnastkowego lub ascii. Mam na myśli, jak odczytać te rosnące i opadające impulsy (0/1).

Dzięki.

Po pierwsze coś, co zauważył Olin: poziomy są odwrotnością tego, co zwykle produkuje mikrokontroler:

Nie ma się czym martwić, przekonamy się, że możemy to również przeczytać w ten sposób. Musimy tylko pamiętać, że w zakresie bit startowy będzie 1a bit stop 0.

$\mu$$\mu$$\mu$1$\mu$0

0x001$\mu$
0xFF$\mu$

szacuje:

0b11001111 = 0xCF
0b11110010 = 0xF2

0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2

edytuj
Olin ma absolutną rację, to coś w stylu ASCII. W rzeczywistości jest to 1 uzupełnienie ASCII.

0xCF ~ 0x30 = „0”
0xCE ~ 0x31 = „1”
0xCD ~ 0x32 = „2”
0xCC ~ 0x33 = „3”
0xCB ~ 0x34 = „4”
0xCA ~ 0x35 = „5”

0xF2 ~ 0x0D = [CR]

Potwierdza to, że moja interpretacja zrzutów ekranu jest poprawna.

edytuj 2 (jak interpretuję dane, na popularne żądanie :-))
Ostrzeżenie: to długa historia, ponieważ jest to zapis tego, co dzieje się w mojej głowie, gdy próbuję dekodować coś takiego. Przeczytaj go tylko, jeśli chcesz nauczyć się jednego sposobu na jego rozwiązanie.

Przykład: drugi bajt na pierwszym zrzucie ekranu, zaczynając od 2 wąskich impulsów. Zaczynam od drugiego bajtu celowo, ponieważ jest więcej krawędzi niż w pierwszym bajcie, więc łatwiej będzie go poprawnie ustawić. Każdy z wąskich impulsów ma około 1/10 części podziału, więc każdy może mieć 1 bit wysokości, a pomiędzy nimi niski bit. Nie widzę też nic węższego niż to, więc myślę, że to tylko kawałek. To jest nasza referencja.
Następnie, po 101dłuższym okresie na niskim poziomie. Wygląda na około dwa razy szerszy niż poprzednie, więc może być 00. Wysokie podążanie, które znów jest dwa razy szersze, tak będzie 1111. Mamy teraz 9 bitów: bit początkowy ( 1) plus 8 bitów danych. Więc następny bit będzie bitem stopu, ale ponieważ jest0 nie jest od razu widoczny. Więc mamy to wszystko razem1010011110 , w tym bit startu i stopu. Gdyby bit stopu nie wynosiłby zero, zrobiłbym gdzieś złe przypuszczenie!
Pamiętaj, że UART najpierw wysyła LSB (najmniej znaczący bit), więc będziemy musieli odwrócić 8 bitów danych: 11110010= 0xF2.

Znamy teraz szerokość pojedynczego bitu, podwójnego bitu i 4-bitowej sekwencji i przyjrzeliśmy się pierwszemu bajtowi. Pierwszy wysoki okres (szeroki impuls) jest nieco szerszy niż 1111w drugim bajcie, więc będzie miał szerokość 5 bitów. Okres niski i wysoki po nim są tak szerokie jak podwójny bit w drugim bajcie, więc otrzymujemy 111110011. Znowu 9 bitów, więc następny powinien być bitem niskim, bitem stopu. Zgadza się, więc jeśli nasza ocena trafności jest poprawna, możemy ponownie odwrócić bity danych: 11001111= 0xCF.

Potem dostaliśmy wskazówkę od Olin. Pierwsza komunikacja ma 2 bajty długości, 2 bajty mniej niż druga. A „0” jest także o 2 bajty krótsze niż „255”. Prawdopodobnie jest to coś w rodzaju ASCII, choć nie do końca. Zauważam również, że drugi i trzeci bajt „255” są takie same. Świetnie, to będzie podwójne „5”. Mamy się dobrze! (Musisz od czasu do czasu się zachęcić.) Po zdekodowaniu „0”, „2” i „5” zauważam, że istnieje różnica 2 między kodami dla pierwszych dwóch, a różnica 3 między ostatnimi dwa. I wreszcie zauważam, że 0xC_jest to uzupełnienie 0x3_, które jest wzorem cyfr w ASCII.

Coś się nie sumuje. Twoje sygnały wydają się być 3.3V od szczytu do szczytu, co oznacza, że ​​są prosto z mikro. Jednak poziomy UART mikrokontrolera są (prawie) zawsze bezczynne, wysokie i aktywne niskie. Twoje sygnały są odwrócone od tego, co nie ma sensu.

Aby ostatecznie przenieść te dane do komputera, należy je przekonwertować na poziomy RS-232. Tego właśnie oczekuje port COM komputera. RS-232 jest w stanie bezczynności niskim i aktywnym wysokim, ale niski jest poniżej -5 V, a wysoki powyżej + 5 V. Na szczęście istnieją układy scalone, które ułatwiają konwersję między typowymi sygnałami UART poziomu logiki mikrokontrolera a RS-232. Te układy zawierają pompy ładujące, które wytwarzają napięcia RS-232 z zasilacza 3,3 V. Czasami te układy są ogólnie nazywane „MAX232”, ponieważ był to numer części wczesnego i popularnego układu tego typu. Potrzebujesz innego wariantu, ponieważ najwyraźniej używasz zasilania 3,3 V, a nie 5 V. Wykonujemy produkt, który jest w zasadzie jednym z tych układów na płycie ze złączami. Wejdź na http://www.embedinc.com/products/rslink2 i spójrz na schemat, aby zobaczyć jeden przykład, jak podłączyć taki układ.

Kolejną rzeczą, która się nie sumuje, jest to, że obie sekwencje wydają się mieć więcej niż jeden bajt, nawet jeśli mówisz, że wysyłasz tylko 0 i 255. Ten typ danych szeregowych jest wysyłany z bitem początkowym, a następnie 8 bitami danych, potem bit stopu. Bit startowy ma zawsze przeciwną biegunowość niż poziom biegu jałowego linii. W większości opisów poziom bezczynności linii jest określany jako „spacja”, a przeciwnie jako „znak”. Tak więc bit startowy jest zawsze na znak. Celem bitu początkowego jest zapewnienie synchronizacji czasu dla pozostałych bitów. Ponieważ obie strony wiedzą, ile to trochę czasu, jedynym pytaniem jest, kiedy zaczyna się bajt. Bit startowy zapewnia tę informację. Odbiornik zasadniczo uruchamia zegar na zboczu początkowym bitu startowego i używa go, aby wiedzieć, kiedy nadejdą bity danych.

Bity danych są wysyłane co najmniej do najbardziej znaczącej kolejności, przy czym znak wynosi 1, a spacja wynosi 0. Dodaje się bit stopu na poziomie przestrzeni, dzięki czemu początek następnego bitu początkowego jest nową krawędzią i pozostawia trochę czasu między bajtami. Pozwala to na mały błąd między nadawcą a odbiorcą. Jeśli odbiornik byłby choć trochę wolniejszy od nadawcy, w przeciwnym razie przegapiłby początek następnego bitu startowego. Odbiornik resetuje się i uruchamia swój zegar od nowa za każdym nowym bitem początkowym, aby błędy synchronizacji nie kumulowały się.

Z tego wszystkiego powinieneś zobaczyć, że pierwszy ślad wydaje się wysyłać co najmniej dwa bajty, a ostatni wygląda na może 5.

Pomoże to, jeśli rozszerzysz skalę czasową śladów. W ten sposób możesz zmierzyć, czym naprawdę jest trochę czasu. Pozwoliłoby to zweryfikować, czy naprawdę masz 9600 bodów (104 µs / bit), i umożliwić dekodowanie poszczególnych bitów przechwytywania. W tej chwili nie ma wystarczającej rozdzielczości, aby zobaczyć, gdzie są bity, i dlatego faktycznie dekoduje to, co jest wysyłane.

Dodany:

Właśnie przyszło mi do głowy, że twój system może wysyłać dane w formacie ASCII zamiast binarnym. Tak się zwykle nie dzieje, ponieważ konwersja do ASCII w małym systemie zajmuje więcej ograniczonych zasobów, słabo zużywa przepustowość i konwersję na PC można łatwo wykonać, jeśli chcesz wyświetlić dane użytkownikowi. Jeśli jednak Twoje transmisje są znakami ASCII, które wyjaśniłyby, dlaczego sekwencje mają więcej niż jeden bajt, dlaczego drugi jest dłuższy („255” to więcej znaków niż „0”) i dlaczego oba wydają się kończyć tym samym bajtem. Ostatni bajt jest prawdopodobnie rodzajem znaku końca linii, który zwykle byłby znakiem powrotu karetki lub znakiem nowej linii.

W każdym razie rozszerz skalę czasową, a my możemy dokładnie zdekodować, co jest wysyłane.

Musisz znać wszystkie szczegóły: prędkość, jeśli jest bit startu, liczbę bitów danych, jeśli jest bit stopu i jeśli jest bit parzystości. Powinno to być funkcją konfiguracji UART w mikrokontrolerze.

Jeśli zakres Rigola nie ma opcji szeregowego dekodowania (wiele DSO ma), możesz użyć kursorów X, aby wspomóc dekodowanie. Umieść pierwszy kursor na wiodącej krawędzi danych i przesuń drugi kursor przez strumień bitów. Różnicy między kursorami można użyć do określenia, który „bit” obecnie najeżdżasz myszą za pomocą prostej arytmetyki. Oczywiście zignoruj ​​bity start / stop / parzystość.