monitor/debugger/sniffer rs232

Dec 07, 2007 26 Replies

Mam urządzenie które komunikuje się z drugim na rs232. Chciałbym przechwycić transmisję, a dokładnie rozszyfrować protokół. Prędkość i parametry transmisji znam, ale chodzi o rozgryzienie zależności czasowych - jak na jakie sekwencje urządzenie odpowiada, itp.



Podłączyłem się "równolegle" moim komputerem z rs (tzn linia RxD mojego komputera do np RxD>TxD w urządzeniu) i widzę transmisję idącą w jedną stronę. Przepinam się na drugą linię (TxD>RxD) i widzę odpowiedzi. Ale nie mam nijak zachowanej chronologii co jest odpowiedzią na co...



Próbowałem takim fajnym darmowym programikiem pt. terminal.exe (można włączyć dodawanie "timestampt") ale dodaje z dokładnością do 1sekundy, a transmisji jest dużo i szybkiej, mam kilka-kilkanaście wierszy/znaków z tym samym czasem nadania/odebrania...



Idealnym rozwiązaniem byłby program który umie otworzyć sobie 2 lub więcej portów RS232/COM (mam kartę 8port rs232 na pci, oraz 2comy na płycie, już o comach na usb nie wspomnę), i zrzucać taką transmisję z kilku RxD "wielokanałowo" lub przynajmniej znakując kolorem skąd co przyszło, efekt byłby conajmniej taki "czatowy": pytanie=odpowiedz w okienku obok tuż zaraz po pytaniu itp...



Może ktoś zna taki program? Lub chciałby napisać (również za $)


BartekK pisze:

(...)

formatting link
Jest pod DOS-a, ale dzięki temu są zachowane dokładne czasy. Program używa dwóch portów RS. Jest dosyć toporny ale działa chyba najlepiej ze wszystkich.

Maksymilian Dutka pisze:

Fajnie, tylko że tylko COM1 i COM2 po portach niskich... A ja mam COM1 na płycie real-hardware-0x378, com2 juz na pci, i 8 portów na karcie Moxa... Pozatym - skąd ja teraz dosa wezme ;) Moze ruszy pod jakims freedosem?

Jak nic innego sie nie znajdzie to postawie osobnego compaqa p2-350 do tego softu, ale to troche przerost formy ;) Zwłaszcza późniejsze przerzucanie wyników...

A. Grodecki pisze:

Zapewne masz rację. Ale w tym urządzeniu jest windows ;) Mi nie chodzi nawet o to czy jest wysylane "DA", 18.2ms przerwy, odpowiedz "ACK" i 245ms przerwy, mi chodzi o to "co leci po kolei w którą stronę" - przerwy/odstępy między transmisjami to sobie na oscyloskopie cyfrowym ładnie obejrzę, ale dekodować bajt po bajcie z ekranu - to mi się nie chce ;)

BartekK napisał(a):

W "systemie okienkowym" nie dostaniesz dokładnych czasów między fragmentami transmisji. Tak samo aplikacją chodzącą pod windowsem nie bedziesz w stanie kontrolować dokładnie czasów wysyłania i odbioru. To nie jest system do przemysłowego zarzadzania hardware. Systemy sterowania bardzo czesto muszą mieć specjalne konwertery do PC-ta, żeby pecet był w stanie gadac z systemem. Ma to miejsce wtedy gdy relacje czasowe sa ostre. Windows nie ma wtedy szans.

BartekK pisze:

Niestety...

(...)

Sprawdzałem tylko na dos-ie z Win95 i Win98.

Przypomnisz sobie co to dyskietka ;) Mozę znajdziesz coś lepszego to chętnie bym też skorzystał, ja te co testowałem to albo nie pokazywały czasów, albo działały na zasadzie monitorowania jednego portu w komputerze.

Znalazłem właśnie coś takiego:

formatting link
Jeszcze tego nie testowałem.

Maksymilian Dutka pisze:

Niestety, praca na 2 portach jest możliwa tylko w Serial Monitor (DMS) Pro za 84.99$ (albo 33.99$ na 3miesiące). Jeśli mam tyle zapłacić - wolałbym dać tą kasę "naszym" i niech powstanie jakiś program GNU. Ale nie wierzę że już nie istnieje, przecież nie ja pierwszy mam taki problem/potrzebę, a nie kazdy ma megaanalizator cyfrowy z debugerem transmisji szeregowych...

BartekK napisał(a):

Prędkość transmisji też nie musi być standardowa i CZĘSTO NIE JEST. Do tego dochodzi kodowanie znaków (czasem jest) i sumy kontrolne posługujące się mechanizmem, którego nie rozwikłasz zanim osiwiejesz. Powodzenia :)))

A. Grodecki pisze:

Ale w tym przypadku jest wszystko standartowe. 19200/n/8/1 i sterowanie czystym tekstem/ascii (tzn ACK to przeslanie znakow "A","C","K") i wszystko widze jak na dloni w pojedyńczym terminalu oglądając transmisję w jedną stronę. Komendy "proste" typu "zresetuj się" udaje mi się zasymulować moim hardware, ale komendy bardziej złożone niestety nie, gdzie idzie (prawdopodobnie z tego co podejrzałem) komenda, ack, parametry, zwrotne parametry + ack, ack z mastera i czasem jeszcze cos, i tak w kolko az dojdzie do konca danej sekwencji... Dwa terminale otwarte w 2 okienkach na 2 portach działają bardzo fajnie, ale nie mam możliwości zobaczyć co jest odpowiedzią na co... za szybko to leci

