[biskup2k]

Uruchomiłem ostatnio także prędkościomierz + zmniejszyłem trochę przeskok obrotomierza przy najwyższych obrotach. To chyba będzie ostatnia aktualizacja projektu, bo podczas gry nawet nie ma czasu spojrzeć na liczniki (teraz doceniam HUD w grze).
#biskupspam (< tutaj postaram się wrzucać podobne projekty) #mikrokontrolery #arduino #elektronika

Chyba mój następny projekt tego typu to będzie odwrócenie tego. Czyli odczyt obrotów i prędkości prawdziwego samochodu na PC albo urządzeniu z adroidem.

Film tutaj (to samo co w załączniku)

Mój poprzedni wątek
Projekt na wskaźnikach użytkownika Marcin648
Projekt wyświetlacza prędkości z gry MrOsamaful

Tutaj jest plansza wyjaśniająca pobieżnie jak to mniej więcej działa (opis tekstowy niżej)
Tutaj pokazane na pseudoscyloskopie (DSO138) sygnał jaki idzie do obrotomierza (stały czas poziomu niskiego gdzie wcześnie był zmienny tak, że wypełnienie było 50%)

Teraz transmituje na przemian raz bajt z danymi o prędkości a później z danymi o obrotach + na start bajt synchronizujący, który przygotowuje uC na odebranie wartości obrotów. Prędkości poniżej 25km/h (około 15mil/h) na liczniku nie udało mi się uzyskać na najwyższym czasie timera przy danym preksalerze. Prędkość 0 po prostu uzyskuje wyłączając sterowanie wyjściem w pętli głównej. Ponadto w RAMie znalazłem tylko dane o prędkości w milach (nawet jeśli mam ustawione km/h w grze).

Oba timery pracują na preskalerze 64 z taktowaniem 1mhz. Obrotomierz mam od 6 cylindrowego silnika, więc obroty w okolicy 800 pokaże, gdy odległość między tymi samymi zboczami sygnału będzie wynosiła 12,5ms a 7000 gdy będzie 1,43ms.
Po włączeniu dowolnych dwóch timerów nawet z włączonym zgłaszaniem przerwania tylko od jednego z nich transmisja przez port szeregowy przestawała działać (używam “gotowca” do hardwarowej obsługi transmisji szeregowej, która też ma z jedno przerwanie). Jeden timer + przerwanie działało w wersji z samym obrotomierzem.
Po szybkich przemyśleniach doszedłem do tego, że ani jedno przerwanie od timera nie jest mi potrzebne. Zostały dwa timery bez przerwania od któregokolwiek z nich.
Obrotomierz dałem na 16 bitowy w jednym z trybów fast PWM. Dlatego że może on sterować bezpośrednio wyjściem PB1 (OC1A). Jeden z 8 bitowych timerów też jest ustawiony bez generowania przerwania a w pętli głównej jest obsługa jego wartości i przełączanie wyjścia na prędkościomierz przy wysyłanej z kompa wartości timera i po zmienie też jest resetowany aby liczył od zera.
16 bitowy się trochę marnuje, bo każę mu liczyć do 255 ale, może w przyszłości wykorzystam jego potencjał pozbędę się tej nieliniowości wskazań obrotomierza zmieniając mu preskaler i dobiorę wyższe wartości timera. A później zrobię “mapę” na tablicy (w uC) aby dopasować 8 bitową liczbę z COMa do wyższych liczb 16bitowego timera.
Timer1 (16 bitowy) dla obrotomierza ustawiony w trybie FAST PWM tak aby na stałe zmieniał wartość przy liczniku (OCR1A) równym 10. Zmieniam za to wartość do której ma liczyć (ICR1). Stan na wyjściu uC jest zmieniany na 1 przy 10 (OCR1A) a zmiana na 0 jest zależna od danych z komputera (ICR1)).

Na początku jeszcze nie mogłem dojść dlaczego czasami po zmianie wartości do której ma liczyć wskazówka opadała. Ale po kilku minutach wpadłem że jak zmienię wartość do której ma liczyć (ICR1) na wartość mniejszą niż przy której jest aktualnie timer (TCNT1) to musi doliczyć do końca 16bitwej liczby (65536). Rozwiązanie to po prostu zapis zmiennej do bufora wartości, która ma zostać przypisana do ICR i dopiero bufora we właściwe miejsce gdy timer jest poniżej tej wartości.

Sprawdzianie wartości timera i przełączanie wyjścia sterującego prędkościomierzem jest w pętli głównej. W pętli głównej poza tym jest tylko algorytm odbioru danych i segregacji na dane o prędkości i obrotach.

Wołam plusujących mój ostatni wpis:

@Agenda @Arthes @Blockbuster @cholinek @Crisss @czlowiek-z-neptuna @daktyr @Djkudlaty @DobryProgramista @elvisiako @Enignum @errorek95 @franek_w @gaily @glupiekonto @GoracyStek @HetmanPolnyKoronny @imarid @Jaro070 @jarpen1234 @Jaszczurovsky @jeloo @JoeBlade @k_gregor @kamilkx @KimmyJimmel @KyloW13 @l0stfake7 @lech_sie_walesa @MacDada @mackar @mafias @Marcin648 @Mazur9 @mich_al @MrOsamaful @Pan_wons @rozklekotany @Stopa_Stefana @sweetaaasnyy @Ugolf @vibro_vagins @WillyHack @ZmutowanaFrytkownica

[Felonious_Gru]

@glupiekonto:
@przegryw69:
@biskup2k: lfs wystawia dane po socketach, jak normalny serwer, wystarczy sie podpiac i czytać (⌐ ͡■ ͜ʖ ͡■)

[biskup2k]

jak się sprawuje ten oscyloskop? Bo wahałem się nad zakupem

@miszczo997: Tak sobie się sprawuje, przełączniki od wyboru pracy (te po lewej) są marnej jakości i trzeba je czasem szturchać aby zaczął cokolwiek czytać.
Do tego typu projektów nawet się sprawdza, bo przy czymś co wytwarza dużo zakłóceń, np. benzynowy silnik samochodowy łapie od cholery zakłóceń.
Sterowanie jest trochę toporne na tych przyciskach. Trochę żałowałem zakupu do momentu aż zacząłem programować