Początkowo myślałem, że porwałem się z motyką na słońce. Co prawda szukając bardzo długo i bardzo wnikliwie znalazłem jeden temat na rosyjskim forum, gdzie ktoś "wbił" się w ten wyświetlacz, ale niewiele z tego niestety zrozumiałem. Raz, że trochę bariera językowa (znam podstawy rosyjskiego, ale nie korzystałem z tego języka od kilkunastu lat), a dwa, że tamto rozwiązanie wykorzystywało dość skomplikowany układ elektroniczny, a póki co dopiero zaznajamiam się z podstawami elektroniki. Jestem jednak programistą, więc próbowałem zrozumieć działanie tego układu i odwzorować jego zachowanie programowo. Po kilku(nastu?) dniach walki, udało mi się. Kluczem do sukcesu okazało się odpowiednie synchronizowanie zegara wysyłania, tzn. zegary same dają znać, gdy są gotowe na odebranie danych i następuje to w dosyć równych odstępach czasowych. Jest to częstotliwość zbliżona do 10 Hz, ale nie jest to wartość stała. Początkowo próbowałem wysyłać dane na sztywno, co 100 ms. Problem jednak w tym, że nie zawsze zegary były w tym momencie gotowe i dopiero za kilka milisekund chciały dostać dane, a dwa, że Arduino Mega liczy czas dzięki oscylatorowi o częstotliwości 12 MHz - co nie daje równych wartości w przełożeniu na czas. W obu przypadkach rozsynchronizowanie powodowało, że komunikaty przestawały pojawiać się na zegarach i zamiast świecić na stałe, efekt był taki:
Na szczęście udało mi się obejść ten problem. Do synchronizowania urządzeń zegary mają dedykowany przewód. Problem w tym, że komunikacja po nim leci w każdą stronę. Na szczęście w Arduino można dynamicznie zmieniać tryb pinu (input/output), więc mogłem nasłuchiwać, kiedy zegary oczekują danych, a także dawać znać na tej samej linii, że dane będą wysłane. Po takim sukcesie zabrałem się za budowanie dedykowanego urządzenia.
W międzyczasie okazało się, że istnieje dla Arduino biblioteka dekodująca strumień danych z EMU - ale tylko korzystając z protokołu Ecumaster Serial Protocol. Jeśli jednak ktoś - jak na przykład Kamil - ma podłączone do EMU jakieś akcesoria, np. Data Logger EDL-1, musi mieć tryb portu seryjnego odpowiednio przestawiony. W takiej sytuacji strumień danych jest już zupełnie inny. Postanowiłem więc wbudować w urządzenie obsługę szyny CAN i wykorzystać ją do komunikacji. Niestety póki co nie mam jak potestować i przede wszystkim rozkodować sobie dane idące po szynie CAN, więc w praktyce nie mogę zaprogramować tej obsługi i muszę poczekać na odbiór auta z MGarage, który nastąpi... no właśnie, nie wiadomo. Pierwsza wersja mówiłą o styczniu/lutym 2020 a ostatnia o grudniu 2020, jednak auto nadal nie jest poskładane...
Jednak wracając do tematu - prototyp numer 1 wyszedł na tyle dobrze, że zostawiam go dla siebie, choć - jak to prototyp - początkowo miał po testach zostać rozebrany lub przebudowany. Problemy na które się natknąłem, to jednak tylko nie do końca logiczne rozmieszczenie elementów i krzyżujące się i "latające" kable. Największym minusem było wycentrowanie konwertera TTL-RS232, przez co nie miałem go jak przykręcić do dołu obudowy i musiałem zastosować patent w postaci podwyższenia zrobionego z małej obudowy do Arduino Mega.
Potem zabrałem się za budowę drugiego prototypu (pewnie nigdy nie wyjdę z fazy prototypu, bo ilę tego mogę zbudować - maksymalnie 5 urządzeń? W końcu ile ludzi ma EMU W E34), tym razem dla pomysłodawcy, czyli Kamila. Drugi prototyp budowałem już biorąc pod uwagę to, co skopałem za pierwszym razem, mamy więc lepsze rozmieszczenie elementów i ułożenie przewodów. Obudowa ma też nóżki na dole, czyli tam gdzie powinna mieć, bo u siebie... pomyliłem połówki obudowy. Ale to nieistotne, bo mam pomysł jak to zamocować w tej odwrotnej konfiguracji. Poniżej porównanie, mój prototyp numer 1 i "dwójka" dla Kamila.
A tutaj jeszcze filmik z krótkiej prezentacji działania, nagrywane przy pomocy mojego prototypu.
Brak komentarzy:
Prześlij komentarz
Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.