poszukaj sysinternals portmonitor, ma wszystko czego potrzebujesz

groszek pisze:

Tak? A od kiedy obsługuje RS232?

Dariusz Żołna

W pracy (wiêkszo¶æ czasu ¶lêczê nad RS-232) u¿ywam tego urz±dzenia:

formatting link
programik napisany przez kolegê z pracy do takich w³a¶nie celów:
formatting link

Pod Windows, tak, jak p. Andrzej napisa³ nie masz zbyt dok³adnego pomiaru czasu z powodu wielow±tkowo¶ci. Jesli chodzi o czysto softwareowe rozwi±zania, to bawi³em siê kiedy¶ portmonitorem Sysinternals-a. Wyda³ siê niez³y, ale siê nie zag³êbia³em.

LukaszS pisze:

ver1.0 Ledy 2kolorowe 2nóżkowe (zielone/czerwone zależnie od polaryzacji) z opornikiem ~1k do każdej z linii portu - widać stan, brak podłączenia danego sygnalu itp. Wszystko mieści się w przejściówce DB9m-DB9f 1=1 więc można podłączyć praktycznie wszędzie jako przelotka

ver2.0 większa obudowa, ledy niebieskie osobno na stan 0 (+5 do +12v) i

1 (-5 do -12v), bo pojedyńcze peaki/bity/bajty ciężko było zobaczyć na jednym ledzie (nie było widać szybkiej zmiany koloru). połączenie 220ohm
  • 1kohm (i równolegle do niego kondensator 470nF smd) - stan stabilny daje słabe świecenie leda, szybkie impulsy dają niezłe blyski.

ver3.0 najmądrzejsza, bo z prockiem, który mierzy najmniejszą szerokość stanu 0 i/lub 1 na liniach RxD i Txd, czyli szerokość 1 bitu, z czego oblicza prędkość transmisji (przy ustawieniu ilości bitów stopu/startu/parzystosci i bitów w bajcie, ale zawsze lepsze to niż nic nie wiedzieć lub sledzić z oscyloskopem), w dodatku obserwuje linie cts/rts dsr/dtr i wyswietla czy zmiany rxd/txd zaleza od stanu tych linii (czy jest sprzetowa kontrola przeplywu). Niestety ciągle nie mam czasu skończyć softu, na razie faza alfa ;)

Jako pojedynczy terminal - proste a skuteczne, aczkolwiek ja używam " terminal v1.9b by Br@y++ " - obsługuje com1-7, custom baudrate, troszke więcej konfiguracji

formatting link

Ja by³em za leniwy :)

Fajny, fajny. Widaæ stan sygna³ów, ale jak w nim wysy³aæ ci±g bajtów, a nie znaków? Chodzi mi o co¶ takiego, jak w moim: \1B\FF\Dupa wolowa\0D Je¶li siê da, to ciekawa alternatywa do mojego.

Natomiast je¶li chodzi o podgl±danie tego, co wys³ae i odebrane, to chodzi mi po g³owie taka przeróbka, ¿eby w zale¿no¶ci od tego, czy jest to bajt wysy³any, czy odbierany odpowiednio ustawiaæ jaki¶ rzadki sygna³ (np. RI). Odpowiednia przeróbka aplikacji i wówczas mo¿na by³oby rozdzieliæ wizualnie to co wys³ane od tego, co odebrane. Choæby zaznaczaj±c innym kolorem.

LukaszS pisze:

W nim sie wysyla takie rzeczy jako $1B$FF ;)

A co gdy sygnaly na RxD i Txd lecą równocześnie? Nikt nie mówi, że nie może być duplexu...

Nie wiem, czy siê dobrze wyrazi³em: VK-24 wpina siê jako przej¶ciówkê (pomiêdzy np. COM1 a drukarkê), a opcjonalnie do urz±dzenia podpina siê trzeci kabelek podpiêty do np. COM2. Na VK24 s± dwa prze³±czniki w³±czaj±ce ¶ledzenie pakietów wysy³anych i odbieranych. Jednak, jak masz oba w³±czone, to na COM2 nie widzisz, co sz³o w jedn± stronê, a co w drug±. St±d pomys³ z RI.

W ComTe¶cie mo¿esz sobie wpisaæ dowolny COM. Combo, to tylko przykrywka dla niepoznaki :)

Ty¿ prowda. Choæ dla moich potrzeb mogê za³o¿yæ, ¿e dupleks nie wystepuje.

LukaszS pisze:

Po nazwie firmy wnioskuję że ja siedzę nad tym samym tylko po drugiej stronie :D

Ja używam tego pod DOS-a.

Po drugiej stronie kabla RS-232, czy ³añcucha pokarmowego przez pokrewieñstwo z zarz±dem? :D

LukaszS pisze:

Po drugiej stronie kabla ;)

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required