No właśnie, ja używam atmegi więc inne poziomy napięć. U mnie licznik reaguje na przesył danych, ale nie tak jakbym chciał. Dzisiaj może do tego usiądę i podumam co skopałem.

W sumie to nie wiem czy dobrze zrozumiałem sposób zapisywania danych do tablicy (BASIC nie jest moją mocną stroną) i może to jest problemem. Wklej jak możesz swój kod, wgram na atmegę i sprawdzimy czy działa.

Nie ma mnie w miescie i nie mam dostepu do kompa, ale na svrider.com na 3 stronie watku od teeriver'a jest kod w C innego goscia, troche dziwny ale na nim bazowalem.

Edit:
Dobra, dorwałem Atmege 16 w końcu więc dziś powalczę z tym licznikiem jeśli sobie przypomnę jak się w ogóle programuje te Atmegi

A ja ujebałem programator... przez przypadek zrobiłem zwarcie na płytce testowej i po zabawie. Chyba będę musiał lecieć po nowy.

edit: okazało się, że jedynie porty USB w laptopie się wyłączyły od przeciążenia. Po resecie wszystko działa

VOILA! Udało się, jest i temperaturka Licznik jest z angola i dlatego w fahrenheitach. Prędkościomierz i licznik kilometrów można przestawić z mil na kilometry, ale temperatury już nie W sumie bez problemu można wyświetlać w stopniach celsjusza, tylko ikonka fahrenheita pozostanie, także to żaden problem.

Jaka synchronizacja - ja też 10 min temu odpalilem to na Atmega16:

A co do przeróbki z F na C to z tego co zrozumiałem to nie będzie tak łatwo bo mapa temperatur jest w liczniku i najniższą temperaturą w licznikach z opcją w F jest 68 stopni. Potem wyświetlana jest kreska. Natomiast w licznikach Celcjuszowych najniższą temperaturą jest 20*C.
Ale jeszcze się pobawię dziś i zobaczymy co z tego będzie...

Następny krok to obsługa danych lecących z licznika w jakimś przerwaniu + dodanie woltomierza jako czujnika biegu i gitara.

Edit:
I tak jak pisałem, widocznie nasz licznik gada na poziomie logicznym 5V dlatego nie ma sensu dawać procków 3V...

To fakt, przy fahrenheitach minimalna temperatura to 68 stopni, więc nie ma sensu się bawić w żadne przeliczenia. Zostanie Fahrenheit i tyle

Idę w kimę, bo rano do roboty!

Dla ewentualnych zainteresowanych to w necie natknąłem się na projekt "ręcznej roboty" wyświetlacza do SV1000 >>klik<<. Bazuje on na tej samej technice z tym że o wiele bardziej zaawansowanej. Są tam moduły do dekodowania większości info z ECU i wyświetlania ich dalej. Może się przydać.

Miles! Gratki!!!
Pamiętasz o mnie?

Pamiętam, pamiętam

Wczoraj przeanalizowałem wszystkie możliwości ustawień bitów w bajtach odpowiedzialnych za temperaturę i niestety nie ma fizycznej możliwości żeby wyświetlać coś na 4-tej cyfrze, edytując tylko data stream.
Napisałem w związku z tym do Dave'a i tak jak podejrzewałem zrobił on inny myk polegający na reverse engineering komunikacji między prockiem licznika, a samym wyświetlaczem LCD...
Jednocześnie przeprosił za zwłokę ale podobno już jest na finiszu przy ogarnianiu wszystkich materiałów odnośnie tego wynalazku i za jakiś czas wszystko udostępni. Podesłał mi trochę z tych materiałów i wygląda to ciekawie. Tak więc trzeba czekać jeszcze chwile, a potem wszelkie przeliczenia prędkości, obrotów, temp (włącznie z pełną zmianą z F na C wraz ze znaczkiem) będą możliwe i prawie nie inwazyjne.

Kombinuj. Ja większość czasu w pracy spędzam i nie mogę zarywać nocek na własne projekty. Od czasu do czasu tylko usiądę i coś tam pogrzebię.
Ah... gdzie te studenckie czasy.

Znam ten ból... Na szczęście jak w pracy w wolnych chwilach naklepie trochę prywatnego kodu to nikt sie nie zorientuje

Jako, że niestety TeeRiver jeszcze nie udostępnił swojego sposobu na przejęcie kontroli nad oryginalnym wyświetlaczem rozpocząłem reverse engineering jego reverse engineering'u
Dziś spróbuję nabazgrać jakiś testowy kod i zobaczymy czy coś zabangla Póki co udało mi się popodglądać ramki lecące do wyświetlacza na moim turbo amatorskim oscyloskopie.
Jeśli ktoś chce równolegle popróbować tej sztuczki u siebie to chętnie udostępnię wszystko do czego doszedłem.

Wygląda na to, że licznik na jednej linii daje zegar o dziwnym przebiegu: 16 pików co 5us, przerwa 10us, znów 16 pików co 5us, przerwa 10us, 10 pików co 5us, przerwa 10us, jedn pik, przerwa 10us, i jeszcze raz to samo. W tym loopie na drugiej linii wysyłane są 84 bity zapalające poszczególne segmenty na wyświetlaczu. Gdy bit danych jest na 1 podczas danego piku na linii zegara oznacza zapalenie segmentu.
Teraz będę próbował napisać obsługę przerwań żeby przechwytywać dane z licznika (linia danych), oraz osobne przerwanie dla linii zegara. Wtedy spróbuję w locie podmieniać bity lini danych i tak sterować wyświetlaczem.

mozolna robota...ale jak się uda będzie hicior 3mam kciuki

Dzięki, mam nadzieję, że się uda Za tydzień kończę sezon więc licznik będę miał już bez stresu w domu to wtedy zacznę działać pełną parą
Póki co:
Nie za bardzo się udało czytać zegara w przerwaniu i w locie edytować zapalanie segmentów. Czas między przerwaniami to ok. 6-7 us, a niestety sam przeskok do przerwania zajmuje 3us nie mówiąc już o zliczaniu impulsów, porównywaniu z tablicą i wysterowywaniu wyjścia... Aktualny plan jest taki, że zamiast podpinać się pod istniejący sygnał zegarowy również tą ścieżkę rozdzielę i będę przechwytywał całą transmisję z proca, edytował i ponownie generował zarówno zegar jak i linię danych, okienko między odświeżeniami wyświetlacza to 50 ms co jest już wystarczającym czasem na wszystkie operacje.
Chyba, że ktoś ma jeszcze jakieś propozycje

FPGA

Haha, też już to rozważałem

Zastanawiam się czy gdybym miał wtryskową to chciało by mi się z tym bawić

Ja tak sam z siebie lubię grzebać w takich rzeczach