Dla uważnych czytelników poprzedniego wpisu należą się przeprosiny i wyjaśnienia. Napisałem w nim, że pokaże dwa sposoby zobrazowania jak wygląda protokół naszej płytki a przedstawiłem tylko jeden – analiza w IDA. Nie wiem czy to z pośpiechu czy jakiś inny czynnik na to wpłynął, ale o tym drugim – po prostu zapomniałem. Teraz zatem, bijąc się w pierś, omówienie drugiej metody.
Jak wspomniałem w tymże wpisie – istnieją aplikacje, które pozwalają nasłuchiwać i wyświetlić nam całą komunikację z wybranym portem COM. Jest kilka darmowych, kilka płatnych – na pewno każdy wybierze coś dla siebie.
Ja użyłem Serial Port Monitor’a od Elitma Software, ale jako, że był to trial i już wygasł to nie pokażę, jak to w nim wyglądało. Zamiast tego użyję darmowego Serial Port Monitora (wow, jaka różnorodność nazw :]) od firmy HHD Software.

Po zainstalowaniu i uruchomieniu mamy możliwość wyboru trzech z rodzajów monitoringu, ale w wersji bezpłatnej dostępny jest tylko Serial Port Monitor i ten zaznaczamy.

Następny krok to wybór numeru portu, na którym będziemy nasłuchiwać a na sam koniec zostanie wybór sposobu prezentacji danych. Wydaje mi się, że najprzydatniejszym jest połączenie widoku tabelarycznego z Request View. Ten pierwszy pokaże nam wszelkie komunikaty IOCTL a drugi na wyższym poziomie pokaże jakie bajty został wysłane. Mając tak przygotowaną aplikację wysyłamy przez naszą wzorcową aplikację jakiś łańcuch znaków do płytki i obserwujemy wynik.

Dzieje się sporo – to widać. Szczególnie na widoki Table View przelatuje sporo komunikatów IOCTL nawet jak weźmiemy tylko te z kierunkiem DOWN (UP to potwierdzenie odebrania – ktoś zna się bardziej na tym?) to trochę tego zostanie.
Na drugim widoku jednak mamy bajty, które zostały wysłane i na nich możemy się skupić, aby przeanalizować transmisję i spróbować dopasować do tego co dowiedzieliśmy się poprzednim razem.

Widzimy wyraźnie, że na początku wysyłany jest bajt 0 (reset?). A następnie zaczynają się dane właściwe – podział na 4 pakiety jest wyraźnie widoczny jako, że wszystkie zaczynają się tą samą sekwencją: 02 31 06 a następnie podane jest przesunięcie (można to traktować jako nr pakietu << 6) czyli będzie to wartość 00, 40, 80, C0. Dalej już są różnice – w pierwszym pakiecie przesyłamy informacje o użytym efekcie oraz prędkości. Dalej pozostają nam już tylko dane + suma kontrolka widoczna na samym końcu każdego pakietu. Na sam koniec transmisji “stopka” i gotowe.

Czy to bardziej intuicyjne niż IDA? Pewnie tak – nie wymaga znajomości assemblera i pozwala w wizualny sposób zorientować się jaka komunikacja jest przeprowadzana z urządzeniem. Czy można by tylko na tej podstawie poznać protokół? Raczej nie – nie wiem czy można domyślić się, że 1A to suma kontrolna pierwszego pakietu a 77 drugiego. Co obrazują te 3 bajty na końcu?
Być może dla osób z jakimś doświadczeniem będzie to oczywiste – będą one wiedzieć co w takim protokole powinno być i doszukają się w tych danych odpowiedniego znaczenia.
Na pewno dobrym rozwiązaniem jest narzędzie + IDA. Tyle w kwestii wyjaśnień.