W poprzedniej części udało mi się przechwycić komunikację HD2015 przy pomocy analizatora stanów logicznych Salae, kupionego za 40 zł. Tutaj kontynuuję pracę i spróbuję odwzorować tą komunikację w swoim kodzie napisanym w języku C, dla urozmaicenia użyję tu platformy LN882H. Przy okazji w praktyce porównam obsługę tego kontrolera z kontrolerami takimi jak TM1637, TM1638, itp.
Ten temat stanowi kontynuację wątku:
Analizator stanów logicznych Salae 24MHz za 40 zł - analiza nieznanego protokołu wyświetlacza LED
Tym razem będzie nieco krócej, po prostu zweryfikuję tu, czy dobrze odszyfrowałem protokół...
Na początku był chaos
Tutaj nie ma za bardzo co komentować, ale moja zabawa polega na usuwaniu z takich elektrośmieci tego co zbędne i ożywianiu ich z nowymi mikrokontrolerami, najlepiej WiFi. Jest to lepsze niż wylutowywanie układów scalonych, których potem i tak się często wcale nie używa... no więc najpierw usunąłem z pacjenta to co zbędne:
Na pokładzie zostawiłem zasilacz 5V oraz przetwornicę zapewniającą 3.3V. Złącze SCART potem usunę. LDO od 1.8V usunąłem, bo on jest mi zbędny:
Jako nowe serce wlutowałem moduł WiFi LN882H:
Arkusz danych LN882H, wyprowadzenia, moduły WiFi (LN882HK, LN882HKx, LN882), oprogramowanie sprzętow
Jak sflashować LN882H oprogramowaniem OpenBeken aby uwolnić od chmury
Pierwsza komunikacja
W poprzedniej części zebrałem pakiety odpowiedzialne za wyświetlenie godziny 14 na wyświetlaczu, więc tu po prostu spróbowałem je wysłać. Moduł WiFi LN882H programuję poprzez OTA w OpenBeken a kompilacji dokonuję online na Githubie, bo tak wygodniej.
W OBK mam prosty programowy I2C oparty o metodę bit-bang:
Kod: C / C++
Tu warto nadmienić, że znowu, nie jest to w zasadzie I2C, bo jak się w trakcie analizy protokołu okazało, ten układ nie wspiera adresowania wielu urządzeń na jednej magistrali, tylko od razu pobiera adres komendy (bądź rejestru?) tylko z odpowiednio ustawionym bitem R lub W, ale w zasadzie nic to dla mnie nie zmienia. Wywołując Soft_I2C_Start podaję zatem nie adres samego urządzenia, lecz docelowego rejestru i to bez przesunięcia bitowego.
Wysyłane bajty pochodzą z tematu:
Analizator stanów logicznych Salae 24MHz za 40 zł - analiza nieznanego protokołu wyświetlacza LED
Oto rezultat:
Czyli dobrze przechwyciłem komunikację. Wszystko działa.
Tutaj tylko dodam jedną ważną wskazówkę - przy wysyłaniu warto jest weryfikować analizatorem logicznym czy wysyłamy to co myślimy, że wysyłamy.
Czy to jest jakiś znany protokół?
Kolejnym krokiem było sprawdzenie czy protokół HD2015 jest może zgodny z TM1637 lub TM1638 bądź GN6932 - te wyświetlacze mój projekt już wspiera.
TM1638 i GN6932 wymagają trzech linii, CLK, DAT i STB (które swoją drogą tu niby też jest obecne, ale z niego nie korzystam), opierają się o protokół SPI. TM1637 korzysta z dwóch linii, tak jak HD2015 też nie wspiera adresowania, ale niestety same bajty komend są inne.
Natomiast identyczne okazały się być mapowania bitów na segment, pasuje tutaj moja przygotowana dla TM1637 tablica:
Kod: C / C++
Miałem już się poddać z poszukiwaniami, ale coś mnie tknęło by sprawdzić jeszcze TM1650:
Chwila, przecież adres rejestru cyfr się zgadza - 0x68! Kolejne rejestry też się zgadzają...
A rejestr kontrolny?
0x48, też się zgadza. To chyba to! To nawet lepiej dla mnie...
Wspólny sterownik TM1650/HD2015/TM1637/TM1638/GN6932
Wszystkie te wyświetlacze działają na bardzo podobnej zasadzie. Ich protokoły komunikacji może nieco się różnią, rejestry są inne, ale ogólna idea jest wszędzie taka sama.
Z tego powodu postanowiłem po prostu rozszerzyć sterownik który pisałem poniekąd w tym temacie:
Wyświetlacze 7-segmentowe na TM1637 - 4 i 6 cyfr - Arduino, protokół
Wersję rozszerzoną dla TM1637/TM1638/GN6932 już miałem, teraz przyszła pora dopisać HD2015 (czyli TM1650).
Wystarczy zmienić tylko funkcję wysyłającą segmenty:
Kod: C / C++
Powyższa funkcja to wersja obsługująca TM1637, TM1638 oraz GN6932, w przypadku tych sterowników LED rejestry się zgadzają. HD2015 ma nieco inne rejestry, więc na próbę dopisałem po prostu na niego warunek:
Tego typu wpięcie się z nowym wyświetlaczem w istniejący wcześniej sterownik ma bardzo dużo zalet. Dzięki temu wszystkie pomocnicze funkcje jakie mam (ustawianie znaków na danej pozycji, czyszczenie, miganie tekstem, odliczanie) obsługiwać mogą jednocześnie kilka wyświetlaczy jednocześnie nawet "nie wiedząc" co obsługują.
Kontroler przetestowałem i wszystkie znaki działają:
Przyciski też wstępnie testowałem i odczytywane wartości zmieniają się gdy je wciskam.
Jakby co, mój kod "współdzielonego" sterownika jest tutaj, ale nie nadaje się on na ten moment do publikacji, więc zaglądacie na własną odpowiedzialność:
https://github.com/openshwprojects/OpenBK7231...ob/main/src/driver/drv_tm_gn_display_shared.c
Co dalej?
Kolega z Serbii @DeDaMrAz ma moduł z TM1628:
Niedługo będę sprawdzał, czy jego protokół też jest podobny do tych kontrolerów którymi już się zajmowałem.
Podsumowanie
Przechwytywanie pakietów i analiza pokazała, że HD2015 to jest zasadniczo TM1650. Wygląda na to, że ich protokoły są zgodne.
Dodatkowo szybko się zorientowałem, że sama obsługa HD2015/TM1650 jest bardzo zbliżona do obsługi TM1637 (też sterowany dwoma liniami) oraz do obsługi TM1638/GN6932 (z interfejsem SPI - trzy linie), więc ostatecznie przygotowałem jeden wspólny sterownik który obsługuje te cztery (trzy?) kontrolery wyświetlaczy.
Operację zatem można uznać za udaną. Udało mi się uruchomić wyświetlacz ze starego sprzętu bez wcześniejszej znajomości jego protokołu i wyprowadzeń.
PS: Mając informację, że HD2015 jest "podejrzany" o zgodność z TM1650 udało mi się znaleźć wątek: https://wvclub.net/forum/index.php?topic=3189.0 czyli chyba mój pomysł się potwierdza...
Zapraszam do dyskusji - czy też uruchamialiście jakieś układy bez znajomości ich protokołu komunikacji, poprzez badanie analizatorem logicznym?
Fajne? Ranking DIY Pomogłem? Kup mi kawę.