Forum Miłośników Symulatorów Lotniczych
Zaplecze => Software & Hardware => Sprzęt wykonany samodzielnie => Wątek zaczęty przez: vito_zm w Lipca 07, 2016, 06:11:23
-
Zastanawiałem się dosyć długo, czy rozpocząć ten wątek. W końcu doszedłem do wniosku, że może komuś się przydadzą moje doświadczenia w tym temacie tym bardziej, że aktualnie walczę z problemami związanymi z MMJoy2 oraz ProMicro.
Zauważyłem, że coraz więcej kolegów na forum stosuje w swoich kokpitach kontrolery Arduino. Postanowiłem ten temat rozeznać i od jakiegoś czasu tym się zajmuję. Może w tym wątku będzie można wymienić swoje doświadczenia związane z Arduino. Na początek chciałbym przedstawić swoje przemyślenia i doświadczenia. Temat jest obszerny, dlatego przedstawię go w kilku post. Jednocześnie chciałbym porównać kontrolery, które mam u siebie w kokpicie z Arduino.
Jeszcze jedna ogólna uwaga. Każdy kto rozpoczyna przygodę z budową kokpitu ma dylemat jakie zastosować kontrolery wystarczy wspomnieć drejku oraz macieja z forum. Każdy musi dokonać wyboru i liczyć się z jego konsekwencjami. Myślę, że tyle wstępu wystarczy.
Powstawały w ciągu ostatnich lat nowe kontrolery podobnie jak rozwijały się symulatory. W moim przypadku od MJoy16 poprzez urządzenia OpenCockpits, DMKeys8, SimOUT do Arduino. Podobnie z symulatorem do Falcona, który przebył długą drogę i obecnie jest nazwany BMS4.
Kilka uwag o moich kontrolerach. DMKeys8 jest bardzo dobrym kontrolerem. Jego główną zaletą to przyjazny program do konfiguracji. Jest widziany przez pc jako wyspecjalizowana klawiatura. Na stronie Damosa jest jego opis. Kontrolery codeking SimOUT oraz SimIN wymagają platformy programowej HSC. W mojej opinii jest to bardzo dobra i uniwersalna platforma w której można konfigurować prawie wszystko potrzebne w kokpicie. Codeking stosuje w swoich skryptach swój "język", który jest opisany na jego stronie. Podobnie urządzenia OpenCockpits wymagają programowej platformy SIOC oraz w przypadku Falcona dodatkowo FAST. Są też dostępne urządzenia z platformami dla BMS4, ale są dosyć drogie. Ich zaleta to proste uruchamianie w kokpicie.
Czas na właściwy temat czyli Arduino. Na jego temat napisano dużo książek. Jest też bardzo dużo informacji w Internecie. Najważniejsza zaleta to niska cena oraz dostępność w sieci aplikacji dla różnych zastosowań. Na początek jest problem jak się za to zabrać. Są możliwe dwa podejścia. Pierwsze to poszukanie gotowej aplikacji dla konkretnego zastosowania. Jako przykład podam program nazwany MMJoy2, który wystarczy wgrać do jednego z wymienionych kontrolerów Arduino. Następnie zrobić konfigurację i zastosować w swoim joysticku. Jest to bardzo przydatny program w przypadku budowy swojego joysticka lub gdy uszkodzi się np. kontroler w Cougar i trzeba go czymś zastąpić.
Drugie podejście to napisać samemu skrypt dla swojego projektu np. robota. Tutaj trzeba trochę poznać Arduino tzn. język. Ja rozpocząłem swoją zabawę od poznania Arduino i próby napisania kilku przykładów oraz ich sprawdzenia. Pomocą była książka Beginning Arduino.
Postaram się podać na początek kilka przykładów, które mogą być przydatne w projektowaniu samemu jakiegoś wskaźnika w kokpicie. Następnie omówię MMJoy2, ponieważ go właśnie uruchamiam.
Na koniec bardzo istotna informacja dla zastosowania Arduino w kokpicie dla konkretnego symulatora tzn. komunikacja. DCS komunikuje się z elektroniką poprzez soft DCS-BIOS. W BMS4 jeszcze nie wiem jak to zrobić. Są już gotowe aplikacje dla np. DED na graficznym module 256x64. To jest temat do przemyślenia.
Tyle mojego wstępu. Mam nadzieję, że koledzy dołącza do tego wątku z swoimi doświadczeniami. Na koniec zdjęcie z moimi kontrolerami UNO oraz ProMicro.
(http://i700.photobucket.com/albums/ww5/vito_zm/Arduino%20UNO-Micro.jpg) (http://s700.photobucket.com/user/vito_zm/media/Arduino%20UNO-Micro.jpg.html)
-
Dla poznania Arduino kupiłem zestaw na bazie UNO. W zestawie są różne elementy elektroniczne, które można połączyć kabelkami z UNO. Dla majsterkowiczów jest to dobre narzędzie do nauki. Mnie bardziej interesowały takie elementy jak wyświetlacze 7segLED, wyświetlacze znakowe LCD, matryce diodowe, rejestry oraz bardziej złożone układy. Zrobiłem dla testowania tych układów swoje płytki testowe aby uniknąć bałaganu przy połączeniach kabelkami na matrycy połączeniowej. Co wynika z tych prostych testów dla mnie zajmującego się tzw. hardware. Stosowanie kontrolerów Arduino upraszcza projektowanie elektroniki. Jako przykład można podać sterowanie rejestrów szeregowo-równoległych lub równoległo-szeregowych. W klasycznych rozwiązaniach trzeba zbudować jakiś prosty generator zegara taktującego dalej sygnał taktujący, sterowanie rejestrów oraz sygnał zapisu. W Arduino jest to zrobione w tzw. bibliotekach i wystarczy wywołać odpowiednią funkcję z parametrami i to wszystko. Można także stosować zamiast prostych rejestrów np. 74HC595 bardziej rozbudowane MAX 7219. Dla wspomnianych układów są biblioteki i wystarczy poszukać w Internecie przykłady jak je stosować. Zastosowałem u siebie dla testów zarówno 74HC595 jak i MAX 7219 i doszedłem do wniosku, że łatwiej programować MAX 7219, ponieważ funkcje w bibliotece dla tego układu są bardzo dobrze zrobione.
Zakończyłem moją skromną edukację na projekcie testera do sprawdzania działania drążka w moim Cougarze. Drążek komunikuje się z kontrolerem Cougara 3 sygnałami plus zasilanie. Zrobiłem emulator drążka na 3 płytkach (na zdjęciu). Na jednej płytce są 3 rejestry CD 4021 takie same jak w drążku tylko w wersji przewlekanej. Na pozostałych dwóch są przyciski a raczej na jednej jest komplet 8 przycisków a na pozostałych możliwość ustawienia 0 lub 1 na wybranych pozycjach (nie było potrzeby dla testu programu budowy 24 przycisków). Gdy testujemy drążek to podłączamy 5 przewodów do gniazda i to wszystko. Wynik testu jest w dwóch postaciach. Możemy podłączyć drążek do układu, który zaprojektowałem na matrycy diodowej 8x8 LED (taka była w zestawie). Pierwsze 3 rzędy diod wyświetlają stan przycisków w drążku. Drugi sposób jest prosty, ponieważ Arduino ma możliwość monitoringu co jest pokazane na zdjęciu. Stany 3 rejestrów są ciągle wyświetlane na monitorze po w postaci binarnej oraz dziesiętnej.
Na tym kończę moją przygodę z programowaniem UNO. Teraz czas na ProMicro oraz MMJoy2.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_tester-7219.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_tester-7219.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/m_tester%20drka%20Cougara.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_tester%20drka%20Cougara.jpg.html)
-
Dodam swoje trzy grosze. :) Tak jak pisze Vito Arduino jest ogólnie dostępne oraz jest do niego mnóstwo przykładów w siedzi. W chwili obecnej wykorzystuje dwa zewstawy Arduino micro - jeden służy jako sterownik do silnika krokowego, drugi jako joystick do obsługi przycisków z Cougara. Korzystam z biblioteki podanej w linku :https://github.com/MHeironimus/ArduinoJoystickLibrary (https://github.com/MHeironimus/ArduinoJoystickLibrary) Ograniczeniem tej biblioteki są 3 joysticki, ale do obsługi samego Cougara wystarcza. Micro posiada obsługę SPI i I2C. Bardzo ciekawe jest samo I2C do którego potrzeba jedynie 4 kabelków - VCC, GND, SCL i SDA. Mój układ który przedstawiałem w wątku budowy symulatora oparłem na dwóch układach 16 kanałowych MCP23017.
-
No i vito zacząłeś temat rzekę :P
Ja wypowiem się odnośnie samego mmjoy2 (link do repozytorim na githubie (https://github.com/MMjoy/mmjoy_en/wiki)) - opartego w moim przypadku na klonie Arduino (Sparkfun)ProMicro (Atmega32u4 16MHz 5V) - vito zakupił taki sam IMHO dobry wybór cena/możliwości.
Sama płytka droga nie jest, z wysyłką śmiało mieścimy się w kwocie 30zł zamawiając na alledrogo :)
(https://raw.githubusercontent.com/MMjoy/mmjoy_en/master/img/Board%20pinouts/Pins_Sparkfun%5Bpromicro%5D.png)
ProMicro z Sparkfun - na alledrogo jako ProMicro - zazwyczaj niebieski laminat - rozłożenie i funkcje takie same.
Jako że procesor ATmega32u4 (http://www.atmel.com/devices/atmega32u4.aspx) z zasilaniem 5V i kwarcem 16MHz ma natywną obsługę HID może być widziany jako mysz/klawiatura lub właśnie joystick - mmjoy2 działa ww oparciu o tę możliwość - system widzi go jako joy. Obecnie na stronie repo projektu widać obsługiwane uC (at90usb646, at90usb1286, ATmega32u4), w naszym kraju najbardziej dostępne są 'gotowe' płytki z ostatnim układem.
Możliwości konfiguracyjne są naprawdę duże patrząc na cenę - maksymalnie możemy podpiąć 10 osi (natywna rozdzielczość ADC uC to 10bit) oraz 96 przycisków choć nic nie ogranicza nas w dół - jak ktoś potrzebuje, może zrobić 2 przyciskowy joystick bez osi lub podpiąć same osie :)
Dodatkową zaletą mmjoy2 jest jego 'modułowość' oraz zapis ustawień w pamięci EEPROM mikro kontrolera - nic nie stoi na przeszkodzie aby przygotować kilka profili zapisanych na dysku pod konkretne moduły i w razie konieczności przepiąć je i wgrać odpowiednie ustawienia np. joystick + przepustnica + pedały do FSXa, zmieniamy zabawę na Mi8 DCS? przepinamy inną przepustnicę dodatkowe panele wgrywamy profil na urządzenie i gotowe (przynajmniej w teorii bo przepinanie chwilę zajmie ale jest jak najbardziej wykonalne ;).
Mmjoy2 obsługuje zarówno potencjometry jak i czujniki halla oraz przetworniki analogowo-cyfrowe (ADC) jedno lub wielokanałowe (MCP3201, MCP3201, MCP3204s/MCP3208s, MCP3204d/MCP3208d, KMZ60+MCP3202, KMZ60+MCP3208s, TLE5010/5011, S/C-TLE5010/5011), w przypadku klawiszy/przełączników można zastosować matrycę klawiszy lub rejestry przesuwne 74HC165 lub 4021 działające w oparciu o szeregowy interfejs SPI (max 12 sztuk układów co daje 8*12 = 96 przycisków), enkodery także możemy podpinać. Ustawienia klawiszy mają rozbudowane opcje konfiguracyjne - możemy je przypisać jako przyciski/przełączniki joy'a lub klawiatury z dodatkowymi modyfikatorami.
Samo wgranie oprogramowania także nie powinno być problematyczne - w programie ustawiamy port pod którym system widzi arduino w trybie bootloadera, wybieramy odpowiednio schemat uC, sam chip uC, typ bootloadera i opcję auto startu wgrania firmware'u gdy port będzie aktywny - wtedy zostaje tylko zresetować układ (linia RST+GND zwarta na chwilę) i soft automatycznie wgra się do uC. Potem zostaje już tylko zabawa z peryferiami i ustawieniem pod siebie :)
-
Cieszę się, że koledzy zareagowali na ten temat. Może będzie szansa na jego rozwój i wymianę doświadczeń.
Próbowałem na początek zrobić samemu kontroler, który byłby widziany przez pc jako urządzenie HID, ale zabrakło wiedzy jak to zrobić. Zrobił to maciej. Dodatkowo mój UNO nie był najlepszy do tego celu. Leonardo lub Micro mają wbudowany mechanizm w uP, który ułatwia komunikację z pc jako HID. Tak się szczęśliwie złożyło, że kolega golas z forum także aktualnie stosuje Arduino Pro-Micro w swoim kokpicie, dlatego zakupiłem ten kontroler i będę go testował w aplikacji MMJoy2. Ponieważ układ jest bardzo mały i niewygodny dla testów zrobiłem dla niego na płycie uniwersalnej platformę do podłączania urządzeń zewnętrznych. Na początek będzie to matryca 4x3, później rejestry 3x CD 4021 itd. Ponieważ jest dokumentacja w postaci schematu ideowego oraz opis mojego klonu to postanowiłem sprawdzić opcje zasilania układu. Można układ zasilać z USB. W tym przypadku u mnie napięcie na wyjściu VCC wynosi 4.47V. Można zasilać układ napięciem zewnętrznym 6-12V i w tym przypadku na wyjściu regulatora napięcia MIC 5219 powinno być 5V. Jest uwaga na schemacie o opcji 3.3V oraz zwieraniu punktów ozn. SJ1, ale jest to moim zdaniem mylące i nie należy się tym przejmować. Należy przed zakupem sprawdzić czy jest opcja 5V oraz 16 MHz. Jestem już po konfiguracji oraz testach. Do testów użyłem płytki z poprzednich testów z UNO czyli 3xCD 4021 oraz przyciski. Dodatkowo dołączyłem matrycę 4x3. Jest pokazane na zdjęciu. Dołączone elementy działają poprawnie, widać to w programie konfiguracyjnym.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Micro-test.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Micro-test.jpg.html)
Jest tylko jeden problem z którym sobie nie radzę. Walczę z tym od 2 dni i bez powodzenia. MMJoy2 nie jest widziany w Windows. Wgrywałem wiele razy firmware, zmieniałem wejścia USB, zmieniałem VID oraz PIT bez rezultatów. Chociaż dzisiaj przez jakiś czas miałem w Win MMJoy2, ale przy dalszych próbach zmian w konfiguracji już się nie pojawił i nie potrafię to odtworzyć. Trochę to przypomina zabawę z MJoy16, ale to stare dzieje. Mam u siebie 4 kontrolery widziane przez Win oprócz oczywiście MMJoy2. Co ciekawe przy wyborze w konfiguracji MMJoy2 są także widziane ramki F16 MFD1 oraz 2 jako urządzenie do zapisu .
Reasumując nie potrafię zmusić mojego pc z Win7 aby traktował MMJoy2 jako kontroler gier. Może trzeba coś usunąć w rejestrach lub zainstalować jakieś drivery nie mam pojęcia. Zamówiłem Leonardo może na nim będzie dobrze. Trochę szkoda rezygnować z MMJoy2, ponieważ ma on duże możliwości, które warto poznać.
-
Problem rozwiązany i okazał się jak zwykle trywialny. Myślałem, że wystarczy przypisać klawiaturę lub rejestr do konfiguracji. To nie wystarczy trzeba jeszcze zadeklarować w tabelce z prawej strony tak jak na zdjęciu.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_konfig-mmjoy2-ok.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_konfig-mmjoy2-ok.jpg.html)
Teraz mogę przystąpić do poznania parametrów konfiguracji, będzie okazja do pytań.
-
Dobrze, że nie okazało się jak chyba obaj przypuszczaliśmy, że coś nie gra z samym kontrolerem :)
Ja sam na śmierć zapomniałem Ci w naszej korespondencji napisać o przypisaniu klawiszy :P
Swoją drogą nie wspomniałem we wcześniejszym poście o możliwości podpięcia po definiowalne klawisze dwóch HAT'ów (8 przycisków mamy wtedy mniej).
Osobiście projektuje mini płytkę pod same rejestry, tak aby łączyć je 5 przewodami jako moduły oraz dać możliwość umieszczenia ich w osobnych komponentach całego zestawu (joy, pedały i przepustnica + może w przyszłości panele dodatkowe).
-
Ustawienia klawiszy mają rozbudowane opcje konfiguracyjne - możemy je przypisać jako przyciski/przełączniki joy'a lub klawiatury z dodatkowymi modyfikatorami.Nawiązując do cytatu oraz platformy MMJoy2 mam pytania dotyczący na początek tylko klawiatury.
Na platformie MMJoy2 z lewej strony jest mapa gdzie można fizycznie podłączyć matrycę lub rejestry. Z prawej strony są między innymi opcje wirtualny joystick oraz klawiatura. Dla joysticka jest 64 pozycji Button do których możemy przypisać te "fizyczne" z mapy połączeń 1-96. Czy w setup np. mojego symulatora BMS4 widzę te wirtualne Buttons 1-96 którym mogę przypisać kombinację klawiatury.
W platformie setup MMJoy2 każdy Button możemy zdefiniować jako ------, switch, switch on, switch off, soft switch oraz enkoder. Pytanie, czy podłączając przycisk, przełącznik 2 lub 3 pozycyjny lub enkoder do matrycy diodowej lub rejestrów wiemy co wybrać w tabeli mode.
Co oznacza shift1, 2 oraz 3. Czy są to modyfikatory klawiatury typu Shift, Ctrl, Alt czy coś innego. Czy wybór czasu dla timerów oznacza dłuższy czas analizy stanu np. enkodera.
Są to moje podstawowe pytania. Zauważyłem także tabelkę z 12 okienkami dla enkoderów, czy to oznacza, że możemy dołączyć max. 12 enkoderów, które zajmą 24 pozycje z mapy 1-96.
Pytanie do macieja.
dwa zewstawy Arduino micro - jeden służy jako sterownik do silnika krokowego
Czy ten silnik jest powiązany z BMS4. Jeśli tak to jak przechwytujesz dane z symulatora. Jak wiesz codeking potrafi w swojej platformie HSC przechwytywać dane korzystając z biblioteki chyba " Lightinng".
-
To ja się też dołączę :)
Mój kokpit bazuje na A-10C i generalnie latam tylko na DCS. Aktualnie obsługują go 4 szt DMK8. Od kilku miesięcy zgłębiam Arduino i mogę tylko żałować że nie zrobiłem tego wcześniej. Mam w tej chwili podłączone 2x Mega i 4x Nano. Nie jest to jeszcze ostateczny układ ale chyba za dużo już nie zmienię. Jak wspomniał Vito za komunikację odpowiada DCS-BIOS. Można z jego pomocą podłączyć bezproblemowo większość wskaźników ale potrafią się też zdarzyć jakieś nietypowe akcje. Kilka dni temu próbowałem podłączyć serwo mające działać jako wskaźnik wychylenia klap (A-10C). Mam mały problem bo serwo chodzi odwrotnie - chyba że są serwa lewe i prawe? Ktoś może mnie uświadomić w tej kwestii?
Mam opanowane podłączenie LED, wyświetlaczy 7-segmentowych, itd. Jeśli ktoś będzie miał z tym kłopot - chętnie pomogę.
PS. Jak dla mnie to Arduino ma jeden minus - liczbę kabli USB i potrzebę stosowania HUBa. Chociaż gdzieś widziałem próby łączenia szeregowo kolejnych płytek :)
-
Hmm może po I2C to połączyć? Aczkolwiek moja wiedza w tej materii nikła jest bardzo :-[
Vito ja cały czas testuje różne ustawienia - będę wiedział co i jak nie omieszkam napisać.
Co do enkoderów i hatów - https://github.com/MMjoy/mmjoy_en/wiki/Connecting-basic-inputs-and-setting-up-software#button-options - zgłębiam wiedzę z opisów testując :)
-
Ja też mam zamiar poznać możliwości programu, ale zastanawiam się nad metodą. W przypadku kontrolera DMKeys8 można go testować np. programem DIView, który jest także dołączony do MMJoy2. Ponieważ MMJoy2 ma 3 mody pracy to można przez analogię do DMKeys8 wybrać opcję Keyboard, która powinna być widziana w Win jako klawiatura (emulacja). Następnie można przypisać klawisze do fizycznych przycisków, przełączników lub enkoderów wg. tabeli 1-96 w H/W.Button. Tabela mode to prawdopodobnie deklaracja przycisk, przełącznik, enkoder i coś jeszcze do rozeznania. Kolejna tabelka Shift jest dla mnie niezrozumiała. Czy dotyczy modyfikatorów shift, ctrl oraz alt czy czegoś innego. Timer ON ma możliwość wyboru jednego z 3 ustalonych czasów w innej tabelce Timer (delay 50-500 ms). Pytanie czy te czasy są związane z niedoskonałymi elementami (drgania styków, stany nieustalone) np. enkoderów. Jest jeszcze 6 okienek Shift gdzie można przypisać do poz. 1-96 modyfikator. Z tego wynikałoby, że w tabeli z prawej strony w poz. Shift wybieramy który modyfikator. Reasumując jest to do rozeznania, może ktoś już to poznał. Następny element do rozszyfrowania to hat oraz axis to button a na koniec joysticks axes.
Może jest jakiś inny opis oprócz wspomnianego linku np. po rosyjsku. Na koniec wspomnę o uwadze Damosa w odniesieniu do rejestrów oraz enkoderów. Ma on rację enkodery te tanie powinny być połączone do matrycy a nie przez rejestry. To będzie można później potwierdzić testując.
-
Opcję hat na 80% to ustawienie odpowiednich przycisków do fizycznych guzików - wiadomo hat 4 guziczki a kierunków 8 :) masz tam zresztą listę rozwijalną z fizycznymi buttonami 1-96 - przypinasz tylko fizyczny guzik do pcji up/down/left/right i wtedy uc widzi te przyciski jako hat.
Axis to button - tutaj tyle co rozumiem to możemy przypisać guzik który po wciśnięciu ustawi nam daną oś z jednej wartości procentowej na drugą np od 0 do 100% ciągu (dopalacz?)
-
Dopowiem od siebie, że warto poszukać czegoś, co się nazywa "Arduino HID - project". Można popatrzeć też na hasło EDTracker.
Nie pamiętam dokładnie gdzie to znalazłem. W każdym razie jak widać na obrazkach poniżej. Po wgraniu programu z odpowiednim bootloaderem (jedno kliknięcie). Mamy działający joystick z arduino. Obsługuje kilka osi, dwa hat swithe i troszkę guzików (to jest chyba maksymalna liczba jaką windowsowy kontroler gier przyjmuje).
(http://mcdakwa.pl/rozne/joy_zdjecia/arduino_HID.jpg)
(http://mcdakwa.pl/rozne/joy_zdjecia/arduino_HID2.jpg)
Przy swoim joysticku używam arduino leonardo. Bo jak zostało zaznaczone - tylko leonardo i promicro potrafią działać jako HID.
-
Próbuję testując mój model poznać MMJoy2, ponieważ opis pod wskazanym linkiem jest encyklopedyczny bez przykładów. Na początek przyciski oraz enkodery, później przełączniki. Można sprawdzać wspomniane elementy korzystając z konfiguracji w oknie Mouse and keyboard, ale pod warunkiem, że wpiszemy jakieś przypisanie w oknie Joystick. Nie ma czystej emulacji klawiatury tak jak u Damosa, pc musi widzieć kontroler gier. Następnie konfigurujemy dla opcji Button matrix rows oraz columns dla naszych podłączonych elementów do ProMicro. W tabeli Mouse and keyboard przypisujemy klawisz do danej pozycji mapy matrix. Uruchamiamy program testujący Direct Input Viewer i możemy testować.
Testowałem przyciski dla różnych modów (switch, switch ON,switch OFF, soft switch oraz enkoder), wyniki są ciekawe. Można włączyć opóźnienie ustalając czas w ms. Testowałem także enkodery i tutaj mam wątpliwości, ale to wymaga kolejnych testów. To tyle w skrócie. Denerwujące jest to, że nie potrafię przewidzieć jaka jest relacja pomiędzy rows, columns oraz mapą 1-96 tzn. co tworzy kolumny oraz rows. Mamy dla ProMicro B1-B6, C6, D0-D4, E6, F4-F7 co daje razem 17 punktów. Jeśli podłączę do mojego modelu matrycę 4x3 oraz trzy rejestry to następują jakieś przypisania 1-96, które nie potrafię przewidzieć, może mam jakieś zahamowania. Pojęcie Shift nic mi nie mówi. Na koniec pytanie, może ktoś już przez to przechodził.
Ciekawy może być projekt "Arduino HID - project" o którym wspomniał shopik.
-
shopiK wystarczy wgrać bibliotekę do folderu i załadować wsad do arduino- bez konieczności zmiany bootloadera
Dodam swoje trzy grosze. :) Tak jak pisze Vito Arduino jest ogólnie dostępne oraz jest do niego mnóstwo przykładów w siedzi. W chwili obecnej wykorzystuje dwa zewstawy Arduino micro - jeden służy jako sterownik do silnika krokowego, drugi jako joystick do obsługi przycisków z Cougara. Korzystam z biblioteki podanej w linku :https://github.com/MHeironimus/ArduinoJoystickLibrary (https://github.com/MHeironimus/ArduinoJoystickLibrary) Ograniczeniem tej biblioteki są 3 joysticki, ale do obsługi samego Cougara wystarcza. Micro posiada obsługę SPI i I2C. Bardzo ciekawe jest samo I2C do którego potrzeba jedynie 4 kabelków - VCC, GND, SCL i SDA. Mój układ który przedstawiałem w wątku budowy symulatora oparłem na dwóch układach 16 kanałowych MCP23017.
-
I2C używam do podłączenia wyświetlaczy LCD. Potrzebny jest tylko konwerter np. taki:
https://botland.com.pl/konwertery-pozostale/2352-konwerter-i2c-dla-wyswietlacza-lcd-hd44780.html
-
Widocznie jakieś nowsze rozwiązanie się pojawiło, bo wygląda również ciekawie i jest prostsze w instalacji niż to co używałem. Ciekawe tylko, czy po uruchomieniu programu jako joystick działa również serial port (przydatne do debugowania).
-
Maciej, shopiK czy możecie opisać co należy kolejno wykonać aby uruchomić Leonardo jako joystick. Mam IDE Arduino gdzie uruchamiam swoje przykłady na UNO. Zamówiłem Leonardo i chciałbym go testować programem o którym napisaliście.
Równolegle testuję ProMicro w programie MMJoy2. Tutaj mam już kilka wniosków, ale do końca jeszcze daleko. Chcę porównać z sobą te dwie aplikacje jedną MMJoy2 na Pro i drugą na Leonardo.
-
A udało się wam zmienić nazwę w MMJoy2? Tę, która pojawia się w kontrolerach gier.
-
Postaram się w skrócie przedstawić moje wnioski na podstawie testów. Mnie głównie interesowały możliwości MMJoy2 związane z przyciskami, przełącznikami oraz dekoderami. Kolejnym etapem mają by analogi. Testowałem MMJoy2 w konfiguracjach: matryca z przyciskami 4x3, 3 rejestry CD 4021 oraz jeden enkoder (dobrej jakości).
Wniosek pierwszy dotyczy budowania fizycznej matrycy w powiązaniu z mapą 1-96. Ponieważ autor projektu przewidział program setup dla różnych kontrolerów to mamy pełny wybór kolumn oraz wierszy. W ProMicro jest ograniczenie do B1-B6, C6, D0-D4, E6 oraz F4-F7. Nie wiadomo co jest kolumną a co wierszem. Na załączonym obrazku widać, że matryca zajęła 01-12 pozycji a rejestry 13-36, dla mojej konfiguracji. U Damosa są wyraźnie określone kolumny oraz wiersze w relacji do pinów uP. MMJoy2 jest zawsze widziany jako joystick nawet gdy konfigurujemy w tabeli Mouse and keyboard. W opcji joystick mamy osie oraz 32 przyciski. Możemy przypisać pozostałe przyciski od 32 do 96 w tabeli Mouse and keyboard. Są one widziane jako klawiatura. Jest pewne ograniczenie polegające na tym, że możemy przypisać klawisz ale bez modyfikatorów, chociaż na dole jest okienko Keyboard modifier, nie wiem jak to działa. Są także okienka dla 3 Shift oraz pozycji 1-96, też nie wiem jak to działa. Najgorzej wygląda sprawa enkoderów, czego można było się spodziewać. Brak podstawowej opcji konfiguracji enkoderów tzn. jaki to jest typ. Mamy 3 typy enkoderów 1:1, 1:2 oraz 1:4. U Damosa oraz codeking jest ta opcja. Na zdjęciu widać złe działanie enkodera w programie DIView. Powinny być albo same 1-i ruch pokrętła w prawo albo 4-i ruch w lewo. Timery dają opóźnienie jeśli jest taka potrzeba w symulatorze.
Reasumując, gdybym miał zastosować MMJy2 w kokpicie to tylko jako joystick bez dodatkowych opcji typu keyboard. Tutaj projekt Damosa jest bezkonkurencyjny.
Teraz czekam na Leonardo w którym chciałbym zaimplementować program o którym napisał shopiK oraz maciej. Chciałbym go przetestować, ale potrzebuję pomoc od wspomnianych kolegów. Nie chcę znowu odkrywać coś co już jest sprawdzone.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_test%20cd4021%20encoder.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_test%20cd4021%20encoder.jpg.html)
-
To czekamy na konkretne pytania. Jeśli bedę umiał to pomogę.
Maciej zaproponował bardzo proste rozwiązanie: https://github.com/MHeironimus/ArduinoJoystickLibrary Tutaj większej filozofii nie ma. Jeśli jest jakiekolwiek doświadczenie z arduino. Dołącza się bibliotekę i uruchamia program.
Ja wspominałem coś o bootloaderach. I wprowadziłem trochę niepokoju. Miałem rację o tyle, że bawiąc sie tym pewnie już będzie ze dwa lata temu, korzystałem z rozwiązania: https://github.com/NicoHood/HID
Które poprzez zmianę firmware'u umożliwiało uruchomienie funkcji HID nawet na arduino uno, czy mega. W leonardo jest to już niepotrzebne.
W razie czego mogę pokazać mój program do leonardo/micro:
#include <PCF8574.h>
#include <Wire.h>
#include <EEPROM.h>
PCF8574 exp1;
PCF8574 exp2;
PCF8574 exp3;
long hallxSuma;
long hallySuma;
long hallzSuma;
long hallx;
long hally;
long hallz;
long hallxMin;
long hallxMax;
long hallyMin;
long hallyMax;
long hallzMin;
long hallzMax;
int xMinAddress=0;
int xMaxAddress=4;
int yMinAddress=8;
int yMaxAddress=12;
int zMinAddress=16;
int zMaxAddress=20;
int offsetXAddress=24;
int offsetYAddress=28;
long offsetX;
long offsetY;
long roznicaX;
long roznicaY;
int os_x;
int os_y;
int os_z;
void setup() {
analogReference(EXTERNAL);
exp1.begin(0x20);
exp2.begin(0x21);
exp3.begin(0x22);
pinMode(A1, INPUT);
pinMode(A2, INPUT);
pinMode(A3, INPUT);
exp1.pinMode(0,INPUT);
exp1.pullUp(0);
exp1.pinMode(1,INPUT);
exp1.pullUp(1);
exp1.pinMode(2,INPUT);
exp1.pullUp(2);
exp1.pinMode(3,INPUT);
exp1.pullUp(3);
exp1.pinMode(4,INPUT);
exp1.pullUp(4);
exp1.pinMode(5,INPUT);
exp1.pullUp(5);
exp1.pinMode(6,INPUT);
exp1.pullUp(6);
exp1.pinMode(7,INPUT);
exp1.pullUp(7);
exp2.pinMode(0,INPUT);
exp2.pullUp(0);
exp2.pinMode(1,INPUT);
exp2.pullUp(1);
exp2.pinMode(2,INPUT);
exp2.pullUp(2);
exp2.pinMode(3,INPUT);
exp2.pullUp(3);
exp2.pinMode(4,INPUT);
exp2.pullUp(4);
exp2.pinMode(5,INPUT);
exp2.pullUp(5);
exp2.pinMode(6,INPUT);
exp2.pullUp(6);
exp2.pinMode(7,INPUT);
exp2.pullUp(7);
exp3.pinMode(0,INPUT);
exp3.pullUp(0);
exp3.pinMode(1,INPUT);
exp3.pullUp(1);
exp2.pinMode(2,INPUT);
exp3.pullUp(2);
exp3.pinMode(3,INPUT);
exp3.pullUp(3);
exp3.pinMode(4,INPUT);
exp3.pullUp(4);
exp3.pinMode(5,INPUT);
exp3.pullUp(5);
exp3.pinMode(6,INPUT);
exp3.pullUp(6);
exp3.pinMode(7,INPUT);
exp3.pullUp(7);
hallxMin= EEPROMReadlong(xMinAddress);
hallxMax= EEPROMReadlong(xMaxAddress);
hallyMin= EEPROMReadlong(yMinAddress);
hallyMax= EEPROMReadlong(yMaxAddress);
hallzMin= EEPROMReadlong(zMinAddress);
hallzMax= EEPROMReadlong(zMaxAddress);
offsetX= EEPROMReadlong(offsetXAddress);
offsetY= EEPROMReadlong(offsetYAddress);
Serial.begin(9600);
Gamepad.begin();
}
void loop() {
// ----------- odczyt z czujników i uśrednianianie
// ----------- w celu eliminacji skoków (zakłóceń)
for ( int i=0; i<=99; i++){
hallxSuma= hallxSuma + analogRead(A2);
hallySuma= hallySuma + analogRead(A1);
hallzSuma= hallzSuma + analogRead(A3);
}
hallx= hallxSuma/100;
hally= hallySuma/100;
hallz= hallzSuma/100;
// ------------ proste centrowanie (gdyby cyclic nie wrócił fizycznie
// ------------ do punktu centralnego - można go wycentrować wciskając PINKIE
// ------------ i hat switchem wytrymować
if (exp3.digitalRead(2)==LOW & exp1.digitalRead(0)==LOW) offsetX=offsetX-10;
if (exp3.digitalRead(2)==LOW & exp1.digitalRead(2)==LOW) offsetX=offsetX+10;
if (exp3.digitalRead(2)==LOW & exp1.digitalRead(1)==LOW) offsetY=offsetY-10;
if (exp3.digitalRead(2)==LOW & exp1.digitalRead(3)==LOW) offsetY=offsetY+10;
if (exp2.digitalRead(4)==LOW & exp2.digitalRead(5)==LOW) autokalibracja();
if (exp2.digitalRead(5)==LOW & exp3.digitalRead(2)==LOW) centrowanie();
// mapowanie pozycji z czujników halla na dane directX
os_y= map(hally, hallyMin,hallyMax,-32000,32000); //,32766
os_x= map(hallx, hallxMin,hallxMax,32000,-32000);
os_z= map(hallz,hallzMin,hallzMax,-127, 127);
// -------- dodawanie poprawki z ręcznego centrowania
os_x=os_x+offsetX;
os_y=os_y+offsetY;
hallxSuma=0;
hallySuma=0;
hallzSuma=0;
//---------- zabezpieczenie gdyby oś wyskoczyła poza zakres
if (os_x>=32000) os_x=32000;
if (os_x<=-32000) os_x=-32000;
if (os_y>=32000) os_y=32000;
if (os_y<=-32000) os_y=-32000;
if (os_z>=127) os_z=127;
if (os_z<=-127) os_z=-127;
// -------- wysyłka danych do kontrolera gier windows
Gamepad.yAxis(os_y);
Gamepad.xAxis(os_x);
Gamepad.zAxis(os_z);
//przyciski na froncie
if (exp2.digitalRead(0)==LOW) Gamepad.press(7);
if (exp2.digitalRead(1)==LOW) Gamepad.press(6);
if (exp2.digitalRead(2)==LOW) Gamepad.press(2);
if (exp2.digitalRead(3)==LOW) Gamepad.press(3);
if (exp2.digitalRead(4)==LOW) Gamepad.press(5);
if (exp2.digitalRead(5)==LOW) Gamepad.press(4);
if (exp2.digitalRead(6)==LOW) Gamepad.press(8);
if (exp2.digitalRead(7)==LOW) Gamepad.press(1);
if (exp3.digitalRead(0)==LOW) Gamepad.press(10);
if (exp3.digitalRead(1)==LOW) Gamepad.press(12);
if (exp3.digitalRead(2)==LOW) Gamepad.press(11);
if (exp3.digitalRead(3)==LOW) Gamepad.press(9);
if (exp3.digitalRead(4)==LOW) Gamepad.press(13);
if (exp3.digitalRead(5)==LOW) Gamepad.press(14);
if (exp3.digitalRead(6)==LOW) Gamepad.press(15);
if (exp3.digitalRead(7)==LOW) Gamepad.press(16);
// hat switche
if (exp1.digitalRead(0)==LOW) Gamepad.dPad1(7); //pov LEFT
if (exp1.digitalRead(1)==LOW) Gamepad.dPad1(1); // pov UP
if (exp1.digitalRead(2)==LOW) Gamepad.dPad1(3); //pov RIGHT
if (exp1.digitalRead(3)==LOW) Gamepad.dPad1(5); //pov DOWN
if (exp1.digitalRead(4)==LOW) Gamepad.dPad2(7);
if (exp1.digitalRead(5)==LOW) Gamepad.dPad2(1);
if (exp1.digitalRead(6)==LOW) Gamepad.dPad2(3);
if (exp1.digitalRead(7)==LOW) Gamepad.dPad2(5);
// functions above only set the values
// this writes the report to the host
Gamepad.write();
Gamepad.releaseAll();
//delay(10);
Serial.flush();
Serial.print("Os x:");
Serial.print(os_x);
Serial.print(" hallx:");
Serial.print(hallx);
Serial.print(" Os y:");
Serial.print(os_y);
Serial.print(" hallY:");
Serial.print(hally);
Serial.print(" os_z:");
Serial.print(os_z);
Serial.print(" hallZ:");
Serial.print(hallz);
Serial.print(" offsetX:");
Serial.print(offsetX);
Serial.print(" offsetY:");
Serial.println(offsetY);
Serial.print("hallxMin:");
Serial.print(hallxMin);
Serial.print(" hallxMax:");
Serial.print(hallxMax);
Serial.print(" hallyMin:");
Serial.print(hallyMin);
Serial.print(" hallyMax:");
Serial.print(hallyMax);
Serial.print(" hallzMin:");
Serial.print(hallzMin);
Serial.print(" hallzMax:");
Serial.print(hallzMax);
Serial.println();
Serial.println();
Serial.println();
Serial.println();
Serial.println();
Serial.println();
Serial.println();
Serial.println();
Serial.println();
}
void autokalibracja(){
hallxMax=analogRead(A2);
hallyMax=analogRead(A1);
hallzMax=analogRead(A3);
hallxMin=analogRead(A2);
hallyMin=analogRead(A1);
hallzMin=analogRead(A3);
offsetX=0;
offsetY=0;
Serial.print("KALIBRACJA");
for ( int i=0; i<=99; i++){
if (analogRead(A2)> hallxMax) hallxMax=analogRead(A2);
if (analogRead(A1)> hallyMax) hallyMax=analogRead(A1);
if (analogRead(A3)> hallzMax) hallzMax=analogRead(A3);
if (analogRead(A2)< hallxMin) hallxMin=analogRead(A2);
if (analogRead(A1)< hallyMin) hallyMin=analogRead(A1);
if (analogRead(A3)< hallzMin) hallzMin=analogRead(A3);
delay(100);
}
//dodawanie marginesu błędu
hallxMax+=2;
hallyMax+=5;
hallzMax+=5;
hallxMin-=2;
hallyMin-=5;
hallzMin-=5;
EEPROMWritelong(xMinAddress, hallxMin);
EEPROMWritelong(xMaxAddress, hallxMax);
EEPROMWritelong(yMinAddress, hallyMin);
EEPROMWritelong(yMaxAddress, hallyMax);
EEPROMWritelong(zMinAddress, hallzMin);
EEPROMWritelong(zMaxAddress, hallzMax);
EEPROMWritelong(offsetXAddress, offsetX);
EEPROMWritelong(offsetYAddress, offsetY);
Serial.println(" ZAKOŃCZONA");
delay(1000);
}
void centrowanie(){
Serial.print("CENTROWANIE ");
delay(2000);
offsetX=-os_x;
offsetY=-os_y;
EEPROMWritelong(offsetXAddress, offsetX);
EEPROMWritelong(offsetYAddress, offsetY);
Serial.println("CENTROWANIE ZAKOŃCZONE");
}
long EEPROMReadlong(long address)
{
//Read the 4 bytes from the eeprom memory.
long four = EEPROM.read(address);
long three = EEPROM.read(address + 1);
long two = EEPROM.read(address + 2);
long one = EEPROM.read(address + 3);
//Return the recomposed long by using bitshift.
return ((four << 0) & 0xFF) + ((three << 8) & 0xFFFF) + ((two << 16) & 0xFFFFFF) + ((one << 24) & 0xFFFFFFFF);
}
//This function will write a 4 byte (32bit) long to the eeprom at
//the specified address to address + 3.
void EEPROMWritelong(int address, long value)
{
//Decomposition from a long to 4 bytes by using bitshift.
//One = Most significant -> Four = Least significant byte
byte four = (value & 0xFF);
byte three = ((value >> 8) & 0xFF);
byte two = ((value >> 16) & 0xFF);
byte one = ((value >> 24) & 0xFF);
//Write the 4 bytes into the eeprom memory.
EEPROM.write(address, four);
EEPROM.write(address + 1, three);
EEPROM.write(address + 2, two);
EEPROM.write(address + 3, one);
}
z tym, że jak widać, ja mam już nieco zmodyfikowane środowisko i nie muszę dodawać biblioteki w kodzie... ale jak to zrobiłem nie pamiętam. Stosując rozwiązanie zaproponowane przez Macieja. Trzeba dołaczyć bibliotekę <Joystick.h> i tam gdzie u mnie jest gamepad.cośtam zamienić odpowiednie funkcje.
Będa pytania, będziemy myćleć.
Btw. Mój kod pewnie nie jest zoptymalizowany. tzn. dla mnie działa wystarczająco, ale programiści mogą mieć uwagi. Obecnie pracuję nad obsługą ręcznego centrowania. Joystick niestety nie zawsze wraca fizycznie na pozycję zero (rozciągliwe gumy i sprężyny), dlatego tworzę sobie funkcję, która mimo przesunięcia drągala po odpowiedniej kombinacji przycisków wytrymuje mi sygnał wyjściowy do zera.
-
Serial działa i z niego korzystałem do podpatrywania co mi wyskakuje na portach ;)
Tak wygląda mój kod. Też nie jest optymalizowany ale spełnia funkcje jakich potrzebuje i co najważniejsze działa. ;)
#include <Joystick.h>
#include <Wire.h>
int c;
int d;
int f;
void setup() {
Serial.begin(9600);
Joystick.begin();
Wire.begin();
Wire.beginTransmission(0x20);
Wire.write(0x01); // IODIRB register
Wire.write(0xFF); // set all of port B to inputs
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.write(0x0D); // GPPUB register
Wire.write(0xFF); // set all of port B pull-up enable
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.write(0x00); // IODIRA register
Wire.write(0xFF); // set all of port A to inputs
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.write(0x0C); // GPPUA register
Wire.write(0xFF); // set all of port A pull-up enable
Wire.endTransmission();
Wire.beginTransmission(0x27);
Wire.write(0x01); // IODIRB register
Wire.write(0xFF); // set all of port B to inputs
Wire.endTransmission();
Wire.beginTransmission(0x27);
Wire.write(0x0D); // GPPUB register
Wire.write(0xFF); // set all of port B pull-up enable
Wire.endTransmission();
}
void loop() {
Wire.beginTransmission(0x20);
Wire.write(0x13); // read from port B
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.requestFrom(0x20,1);
c = Wire.read();
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.write(0x12); // read from port A
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.requestFrom(0x20,1);
d = Wire.read();
Wire.endTransmission();
Wire.beginTransmission(0x27);
Wire.write(0x13); // read from port B
Wire.endTransmission();
Wire.beginTransmission(0x27);
Wire.requestFrom(0x27,1);
f = Wire.read();
Serial.print("d: ");
Serial.print(d, BIN);
Serial.print("\n");
Serial.print("c: ");
Serial.print(c, BIN);
Serial.print("\n");
Serial.print("f: ");
Serial.print(f, BIN);
Serial.print("\n");
if(bitRead(c,0)==0)
{
Joystick.setButton(0,1);
}
else
{
Joystick.setButton(0,0);
}
if(bitRead(c,1)==0)
{
Joystick.setButton(1,1);
}
else
{
Joystick.setButton(1,0);
}
if(bitRead(c,2)==0)
{
Joystick.setButton(2,1);
}
else
{
Joystick.setButton(2,0);
}
if(bitRead(c,3)==0)
{
Joystick.setButton(3,1);
}
else
{
Joystick.setButton(3,0);
}
if(bitRead(c,4)==0)
{
Joystick.setButton(4,1);
}
else
{
Joystick.setButton(4,0);
}
if(bitRead(c,5)==0)
{
Joystick.setButton(5,1);
}
else
{
Joystick.setButton(5,0);
}
if(bitRead(c,6)==0)
{
Joystick.setButton(6,1);
}
else
{
Joystick.setButton(6,0);
}
if(bitRead(c,7)==0)
{
Joystick.setButton(7,1);
}
else
{
Joystick.setButton(7,0);
}
// HAT SWITCH 1
if(bitRead(f,4)==0)
{
Joystick.setButton(8,1);
}
else
{
Joystick.setButton(8,0);
}
if(bitRead(f,5)==0)
{
Joystick.setButton(9,1);
}
else
{
Joystick.setButton(9,0);
}
if(bitRead(f,6)==0)
{
Joystick.setButton(10,1);
}
else
{
Joystick.setButton(10,0);
}
if(bitRead(f,7)==0)
{
Joystick.setButton(11,1);
}
else
{
Joystick.setButton(11,0);
}
//HAT SWITCH 2
if(bitRead(f,0)==0)
{
Joystick.setButton(12,1);
}
else
{
Joystick.setButton(12,0);
}
if(bitRead(f,1)==0)
{
Joystick.setButton(13,1);
}
else
{
Joystick.setButton(13,0);
}
if(bitRead(f,2)==0)
{
Joystick.setButton(14,1);
}
else
{
Joystick.setButton(14,0);
}
if(bitRead(f,3)==0)
{
Joystick.setButton(15,1);
}
else
{
Joystick.setButton(15,0);
}
if(bitRead(d,6)==0)
{
Joystick.setButton(16,1);
}
else
{
Joystick.setButton(16,0);
}
if(bitRead(d,0)==0)
{
Joystick.setButton(16,1);
}
else
{
Joystick.setButton(16,0);
}
if(bitRead(d,3)==0)
{
Joystick.setButton(17,1);
}
else
{
Joystick.setButton(17,0);
}
if(bitRead(d,4)==0)
{
Joystick.setButton(18,1);
}
else
{
Joystick.setButton(18,0);
}
if(bitRead(d,5)==0)
{
Joystick.setButton(19,1);
}
else
{
Joystick.setButton(19,0);
}
if(bitRead(d,6)==0)
{
Joystick.setButton(20,1);
}
else
{
Joystick.setButton(20,0);
}
if(bitRead(d,7)==0)
{
Joystick.setButton(21,1);
}
else
{
Joystick.setButton(21,0);
}
}
-
Dzięki za kody. Czekam na Leonardo i będę testować oraz raportować. Co do MMJoy2 to trzeba go dobrze poznać i testować. Z informacji w Internecie wynika, że ma dużo zwolenników. Dla mnie istotne było poznanie jego możliwości jako wsparcie joysticka czyli opcja Mouse and keyboard i tutaj dla enkoderów jest problem, chociaż z Internetu wynika, że są stosowane.
Przypomnę tylko, że Damos poświęcił dużo czasu na poprawne działanie różnych typów enkoderów w swoim DMKeys8 i osiągnął dobry rezultat. Testowanie całościowe kontrolera jest dosyć kłopotliwe. W przypadku DMKeys8 musiałem zbudować pełną matrycę 160 pozycji aby znaleźć przesłuch na jednym z wierszy, to tak przy okazji tego tematu. Gdybym chciał testować wszystkie możliwości MMJoy2 to musiałbym zrobić coś podobnego, dlatego uprościłem testy skupiając się na Mouse and keyboard oraz enkoderach.
-
Przejrzałem skrypt macieja i porównałem do swojego. Obydwa realizują to samo zadanie czyli odczyt przycisków w drążku Cougara oraz ich prezentację. Macieja dodatkowo ma przypisania do joysticka i jest widziany w pc. Różnice projektów polegają na zastosowaniu innych rejestrów. W moim przypadku zastosowałem CD 4021 takie jakie są w drążku Cougara. Maciej zastosował MCP23017, które pracują w I2C a moje w SPI. MCP23017 mają opcję pullup, dlatego nie potrzebujemy rezystorów na wejściach rejestrów. Dodatkowa korzyść to biblioteka Wire.h w której są bardzo dobre funkcje, które ułatwiają pisanie skryptu. Skrypt macieja umożliwia realizację drążka Cougara. Pozostałe sprawy czyli osie x, y oraz przepustnicę trzeba dopisać do programu.
Wracając do MMJoy2 to myślę, że dla budowniczych swoich własnych joysticków jest to dobre rozwiązanie pod warunkiem, że realizują tylko joystick. Setup MMJoy2 umożliwia konfigurowanie, nie ma potrzeby pisania skryptów. Dodatkowe funkcje są atrakcyjne tzn. "emulacja klawiatury", ale ryzykowne. Tutaj mogę wspomnieć o moich testach z enkoderem. Może ktoś na forum zrobi takie testy u siebie, będzie możliwość porównania.
Myślę, że projekt zrobienia czegoś podobnego do MMJoy2 jest bardzo atrakcyjny, ale trudny w realizacji. Na poparcie mojej tezy wspomnę o projektach Damosa DMKeys8 oraz DMJoy. Stosuje te same uP co w Leonardo. Problem polega między innymi na małej pamięci tych uP. Damos chciał zrobić DMJoy z możliwością programowania klawiatury, ale nie jest to takie proste. Były problemy z enkoderami, ale zostało to rozwiązane. Dostępne na rynku tanie enkodery są złej jakości i trudno zrobić program, który to uwzględnia.
Co do mnie to będę dalej zajmował się Arduino w różnych jego zastosowaniach. Ponieważ mam kokpit zrobiony pod BMS4 to próbuję znaleźć zastosowanie dla tego symulatora i tu jest problem, ale może znajdę na forum informacje jak przechwytywać dane z symulatora i je realizować w Arduino.
-
Maciej zapomniałem zapytać czy Twoje MCP23017 są ustawione na adresy 20 oraz 27 h czyli w jednym A0-A2 na gnd a w drugim A0-A2 na VCC. Podobnie zegary oraz dane MCP23017 są połączone do SCL oraz SDA Leonardo. Możesz to potwierdzić.
-
Zgadza się w jednym złącza adresowe są pod GND w drugim pod VCC.
-
Dzięki maciej.
Przejrzałem skrypt shopiK i jestem pod wrażeniem. Nie mam wystarczającej wiedzy aby zrozumieć ten program, ale tylko pewne fragmenty są dla mnie rozumiałe. Program realizuje całościowo joystick czyli uwzględnia także analogi. Rejestry są inne PCF8574, ale także I2C oraz z pullup. Jest natomiast dołączona biblioteka EEPROM.h czyli ingerencja w pamięć . Najciekawsze jest programowanie analogów, ale tutaj jestem niekompetentny.
Myślę, że wrócę do MMJoy2 i do testowania analogów, zobaczymy jak to tam wygląda.
-
Nie interesowałem się wcześniej programem mmjoy. Stąd mój program obsługuje joystick w sposób całościowy. to znaczy: po podpięciu do portu usb ma działać jako joystick bez żadnych dodatkowych aplikacji zewnętrznych. Z tej różnicy podejścia z kolei ja jeszcze nie rozumiem, do czego używacie mmjoy. Muszę jeszcze o tym poczytać.
Mój program wbrew pozorom nie jest jakiś specjalnie trudny. Do pamięci eeprom odwołuje się dlatego, że zastosowałem swoją własną kalibrację. Po wcisnięciu odpowiedniej kombinacji przycisków włącza się tryb kalibracji. Program czeka, aż zakręcę joyem jak w kalibratorze windows i do pamięci zapisuje wartości minimalne i maksymalne. Pamięć eeprom jest nieulotna - po odłączeniu zasilania zapis nie znika, więc nie trzeba kalibrować za każdym razem.
Dodatkowo kombinuję trochę z funkcją auto centrowania. Mój joystick, ze względu na amatorską konstrukcję nie zawsze fizycznie wraca do absolutnego zera. I znowu odpowiednia funkcja - autocentrowanie - pozwala ustawić pozycje joya w windows dokładnie na środku (mimo, iż tak fizycznie do absolutnego środka nie wrócił). Ta funkcja jest jeszcze niedopracowana.
Aha. Mówisz, że ciekawe jest oprogramowanie analogów. Jest to bardzo prosta aplikacja. Odczytuję wartość czujnika i mapuję to na wartości wymagane dla direct Input windowsa. Problem jaki zaistniał to szum z czujników. Czyli minimalne skoki odczytywanej wartości. W grze, czy okienku kontrolera gier windowsa - krzyżyk joysticka trochę skakał. dlatego zastosowałem bardzo proste uśrednianie wartości. W odstępie kilkudziesięciu milisekund zczytuję 100 wartości czujnika i wyciągam średnią arytmetyczną. dla mnie to rozwiązanie wystarczy. Próbowałem walczyć z filtrem kalmana, ale niestety potrzebuje on chyba danych z kilku czujników. A my mamy przecież tylko jeden czujnik na oś.
-
Dzięki za wyjaśnienia. Ja także dopiero poznaję MMJoy2. Jest tam dużo możliwości między innym możliwość podłączenia zewnętrzego przetwornika ac. Chcę wrócić do tego programu i poznać jego możliwości pod kątem analogów. Z drugiej strony takie uniwersalne programy jak MMJoy2 są dla mnie podejrzane, ponieważ możliwości uP (pamięci) są ograniczone i trudno napisać dobry program. Dlatego Damos zrobił 2 specjalistyczne kontrolery DMKeys8 dla elementów "cyfrowych" i DMJoy dla analogów. Nie jestem programistą, dlatego trudno mnie to obiektywnie ocenić.
Podziwiam Twoje podejście do problemu i sposób jego rozwiązania. To wymaga niestety trochę więcej wiedzy. W moim przypadku zainteresowałem się Arduino od niedawna i jestem pod wrażeniem. Projektowałem tzw. hardware tradycyjnie. Teraz widzę, że wystarczy poznać możliwości bibliotek i można projektować na układach bardziej złożonych to jest duży postęp.
-
Teraz widzę, że wystarczy poznać możliwości bibliotek i można projektować na układach bardziej złożonych to jest duży postęp.
Tak. Dobry przykład to funkcje eepromWriteLong i readlong w moim kodzie. Służą do odczytywania i zapisywania wartości wiekszych niż 255 w komórkach pamięci... Absolutnie nie wiem jak działają te funkcje, bo nawet nie czytałem specjalnie ich kodu. Tylko wkleiłem i używam :-) To jest potęga społeczności arduino. Masa problemów, które napotykamy, ma już swoje rozwiązanie w sieci. Z bazy przykładów bierzemy co potrzebne i w drogę. :-)
-
Wróciłem do poznawania MMJoy2. Zrobiłem pewne założenia dla moich testów. Testuję tylko opcję z rejestrami. Muszę jeszcze dorobić jeden rejestr aby mięć komplet. W układzie moich 3 rejestrów CD4021 zrobiłem kilka testów. Jeszcze jedna ważna uwaga te kontrolki w setup MMJoy2 to tylko wskaźniki działa lub nie. Właściwa obserwacja to w okienku Windows, gdzie widać faktyczne działanie. Przetestowałem hat1 oraz hat2 i jest widziany w Win. Ciekawe są mody, mamy tutaj 4 mody (enkoder nie ma sensu). I tak kolejno switch ON generuje impuls przy załączaniu (przełącznik) lub przy naciśnięciu (przycisk). Switch OFF generuje przy puszczeniu (przycisk) lub wyłączeniu (przełącznik). Soft switch zapala przy załączeniu, gasi przy powtórnym załączeniu. Dla opcji ozn. "-------" impuls jest generowany zarówno przy załączeniu jak i wyłączeniu. Czas trwania można ustalić opcją timera (od 50ms do 500ms). Jutro przewiduję dalsze testy. Nie mam jeszcze wiedzy na temat opcji Shift.
-
Zrobiłem pewien postęp w poznawaniu MMJoy2. Jest w setup bardzo dobre narzędzie do testowania button pod nazwą WBK Button Tester. Nie ma ograniczeń Win do 32 przypisań. Podłączyłem mój dostępny sprzęt i mam matrycę 4x3 oraz 3 rejestry CD4021 co daje 36 pozycji. Zaprogramowałem 2 HAT co razem zajęło 44 button w wirtualnej tabeli Joystick. W końcu zrozumiałem, mam taką nadzieję jak to działa. Mogę wykorzystać 96 pozycji stosując matrycę oraz rejestry przypisując numer button w tabeli Joystick. Tutaj jest widzę ograniczenie do 64 co i tak jest dużo. Mogę przypisać mod oraz timer, pisałem o tym poprzednio. Nie muszę przypisywać klawiatury do danego button lub hat, ponieważ wystarczy w symulatorze w setup dla danej funkcji np. hamowanie przy kołowaniu nacisnąć odpowiedni przycisk w naszym modelu joysticka. Jedyny problem to zapisać sobie w doc. który button jest za co odpowiedzialny.
Tak jak założyłem nie ruszam opcji Mouse and keyboard. Pozostaje jedna niewiadoma tzw. opcja Shift (1-3). Nie potrafię tego zrozumieć. Piszą:
After defining shifts in the designated section of the MMjoySetup, you can assign different virtual buttons to the same hardware button+shift combination.
Próbowałem przez analogię do Foxy Cougara powiązać ten Shift (1-3) do modyfikatorów w Foxy, które faktycznie zmieniają funkcję np. hat H1 (trymowanie lub widoki) przycisk S3 w drążku. Może tutaj jest coś podobnego, ale jak to sprawdzić. Może ktoś na forum wie co to oznacza i jak to sprawdzić w symulatorze.
Myślę, że teraz mogę zabrać się za analogi.
-
To trochę z innej bajki podejście, ale jakby ktoś chciał swojemu cudu do symulacji dodać trochę funkcjonalności, to jest promocja na Orange PI za $8.57 z przesyłką. Tani malutki kompik do (prawie) wszystkiego.
http://www.cnx-software.com/2016/07/15/orange-pi-pc-board-is-now-selling-for-8-57-shipped-promo/
-
Mały postęp w temacie MMJoy2. Zrobiłem model joysticka z elementów dostępnych w moich śmieciach. Model realizuje 12 przycisków podłączonych do matrycy diodowej, do 3 rejestrów CD4021 mam dostęp do 8 przycisków. Analogi są realizowane za pomocą 4 potencjometrów oraz joysticka. Widać całość na zdjęciu oraz połączenie na schemacie. Analogi dopiero rozpocząłem testować poznając przy okazji setup MMJoy2. Informacje są pod tym linkiem
http://simhq.com/forum/ubbthreads.php/topics/3899105/89 , gdzie twórca mega-mozg-13 odpowiada na pytania. Jest tego dużo i są poruszane różne problemy. Nie należę do tego forum, dlatego nie pytam, ale zapytam tutaj. Czy ktoś już poznał możliwości MMJoy2, łatwiejsza byłaby dyskusja. Mam zamiar poznać jego możliwości, ale na tyle na ile to jest możliwe na moim modelu.
Kolejny logiczny krok to wymiana uszkodzonej elektroniki w jakimś starym joysticku i zastosowanie sensorów. Możliwości MMJoy2 wydają się zrealizować tę modyfikację.
Jedna sprawa nie daje mnie spokoju to zastosowanie enkoderów w ProMicro oraz MMJoy2. Z tego co zauważyłem na forum ludzie stosują enkodery, pytanie dlaczego u mnie są błędy, chociaż mam u siebie ten lepszy enkoder.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Pro-Joy-model-sch.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Pro-Joy-model-sch.jpg.html) (http://i700.photobucket.com/albums/ww5/vito_zm/m_Pro-joy-model.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Pro-joy-model.jpg.html)
-
Chciałbym uzupełnić ostatni wpis. Rozpocząłem wątek Kontrolery Arduino a piszę ostatnio o aplikacji MMJoy2. Ta aplikacja to tylko jeden z przykładów. Zainteresowałem się tą aplikacją z kilku powodów. Maciej z forum ma uszkodzony kontroler do Cougara i musi zbudować zastępczy, wybór padł na Arduino. Zastosował w drążku rejestry MCP23017 z możliwością pullup, której nie mają CD4021. MMJoy2 obsługuje tylko CD4021 lub 74HC165, dlatego musiał napisać swój skrypt. Musi jeszcze dopisać obsługę analogów. Mógłby zastosować MMJoy2 i pozbyć się problemu pisania skryptu.
Drugi powód to zastosowanie ProMicro przez golasa w swoim kokpicie. MMJoy2 nie musi się ograniczyć tylko do mapowania fizycznego joysticka. Można go zastosować do sterowania paneli. I tak zrozumiałem ideę zastosowania golasa. Można połączyć szeregowo połączone rejestry do np. ProUno lub Leonardo i do nich podłączać przyciski lub przełączniki z paneli kokpitu. Sterownik będzie widziany w symulatorze np. BMS4 jako joystick i w setup można go mapować. Jest to kuszące, ponieważ nie potrzeba diodowej matrycy i oszczędzamy na przewodach. Jeśli zastosujemy np. DMKeys8 to musimy budować diodową matrycę.
Nie mogę porównać tych dwóch kontrolerów mam na myśli DMKeys8 oraz ten z aplikacji MMJoy2, ponieważ mam u siebie tylko ten Damosa. Jeszcze jedna różnica DMKeys8 jest widziany przez pc jako klawiatura na natomiast MMJoy2 jako joystick. Jeszcze jedno porównanie MMJoy2 do MJoy16, który był na forum bardzo popularny. MJoy16 był mapowany w SWMapper i pracował z tym programem.
Piszę dosyć dużo na temat MMJoy2, ponieważ może on być atrakcyjny dla osób, które nie lubią pisać skryptów i zagłębiać się w Arduino a chcą jakoś rozwiązać sterowanie swoich paneli. Jedyny problem, który u mnie wystąpił z MMJoy2 to błędy przy podłączeniu enkoderów. Celowo w moim modelu stosuję matrycę , rejestry, pots oraz joystick z zestawu UNO, aby lepiej testować zarówno program jak i Arduino. Apelowałem do naszego forum, ponieważ sądziłem, że ta aplikacja jest już u nas stosowana. Na forum rosyjskim ta aplikacja sądząc po wpisach jest popularna.
Mam w dalszych planach rozeznać możliwości zastosowania Aruino w moim symulatorze BMS4. Tak jak napisał Marcin_B nie ma problemu w DCS, ale jest problem w BMS4. Jeśli będzie zainteresowanie tym wątkiem to go pociągnę. Myślę, że wyjaśniłem swoją ideę.
-
Vito - dla mnie właśnie bardzo dużą zaletą właśnie jest jak pisałem system modularny bo do połączenia kolejnych rejestrów przesuwnych wystarczy 5 kabelków :)
Ja póki co mam przestój dość spory w budowie ze względu na brak czasu i środków - niestety po równo :)
-
Czas na krótkie podsumowanie MMJoy2. Jest to wspaniała platforma, która może pracować z tanim ProMicro (23 zł). Można zrealizować 8 analogów na pots lub sensorach. Jest możliwość podłączenia przetwornika zewnętrznego. Komunikacja z rejestrami jest po SPI. Można realizować przyciski oraz przełączniki z różnymi modami oraz timerami. Jest to dobre rozwiązanie dla osób, które mają problemy z pisaniem skryptów. Niestety jest to tylko uzupełnienie innych kontrolerów np. DMKeys8 do którego można podłączyć enkodery. Podobnie platforma HSC oraz SimOut jest bezkonkurencyjna, ponieważ może sterować LED, LCD oraz 7segLED. Reasumując MMJoy2 jest bardzo dobrym uzupełnieniem wspomnianych kontrolerów.
Co do mnie to mam zamiar poznać dokładnie projekt macieja i dorobić do niego analogi.
-
Dorobienie osi analogowych to kwestia podłączenia potencjometrów pod odpowiednie wejścia Arduino i dopisanie kilku linijek kodu - odczyt wartości z osi analogowej (jest to w przykładach z Arduino) a następnie wysłanie jej do komputera za pomocą polecenia
Joystick.setXAxis(byte value).
-
Zrobiłem model dla testów projektu joysticka macieja, jest na zdjęciu. Do 2 układów MCP 23017 mogę podłączyć 16 przycisków.
(http://i700.photobucket.com/albums/ww5/vito_zm/joy-maciej.jpg) (http://s700.photobucket.com/user/vito_zm/media/joy-maciej.jpg.html)
Zrobiłem kompilację i wgrałem skrypt (szkic) macieja do Leonardo i jest ok. Mam tylko problem z monitorowaniem. Leonardo jest na COM7 i po wgraniu skryptu jest tak jak na zdjęciu error-1 (nie jest zaznaczony COM7).
(http://i700.photobucket.com/albums/ww5/vito_zm/error1-1.png) (http://s700.photobucket.com/user/vito_zm/media/error1-1.png.html)
Włączam monitor portu szeregowego i otrzymuję komunikat error-2 (dlaczego COM5 ??). Mam dostępny tylko COM7.
(http://i700.photobucket.com/albums/ww5/vito_zm/error-2.png) (http://s700.photobucket.com/user/vito_zm/media/error-2.png.html)
Po włączeniu COM7 i ponownym włączeniu monitora portu szeregowego otrzymuję to co na obrazku error-3.
(http://i700.photobucket.com/albums/ww5/vito_zm/error3.png) (http://s700.photobucket.com/user/vito_zm/media/error3.png.html)
Nie miałem problemów z UNO oraz monitoringu portu szeregowego w poprzednich projektach. Nie rozumiem gdzie jest błąd.
-
Jeszcze w kwestii enkoderów do mmjoy2:
(http://simhq.com/forum/files/usergals/2014/08/full-37484-85623-pins_common.png)
Czekam teraz na paczkę z chin z TLE5011 bo cena w polsce zabójcza oraz kilkoma innymi 'gratami' w tym enkodery :) popatrzymy popróbujemy :)
-
Coś u mnie ruszyło trzeba to dokładnie sprawdzić musi pracować w modzie portu szeregowego a nie w modzie monitora portu szeregowego. Mam zamiar sprawdzić jak to wygląda z układami I2C, chcę zrobić coś podobnego jak w MMJoy2 może się uda.
Już teraz widać, że MMJoy2 jest właściwym narzędziem ze względu na platformę. Mam nadzieję golas, że wejdziesz w temat i będzie można podyskutować. Jest opcja zapisania się na forum i pytania między innymi o enkodery. Może to trzeba zrobić ale na początek chciałbym potwierdzenia moich testów i tutaj są potrzebne testy golasa.
-
Hehe to daj mi miesiąc minimum jak paczka przyjdzie :) Chyba, że uda mi się w niskiej cenie jakieś w miarę normalne enkodery w naszym kraju znaleźć :)
-
Mam nadzieję, że opanuję moje Arduino Leonardo oraz opcję monitor szeregowy. Problem dotyczy numeracji COM. Po wgraniu programu w platformie Arduino potrafi się zmienić numeracja COM np. z 7 na 5, gdzie COM7 jest w menadżer urządzeń. Była też zmiana z Arduino Leonardo na Arduino Yun. Mam nadzieję, że ustabilizuję system i zajmę się skryptem macieja. Co do enkoderów to apel do golasa. Można kupić enkoder za kilka zł w miarę dobry. Warto połączyć tylko jeden enkoder i sprawdzić czy daje błędy. Jeśli tak to pozostaje zapisać się na forum i przedstawić problem. Oni tam stosują enkodery do łączności radiowej. Będę jeszcze szukał funkcji, może znajdę, które realizują działanie enkoderów w Arduino. Może jest w jakiejś bibliotece.
-
Problem z portem szeregowym w mikrokontrolerach z wbudowanym USB, jakim jest ATMEGA32U4 polega na tym, że jest on w pewnym sensie wirtualny, jest częścią drivera USB w bootloaderze i potem w głównym programie też. Stąd po wgraniu programu, resecie procesora port ten na chwilę znika, pojawia się po chwili, a system po ponownym wykryciu nadaje mu inny numer. Niezbyt wygodne rozwiązanie jeśli używamy portu do debuggowania programu. Z drugiej strony zaletą jest możliwość użycia go do symulacji joysticka lub klawiatury.
O wiele lepszym wyjściem, jakie stosuję w takich wypadkach jest użycie sprzętowego portu szeregowego. ATMEGA32U4 ma właściwie dwa. Jeden dostępny poprzez USB i drugi, "normalny" dostępny poprzez piny TX i RX. W Uno te piny podłączone są do zewnętrznego translatora UART<-->USB.
W Leonardo inicjacja portu przez
Serial.begin(baudrate);uruchamia ten pierwszy port na USB. Dostęp do tego drugiego realizuje się poprzez Serial1, np.:
Serial1.begin(baudrate);Oczywiście, żeby podłączyć drugi port do PC potrzebujemy jeszcze jakiś moduł UART-USB. Przestrzegam przed kupowaniem modułów opartzch na FT232 w Chinach. Jest cała masa podróbek, a jakiś czas temu było ogólne poruszenie gdy f-ma FT wypuściła nowe sterowniki wykrywające podróbki i nawet je uszkadzające. Tanie Arduino z Chin przestawały nagle działać. Oczywiście Chiny zareagowały dość szybko zastępując układ FT własnym, tańszym i działającym równie dobrze (CH340 o ile się nie mylę).
Polecam za to moduły Bluetooth-UART serii HC-06 lub HC-05. Działają w porządku, a do tego z telefonu albo tabletu można zrobić sobie dedykowany terminal.
Serial1 będzie pozbawiony "czkawki" jaką powoduje reset i przeprogramowanie procesora.
Jeszcze innym rozwiązaniem, którego osobiście nie sprawdzałem, ale poleca go strona Arduino jest dodanie podczas inicjalizacji pętli czekającej na otworzenie się portu szeregowego:
Serial.begin(9600);
// while the serial stream is not open, do nothing:
while (!Serial) ;
Mam nadzieję, że moje wypociny wniosły co nieco do tematu. Na codzień zajmuję się mikrokontrolerami, być może będę w stanie pomóc w kilku kwestiach.
-
Bardzo dziękuję za wyjaśnienia. Nie mogłem zrozumieć zachowania się Leonardo. Faktycznie UNO ma inny procesor a właściwie dwa i może dlatego nie miałem z tym problemu. Generalnie Arduino jest dla mnie nowością, ale jestem pod wrażeniem jako praktyk w tzw. hardware. Nie będąc programistą można sobie ułatwić życie.
-
Witam
Obserwuje ten wątek i jestem bardzo ciekaw rezultatów. Czytając go wpadłem na pomysł, czy nie dało by rady stworzyć modułu wejścia i wyjścia dla Arduino do HSC. Oczywiście, jeżeli codeking by pomógł. Nawet taki najprostszy czyli odczytujemy dane z symulatora i wysyłamy na serial monitor do Arduino o odwrotnie. Później napisanie szkicu do Arduino to już da radę. Od jakiegoś czasu "bawię" się Arduino i można dużo zrobić. Wyświetlacze np 7-segmentowe czy inne oraz przyciski i encodery. Robiłem testy z encoderami i przy podłączeniu bezpośredni do Arduino korzystając z biblioteki Rotary.h bardzo ładnie działało z różnymi encoderami, tymi tańszymi również. Testy robiłem z diodami i było ok nie gubił impulsów nawet przy szybkim obracaniu. Można stworzyć projekt na innej atmedze / nie trzeba korzystać z gotowych płytek / trzeba tylko kwarc parę kondensatorów i jeden opornik i mamy własne Arduino. Sam zrobiłem takie na atmedze 328p oraz atmedze 16 gdzie jest już dużo portów wejścia wyjścia. Można jeszcze dodać dodatkowe kontrolery np do wyświetlaczy 7-segment np / MAX7219 czy TM1637 / czy układy MCP23017 i już można budować.
Pozdrawiam Zając
-
Bardzo się cieszę, że się znowu pojawiłeś na forum. Dla mnie Arduino jest rewelacją z kilku powodów. Najważniejszy to biblioteki drugi to cena. Mam teraz ProMicro za 23 zł i trochę droższe UNO i Leonardo. Można to zrobić samemu i będzie jeszcze taniej to fakt.
Zajmuję się Arduino od niedawna i dopiero poznaję jego możliwości. Testowałem ostatnio tak jak wspomniałem MMJoy2 i jestem pod wrażeniem. Coś podobnego do HSC codeking, ale nie tak uniwersalne, ma ograniczenia. Wg. mnie to HSC jest najlepszą platformą dla budowniczych kokpitów czy paneli dla symulatorów. Dla mnie barierą jest zrobienie programu do przechwytywania danych z symulatora BMS4 przez Arduino. To zrobił codeking w HSC. Na forum są programiści, którzy to zrobili dla swoich kontrolerów. Jest biblioteka Lightning, ale trzeba wiedzieć jak z niej korzystać.
Wracając do moich doświadczeń to mogę stwierdzić, że SimOut oraz SimIN i HSC załatwia większość spraw związanych z budową kokpitów.
Kontrolery Arduino mogą stanowić uzupełnienie ze względu na cenę oraz małe wymiary. Można je umieścić w panelach np. ICP. Stosując interfejs SPI lub I2C oraz odpowiednie układy można zrezygnować z budowy diodowych matryc.
Jedną z zalet DMkeys8 jest dopracowana platforma do konfiguracji, możliwość przypisania do przycisków sekwencji kombinacji klawiatury oraz możliwość konfigurowania enkoderów.
Co do mnie to będę nadal eksperymentował z Arduino, ale pod kątem zastosowania w symulatorach. Z DCS nie ma problemu ale jest problem z BMS4. Tutaj przydałby się programista taki jak codeking.
Dobrze, że Zając wspomniał o Rotary.h to daje szansę na zastosowanie enkoderów. Ciekawe czemu dekodery w MMJoy2 u mnie przekłamują. Nie chce mi się wierzyć , że twórca tego nie przewidział. Na zakończenie dodam, że jestem coraz większym optymistą, ponieważ temat zainteresował kolegów a to rokuje nadzieję.
-
cd
Dzięki pomocy kolegi 3.14 ter mogę kontynuować testy szkicu (skryptu) macieja. Ponieważ nie mam odczytu przycisków podłączonych do MCP23017 to mam pytania do macieja.
Pierwszy MCP23017 jest na adresie 20 (A0-A2 na gnd) drugi na 27 (A0-A2 na VCC) tak jak u macieja. Sprawdziłem rejestry w setup oraz loop skrypu z katalogiem MCP23017. Adresy rejestrów zgadzają się z adresami BANK = 0. Ale mam wątpliwość co do odczytu rejestru A oraz B w pętli loop.
Mam na myśli ten fragment a konkretnie linijkę z pogrubionymi literami
Wire.beginTransmission(0x20);
Wire.write(0x13); // read from port B
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.requestFrom(0x20,1);
c = Wire.read();
Wire.endTransmission();
Jest instrukcja write a nie read. Czy możesz to wyjaśnić. Ja mam na szeregowym monitorze tylko same jedynki (pullup) i nie ma reakcji na zwieranie do gnd co sugeruje brak odczytu portu.
-
Tak wtrącając jeszcze może odnośnie programowania na ardku, ja nie posiadając kiedyś fizycznie testowałem rozwiązania na programach typu:
http://www.smashingrobotics.com/arduino-simulators-lineup-start-developing-without-real-board/ - jak zobaczyłem, że coś tam jednak potrafię napisać wtedy zakupiłem pierwsze :P co by nie marnować pieniędzy ;)
-
Witam
Chciałbym pokazać jak encoder u mnie działa - oto filmik https://www.youtube.com/watch?v=RI_ky6x1peM (https://www.youtube.com/watch?v=RI_ky6x1peM) . Ta biblioteka rotary.h będzie działać pewnie tylko na arduino a nie na MMJoy2. Można ją wykorzystać w szkicach arduino, z tego co poczytałem to obsługuje ona różne typy encoderów. Na filmiku widać, że próby robiłem na "własnym" Arduino na Atmedze16, które również wysyła na serial monitor dane / mogą być dowolne / i teraz jakby się udało je odczytać w HSC i wysłać do symulatora ti było by fajnie. Obok Atmegi16 widać MCP23017. Na razie przyciski obsługuje, ale nie mogę odpalić biblioteki rotary.h do encodera podpiętego do MCP23017. Będę próbował i dam znać.
-
Uprzedzę odpowiedź kolegi Macieja.
Wire.write(0x13); // read from port B
Ta instrukcja ustawia adres rejestru z którego będziemy czytać dane poźniej, w następnych krokach.
W tzw. pseudo-kodzie wygląda to tak:
- wyślij komendę I2C start, celuj w odbiornik o oadresie 0x20
- ustaw adres rejestru - musimy najpierw podać skąd chcemy pobrać dane
- wyślij I2C stop. W tym momencie wewnętrzny adres MCP23017 ustawiony jest na 0x13, czyli GPIOB (BANK=0).
Dalej startujemy transmisję jeszcze raz, ale tym razem będziemy odczytywać jeden bajt z MCP23017. Odczyt nastąpi z adresu ustawionego wcześniej.
Ustawienie BANK=0 przeznaczone jest w zasadzie do sekwencyjnego odczytywania/zapisywania portów A i B. Część kodu Macieja odpowiedzialną za odczyt z MCP23017 można uprościć i zoptymalizować do dwóch funkcji. Niestety nie mam teraz pod ręką układu, żeby go przetestować, ale powinno działać. Starałem się dokładnie komentować kod, myślę, że powinien być zrozumiały. Cała operacja czytania portów z MCP23017 zgrupowana jest w jedną funkcję, która jako argument pobiera adres I2C kości, a wyrzuca stan wszytkich przycisków w 16 bitowym słowie.
uint16_t buttonBank1, buttonBank2; //zmienne przechowujace stan przyciskow
void initMCP23017(uint8_t slaveAddr); //deklaracja funkcji inicjalizujacej
uint16_t readMCP23017(uint8_t slaveAddr); //deklaracja funkcji odczytywania stanu portow
/*
Funkcja inicjalizujaca uklad MCP23017
wszystkie piny jako input + pullup
argument: adres I2C
BANK0 = 0 - wykorzystamy sekwencyjny zapis,
adres jest automatycznie inkrementowany
po kazdej operacji zapisu bajtu
*/
void initMCP23017(uint8_t slaveAddr)
{
// IODIRA -> IODIRB
Wire.beginTransmission(slaveAddr);
Wire.write(0x00); //IODIRA
Wire.write(0xFF); //portA = wejscia, adres skacze do 0x01=IODIRB
Wire.write(0xFF); //portB = wejscia
Wire.endTransmission();
// Pull-ups
Wire.beginTransmission(slaveAddr);
Wire.write(0x0C); //GPPUA
Wire.write(0xFF); //podciagnij wejscia A do VCC,nowy adres = 0x0D=GPPUB
Wire.write(0xFF); //podciagnij wejscia B do VCC
Wire.endTransmission();
}
// Funkcja odczytujaca stany portow GPIOA i GPIOB
// stan zwracany jest w postaci 16bitowego slowa,
// gdzie jeden bit odpowiada jednemu przyciskowi
uint16_t readMCP23017(uint8_t slaveAddr)
{
uint8_t output[2];
uint8_t index = 0;
Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adress
Wire.write(0x12); //ustaw wewnetrzny adres na GPIOA
Wire.endTransmission(); //I2C stop
Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adres
Wire.requestFrom(slaveAddr,2,true); //grzecznie popros o 2 bajty
//po odczytaniu GPIOA wewnetrzny adres
//automatycznie zostanie zwiekszony o 1.
//czyli wyladuje na GPIOB
//"true" na koncu generuje I2C stop i zwalnia
//magistrale, Wire.endTrasmission nie jest potrzebny
while (Wire.available())
{
output[index] = Wire.read(); //wpisz GPIOA i B do tablicy
index++;
}
return uint16_t(output[0] | ((output[1])<<8)); //zgrupuj oba bajty w 16 bitowe slowo
}
Użycie funkcji wygląda następująco:
//inicjalizacja obu ukladow:
initMCP23017(0x20);
initMCP23017(0x27);
//potem gdzies w programie
buttonBank1 = readMCP23017(0x20);
buttonBank2 = readMCP23017(0x27);
W sumie właśnie odkryłem, że istnieje już biblioteka do MCP23017 (https://github.com/adafruit/Adafruit-MCP23017-Arduino-Library). Ech.. arduino ;) Może ten kod powyżej będzie miał chociaż wartość edukacyjną :)
Być może nadeszła odpowiednia chwila, żeby odkurzyć mój stary projekt kontrolera do Iłka i pomajstrować co nieco:
(http://i.imgur.com/RvRxCoT.jpg)
W kwestii enkoderów, pan Marek w dość przystępny sposób objaśnia ich działanie, pułapki i inne kruczki, które mogą się pojawić podczas ich obsługi:
http://mirekk36.blogspot.de/2016/02/enkoder-obrotowy-od-podstaw.html
Jeśli chodzi zaś o magistralę I2C to jest ona raczej "krótkiego zasięgu". Zbyt długie kable i spora liczba odbiorników zwiększa pojemności pasożytnicze na liniach, przez to mogą pojawić się przekłamania i błędy. Trzeba mieć to na uwadze projektując systemy modułowe.
Jeszcze takie pytanie: nie macie problemów z drganiami styków w przyciskach? Typu przycisk wyzwalany jest kilka razy itp.? Eliminacja drgań styków to pierwsza rzecz jaką dodaję, jesli urządzenie ma przyciski. Jest taki dość sprytny sposób na filtrowanie drgań kilku-kilkunastu wejść naraz. Wymaga jedynie przerwania Timera ustawionego na ok. 5-10 ms.
/Piter
-
Dzięki koledzy za włączenie się do tematu. Te symulatory pod Arduino są bardzo ciekawe. Co do enkoderów to faktycznie pięknie działają nie ma przekłamań.
Zajac wspomniałeś, że twoja MCP23017 odczytuje przyciski. W szkicu macieja musi być jakiś błąd. W poprzednim post pokazałem ten fragment szkicu, który ma odczytać port A oraz B i zapisać do zmiennej c. Moje MCP23017 są na adresach 20 oraz 27. Czy możesz pokazać fragment twojego szkicu odczytującego porty A i B.
Ja próbowałem w MMJoy2 odczytywać enkodery zarówno podpięte do pinów MroMicro jak i do rejestrów CD4021. W obu przypadkach enkodery przekłamywały.
-
Jeszcze takie pytanie: nie macie problemów z drganiami styków w przyciskach? Typu przycisk wyzwalany jest kilka razy itp.? Eliminacja drgań styków to pierwsza rzecz jaką dodaję, jeśli urządzenie ma przyciski.
Ja stosuję rozwiązanie Damosa, czyli DMKeys8, który emuluje klawiaturę. W platformie Damosa konfigurującego DMKeys8 są różne możliwości eliminacji niedoskonałości elementów elektronicznych typu styki czy enkodery. W wspomnianym MMJoy2 są także do wyboru 3 timery w których można ustawiać opóźnienia, ale na enkodery (przekłamania) to nie ma chyba wpływu. Damos zastosował możliwość zwiększenia ilości próbowania zboczy i uśredniania wyniku. W gorszych enkoderach zbocza prawie na siebie nachodzą.
Dzięki Piter za wyjaśnienia oraz przykłady. Muszę to przetrawić. Widzę, że mamy fachowca od programowania to jest optymistyczne
-
Już działa na szkicu macieja. Dziękuję Piter za pomoc w zrozumieniu działania MCP23017. Bez Twojej pomocy nie dał bym rady, mam na myśli zmiany wirtualnych COM przy wgrywaniu do kości. Nie mam jeszcze połączenia na TX, RX zrobię to później. Teraz korzystam z USB, ale mam prostą metodę. Przy testach które wymagają wgrania szkicu sprawdzam po wgraniu na menadżer urządzeń jaki wybrał COM i przy szeregowym monitoringu ustawiam ten COM i jest ok. Nie zawsze wraca do tego samego COM, dlatego to sprawdzanie.
Co do moich kłopotów z odczytem wejść to jak zwykle trywialny problem. Porty A oraz B mają na złączach 10 pin masy w innych miejscach (łatwiejsze połączenia na pcb). Jeśli pomylimy sznury łączące płytę z MCP23017 z płytą z 16 przyciskami to mamy problem z podawaniem masy, co wystąpiło w moim przypadku.
Teraz mogę testować szkic macieja dokładniej i już widzę szansę na jego poprawę, ale o tym później. Gratuluję Piter powrotu do zabawy w panele, ładnie wygląda ten na zdjęciu.
-
Zaraziliście mnie Panowie :)
Zacząłem już pisać własny program pod Leonardo/ATMEGA32U4 z wykorzystaniem MCP32017. A to tego powstaje już bazowa płyka z procesorem i całą resztą. Być może nieco na wyrost, ale moje podejście jest takie: jeśli buduję coś jednostkowego to projekt nie musi być maksymalnie wyżyłowany (w sensie zoptymalizowany i jak najtańszym kosztem). Warto dodać kilka różnych zabezpieczeń i dodatków, opcjonalnych konfiguracji itp. Zazwyczaj przydają się później.
Nie mam na stanie wersji PDIP MCP23017, jedynie QFN24 - za bardzo nie da się jej wetknąć w stykówkę ;) Ale to nic, nowy egzemplarz niedługo przyjedzie.
Tymczasem napisałem program, który udaje przyciskanie i wysyła to do WIN, systemowy podgląd joysticka pokazuje, że działa:
(http://i.imgur.com/s2pgWkJ.png)
Przy okazji do podglądu co się dzieje w programie wykorzystałem bibliotekę BasicTerm (https://github.com/nottwo/BasicTerm) i program PuTTy. Działa praktycznie jak zdalny monitor tekstowy. Użyłem Serial1 i zewnętrzną przejściówkę Serial-USB, okazało się, że system nie odbiera danych z joysticka jeśli jestem podłączony terminalem do Serial, tego, który leci po USB Atmegi.
W sumie logiczne, port USB jest już zajęty czymś innym.
-
Robi się ciekawie. Tego brakowało , ja jutro przedstawię moją koncepcję na podstawie moich skromnych doświadczeń z Arduino oraz innych kontrolerów, które mam u siebie w kokpicie.
-
Tak jak wspomniałem próbuję określić pewne założenia projektu wspomagającego kontrolę kokpitu w symulatorach opartego na Arduino. Punktem wyjścia jest procesor ATmega32U4. Czy to będzie własny projekt sterownika czy gotowy ProMicro lub Leonardo to nie ma znaczenia. Pytanie podstawowe po co nowy projekt jeśli już są dostępne inne sterowniki z programami. Na podstawie swojego kokpitu mogę odpowiedzieć, że każdy zastosowany u mnie sterownik spełnia doskonale swoją rolę, ale w ograniczonym zakresie. Jest szansa, zaprojektowania kolejnego kontrolera na bazie Arduino, który w jakimś stopniu zastąpi MJoy16. Jest już doskonały program MMJoy2 z przyjazną platformą. Program ten realizuje to co realizował MJoy16, ale ma ambicje zrobić coś więcej np. sterowanie LED. Po moich testach mogę stwierdzić, że można go stosować z wyjątkiem enkoderów co jest wadą.
Po testach szkicu macieja mogę stwierdzić, że jest program, który realizuje funkcje joysticka. Analogi można dopisać. Można także dopisać bibliotekę o której wspomniał zajac i sprawdzić jak działają enkodery. Maciej zrobił swój projekt po to aby zastąpić uszkodzony kontroler Cougara. Można ten projekt rozwinąć i próbować zrobić coś podobnego do MMJoy2 dokładając rejestry MCP23017 oraz analogi. Jeśli będą problemy o których wspomniał zajac z enkoderami podłączonymi do rejestrów to można zrobić dodatkową klasyczną matrycę diodową dla enkoderów. Trzeba także zmienić w szkicu macieja funkcje realizujące HAT. Maciej potraktował HAT jak przyciski. Myślę, że znalazłem rozwiązanie, ale muszę to przemyśleć.
W platformie MMJoy2 są dołączone bardzo przydatne programy do testowania między innymi do testów przycisków oraz HAT pod nazwą VBK_Btn Tester. W odróżnieniu od Win można testować większą liczbę przycisków.
3.14 ter jakie jest Twoje zdanie na temat tego co napisałem, czy to ma sens.
-
Z całą pewnością nie mam takiego doświadczeznia z kokpitami, jak wielu z Was i dokładnie nie jestem pewien co będzie potrzebne. W sensie ilości wejści itp. Za punkt wyjściowy przyjmuję to, co może obsłużyć standardowy joystick HID w Windows.
Jeśli chodzi o używanie istniejących rozwiązań, ich adaptację - pewnie dobry pomysł, ale chyba nie dla mnie ;) Ten mały projekt joysticka nad którym pracuję powstanie na zasadzie sportu, dla odskoczni od tego co robię na codzień. Dlatego raczej postaram się stworzyć coś własnego od podstaw. Najprawdopodobniej będzie to pojedyncza płytka o dość sporych możliwosciach konfuguracyjnych, z kondycjonowaniem sygnałów analogowych, zasilania, dodatkową ochroną wejść/wyjść. Po prostu taka baza, na której można będzie zbudować joystkick albo innego rodzaju kontroler i która przetrwa różne męczarnie związane z eksperymentowaniem przy budowie kokpitów.
Projekt będzie w całości udostępniony na zasadach "open hardware".
Kwestia enkoderów:
raczej wątpię, że rozwiązania typu matryce czy odczytywanie stanów kilku enkoderów podłączonych do MCP23017 czy innego rejestru przesuwnego dadzą zadawalające rezulataty. Kręcenie enkoderem może generować dość szybkie przebiegi. W dotychczasowej wersji MCP odcztywany jest cyklicznie w pętli głównej. Procesor ma, albo będzie miał też inne zadania. Przez to na 100% dochodzić będzie do gubienia kroków, co jakiś czas procesor będzie zajęty czymś innym i po prostu nie zdąży wyłapać zmiany. Sytuację poprawić może użycie przerwań (INTA i INTB) w MCP do zasygnalizowania procesorowi, że nastąpiła jakaś zmiana na wejściach. To rozwiązanie ogólnie jest lepsze i takie zastosuję w mojej wersji. Program nie musi na okrągło odbierać danych z MCP tylko czeka na sygnał i ściąga sobie dane jeśli naciśnięty został któryś z przycisków.
Poza tym coraz bardziej skłaniam się do wersji dwuprocesorowej. ATMEGA32U4 będzie działać jako główny procesor, odpowiedzialny za wejścia analogowe i jeden bank 16 przycisków na MCP23017. Drugi procesor, jakiś mniejszy, np. ATMEGA8 będzie odpowiedzialny za 8 wejść enkoderów. Porządnych wejść z filtowaniem drgań, działających na przerwaniach przez co nie powinno dochodzić do gubienia kroków. Zapewne nie zawsze potrzebne będzie aż 8 enkoderów. Myślę, że jakiś mechanizm na zworkach mógłby przełączać wybrane wejścia między funkcją enkodera, a dwoma wejściami dla zwykłych przycisków. Ten drugi procesor generowałby zdarzenia typu "wciśnięty przycisk" sygnalizujące EnkoderN/obrót w lewo/obrót w prawo i wysyłał je do procesora głównego. Połączenie między obydwoma prcesorami będzie przez SPI, to zapewni możliwość zaprogramowania małego MCU z dużego (Arduino ISP).
Opcjonalnie (można ominąć zworkami) planuję dodanie zewnętrznego 12bitowego przetwonika A/C dla osi które wymagają większej przecyzji.
Mam już MCP23017 w DIP na stole i pewnie dziś przetestuję jak działają nowe funkcje.
-
Dzięki za wyjaśnienia oraz obietnicę udostępnienia projektu. Bardzo się przyda szczególnie w przypadku budowy własnego joysticka lub gdy zostanie uszkodzona płyta sterownika np. do Cougara (nie do zdobycia na rynku). Ja będę jeszcze eksperymentował, ale raczej w celach poznawczych. Co do enkoderów to masz całkowitą rację. Damos w swoim DMKeys8 dużo czasu poświęcił na opcję konfigurowania enkoderów (ustawianie filtrów, wybór typu enkodera 1:1, 1:2, 1:4) po to aby minimalizować przekłamania.
Na koniec pytanie związanie z programowaniem HAT w joysticku. Tak jak wspomniałem maciej nie znalazł sposobu zaprogramowania HAT, dlatego potraktował go jako zwykłe przyciski. W programie dla MMJoy2 jest możliwość zaprogramowania w konfiguracji 2 HAT i to działa. Szukałem jakiś przykładów i znalazłem pod tym linkiem http://forum.arduino.cc/index.php?topic=271306.0
Jest tam szkic dla joysticka F16 FLCS. Jest też opis dla HAT1
// Determine Joystick Hat Position
int angle = -1;
if (H1U) {
if (H1R) {
angle = 45;
} else if (H1L) {
angle = 315;
} else {
angle = 0;
}
} else if (H1D) {
if (H1R) {
angle = 135;
} else if (H1L) {
angle = 225;
} else {
angle = 180;
}
} else if (H1R) {
angle = 90;
} else if (H1L) {
angle = 270;
}
Joystick.hat(angle);Na początku jest tylko jedna deklaracja biblioteki #include <SPI.h>
Maciej stosuje u siebie biblioteki #include <Joystick.h> oraz #include <Wire.h>
Czy można w macieja szkicu zrobić funkcje dla jego HAT1 oraz HAT2 coś podobnego do przedstawionego powyżej programu. Może jest inny sposób realizacji HAT.
-
#include <SPI.h>
dołącza jedynie bibliotekę do obsługi interfejsu SPI, który do czegoś tam jest potrzebny (nie wnikałem głębiej).
My używamy tej biblioteki:
https://github.com/MHeironimus/ArduinoJoystickLibrary
Jak zwykle w przypadku niejasności co biblioteka oferuje idziemy do pliku nagłówkowego .h, albo do dokumentacji, którą udostępnił autor:
Joystick - adds a single joystick that contains an X, Y, and Z axis (including rotation), 32 buttons, 2 hat switches, a throttle, and a rudder.
Jak widać biblioteka udostępnia dwa HAT, a dostęp do nich jest poprzez fukncję:
Joystick.setHatSwitch(byte hatSwitch, int value)
Sets the value of the specified hat switch. The hatSwitch is 0-based (i.e. hat switch #1 is 0 and hat switch #2 is 1). The value is from 0° to 360°, but in 45° increments. Any value less than 45° will be rounded down (i.e. 44° is rounded down to 0°, 89° is rounded down to 45°, etc.). Set the value to -1 to release the hat switch.
Tymczasem uruchomiłem obsługę przycisków narazie na jednym MCP23017:
(http://i.imgur.com/Y971PMV.jpg)
Układ działa z wykorzystaniem przerwań generowanych przed MCP. Serial1, czyli ten drugi port szeregowy, dostępny na pinach D0 i D1 podłączony jest do modułu UART-Bluetooth HC-05, a ten podlądam programem PuTTy. Działa bez zająknięcia, nie traci połączenia po programowaniu procesora i nie blokuje działania joysticka w windows.
(http://i.imgur.com/6sPUSVp.png)
Guziki gotowe, to może teraz spróbuję dorobić dwa HATy, a potem wejścia analogowe.
-
Dzięki za tak szybką odpowiedź. Działasz bardzo szybko gratulacje. Muszę kupić modułu UART-Bluetooth HC-05, aby uwolnić się od problemów. Wykorzystanie przerwań ma sens, ponieważ reakcja jest natychmiastowa i MCP23017 ma taką możliwość.
-
Ponieważ kolega 3.14 ter projektuje tak jak wspomniał "mały projekt joysticka " to odpuściłem sobie pewne problemy związane z szkicem macieja. Chcę teraz zając się transmisją z wykorzystaniem modułu UART-Bluetooth HC-05 tak jak to zrobił 3.14 ter. Przejrzałem Internet i mam pytania. Podstawowe pytanie to napięcie po liniach RX, TX. Arduino wysyła poziomy napięć w pobliżu VCC (5V) a HC- 05 ma ograniczenia do 3.6V na odbiorze. Czy stosujesz jakiś konwerter napięć 5V na 3.3V czy po prostu łączysz Arduino z HC-05. Zakładam, że HC-05 zasilane jest z VCC (5V) z Arduino. Po stronie PC trzeba w USB włożyć jakiś układ nadawczo odbiorczy, czy jest to jakiś konkretny moduł.
Ponieważ mój SimOut pracuje z PC poprzez konwerter USB-RS232 to chciałbym zrobić test z Leonardo i połączyć RX, TX z konwerterem poziomów RS232 oraz wspomnianym konwerterem USB-RS232 z PC i zobaczyć czy będzie działać. Tutaj chyba potrzebuję program PuTTy, którego nie znam. Czy mogę prosić o opinię na ten temat.
-
http://www.putty.org/ - to nic innego jak klient telnetu i ssh :)
-
vito_zm - właściwie teraz jak wspomniałeś o poziomach napięć, zorientowałem się, że HC-05 chodził cały czas na 5V (TX&RX). Pewnie moja wersja ma jakieś dodatkowe rezystory szeregowe w liniach, które umożliwiły normalną transmijsę. Ale... Te moduły można kupić w co najmniej kilku wariantach, zależy co akurat mają na magazynie. Być może nie wszystkie będą odporne na 5V. Dla bezpieczeństwa można wpiąć rezystory 2k2 w szereg w linie TX i RX. Oczywiście najlepszym wyjściem byłoby zastosowanie konwertera poziomów.
Sam używam OLIMEXINO-32U4, bazuje na Leonardo i ma kilka dodatków, m.in przełącznik VCC między 5, a 3.3V.
To 3.6V w module HC05 jest minimalnym zalecanym napięciem zasilania. Na płytce modułu jest regulator napięcia 3.3V typu "low dropout", 0.3V wyżej potrzebne jest, żeby pracował poprawnie. W praktyce podłączałem go do 3.3V i też działał bez problemu.
Połączenie Leonardo->konwerterUART/RS232-------->RS232/USB->PC jest poprawne, będzie działać. PuTTy to po prostu klient, używamy go jako bardziej rozbudowanego monitora Serial. PuTTy potrafi symulować stare terminale typu V100, przez co, oprócz wysyłania gołego tesktu można używać go jako zdalnego wyświeltacza, ustawiać kolory, wyłączać kursor, przesuwać go itp.
Wracając do projektu. Zainspirowany jednym wątkiem na forum Teensy postanowiłem przepisać bilbiotekę "joystick" tak, aby obsługiwała do 128 przycisków, 6 analogowych osi 16bit, 17 analogowych suwaków 16bit i 4x HAT. Zobaczymy co z tego wyjdzie, praca w toku.
Znalazłem również ciekawy programik autorstwa jednego z tamtejszych forumowiczów: tester joystików wykrywający wszystkie dodatkowe osie, przyciski itp.
http://www.planetpointy.co.uk/joystick-test-application/
---
Zapomniałem dodać, naturalnie, po stronie PC trzeba mieć jakiś odbiornik Bluetooth (USB dongle), żeby komunikacja działała.
-
Zaczyna działać! Tester z linku z poprzedniego posta, ustawiony na RawInput, wykrył wszystkie wejścia logiczne i analogowe:
(http://i.imgur.com/lNriAte.png)
-
Robi się coraz ciekawiej.Teraz widzę co to znaczy mieć pojęcie o programowaniu. To co założyłeś jest super wygląda lepiej od MMJoy2. Co do przełączania 5V a 3.3V to na początku mojej przygody z ProMicro zauważyłem na schemacie uwagę oraz zworkę SJ1. Nie do końca rozumiem działanie tego układu MIC5219, ponieważ u mnie zworka jest rozwarta (nie polutowana), napięcie z USB to około 4.9V a w punkcie VCC 4.54V. Z tego wnioskuję, że układ MIC5219 nie daje 3.3V. Wejście RAW jest dla opcji zew. napięć. To taka dygresja na temat ustawiania napięć.
(http://i700.photobucket.com/albums/ww5/vito_zm/ProMicro-power.jpg) (http://s700.photobucket.com/user/vito_zm/media/ProMicro-power.jpg.html)
Chciałem zrozumieć jak to działa, ale się poddałem.
-
W przypadku, gdy nie wiadomo co konkretny scalak robi, najlepiej poszukać noty katalogowej:
https://cdn-shop.adafruit.com/product-files/3081/mic5219.pdf
MIC5219 to stablizator napięcia typu "Low Dropout". Dla tej konkretnej wersji na wejściu dostaje napięcie z zakresu ok 3.3V do 16V, a na wyjściu trzyma równe 3.3V.
Jeśli ProMicro jest chińskie, to wcale nie musi odpowiadać temu, co jest na oryginalnym schemacie.
Właśnie spojrzałem na jedno takie. Nie ma tam wcale zworki SJ1, a stablilizator jest na 5V.
Wygląda na to, że u Ciebie jest również stabilizator 5V. Zworka rozwarta, a więc napięcie wejściowe, w tym przypadku VUSB, idzie na wejście stabilizatora.
Stablilizator właściwie nie pracuje poprawnie. Napięcie wejściowe powinno być trochę wyższe od tego co ma być na wyjściu (LowDropout - znaczy, że ta wymagana różnica jest dość mała, kilkadziesiąt/kilkaset mV zazwyczaj, zwykłe stablilizatory jak LM7805 wymagają więcej, ok 2V). No więc zamiast stablilzować powoduje jedynie spadek napięcia koło 0.4V. Stąd wynika różnica między VUSB (4.9V), a VCC (4.54V).
Oczywiście to tylko moje domysły. Żeby powiedzieć coś więcej, musiałbym dokładniej obejrzeć płytkę.
Tymczasem sprawdziłem działanie wszystkich 128 przycisków i kilku osi. Niestety ten program do testowania to jednak alfa. Wieszał się nagminnie.
Widze, że jakimś cudem wysłałem poprzedniego posta podczas jego pisania... proszę o usunięcie.
-
Masz rację z tym stabilizatorem, nie wiadomo co tam włożono, ponieważ nie można odczytać napisu na scalaku. ProMicro u mnie jest tylko dla testów MMJoy2 i dlatego wartość VCC nie ma dla mnie znaczenia.
Co do modułu HC05 to zamawiam przez Internet i połączę szeregowo tak jak sugerujesz rezystory tak aby zredukować napięcie, może to wystarczy. Zanim dostanę HC05 to sprawdzę na moim konwerterze USB->RS232 plus konwerter poziomów na TTL i zobaczę jak działa monitoring.
Jeśli chodzi o tester joysticka dla przycisków oraz HAT to w MMJoy2 są dołączone testery do sprawdzania analogów oraz wspomnianych przycisków (4 HAT oraz 128 przycisków). Testery działają niezależnie od platformy (setup) MMJoy2. Jest to na zdjęciu dla mojego modelu.
W okienku można wybrać joystick jeśli mamy ich kilka (u mnie są 3). Program nazywa się WKB_Btn Tester
(http://i700.photobucket.com/albums/ww5/vito_zm/m_test-joy-macieja.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_test-joy-macieja.jpg.html)
Zajac mam do Ciebie prośbę. Czy możesz pokazać kod dla Arduino, który realizuje sterowanie enkoderów korzystając z biblioteki rotary.h. Chciałbym to sprawdzić na moim modelu.
-
A istnieje jakiś program, który będzie w stanie widzieć więcej analogowych osi niż to ustawa, tzn. DirectX przewiduje?
Ten tester z linku, który podałem wykrywa ilość dostępnych osi, ale w trybie RAW kompletnie mi się zawiesza. Nie wiem jeszcze, czy to wina mojej biblioteki, czy programu.
Być może implementacja aż tylu osi nie ma sensu, bo i tak większość simów tego nie wykryje?
W każdym bądź razie standardowe osie są 16 bitowe i działają. Przyciski i HATy również sprawdziłem testowym generatorem zdarzeń.
Kolejne spostrzeżenie:
zauważyłem, że są problemy z działaniem USB w trybie autoSendStatus, zwłaszcza gdy skanuję osie przy pomocy ADC. Pewnie HID, albo jego implementacja w Arduino nie nadąża z nadawaniem pakietów. Raczej usunę tą opcję z biblioteki. Znacznie lepszym rozwiązaniem będzie zczytanie wszystkich wejść, zaktualizowanie pakietu HID i jednokrotne wysłanie go do PC.
Pewnie da się dopisać jakieś zabezpiecznie, ale tak głęboko nie wnikałem jeszcze w bilbioteki USB dla Arduino. To dopiero drugi projekt jaki robię w tym środowisku.
Dopiszę jeszcze parę brakujących funkcji i udostępnię całość do testów, wraz z przykładowym programem czytającym przyciski z jednego/dwóch MCP23017.
-
Biblioteka wraz z jednym przykładem testowym dostępna jest pod tym linkiem:
MegaJoystick (https://github.com/hexeguitar/MegaJoystick)
Jedyna dodatkowa biblioteka, jaka jest wymagana to BasicTerm (https://github.com/nottwo/BasicTerm).
W tej chwili program wykorzystuje tylko jeden MCP23017, ale w prosty sposób można to rozszeszyć.
Analogowe osie podłączyłem do wejść A0-A3.
HATy przetestowane są narazie programowo, chwilowo nie zaimplementowałem ich jeszcze w programie. Obsługa oczywiście jest.
AutoSendStatus jednak działa poprawnie. Pewnie miałem błąd gdzieś indziej. Dodałem funckję do włączania i wyłączania AutoSend. Oryginalnie można to było zrobić jedynie podczas inicjalizacji obiektu Joystick.
Przydaje się to np., gdy skanujemy 128 przycisków. Wysyłanie całego pakietu HID dla każdego przycisku z osobna nie ma sensu. Lepsze rozwiązanie wg mnie to wyłączyć AutoSend, odczytać i uaktualnić przyciski, wysłać pakiet ręcznie i potem włączyć AutoSend z powrotem.
MCP23017 skonfigurowane jest do sygnalizacji zmian na wejściach przez przerwania INTA i INTB. Te z kolei ustawione są jako wyjścia z otwartym kolektorem. Dzięki temu można po prostu połączyć razem wszystkie wyjścia INT z kilku scalaków i podpiąć do D6 w Leonardo. Jeśli któreś z wejść zmieni stan, procesor i tak odczyta wszystko od nowa. Zaoszczędzamy na pinach procesora, przydadzą się do czegoś innego.
Starałem się komentować kod, tak, żeby był zrozumiały i łatwy do adaptacji. Byłoby fajnie, gdyby ktoś z Was przetestował go we własnym systemie i ew. dał znać czy są jeszcze jakieś błędy.
-
A ja mam pytanie, skąd kolega ma ten ciemny motyw w swoim Arduino IDE? Czy to jakieś inne środowisko?
-
Notepad++
W Arduino w ustawieniach zaznaczamy użycie zewnętrznego edytora. Skrypt otwieramy w Arduino IDE, a edytujemy w Notepad++. Po każdorazowym zapisaniu w Notepadzie Arduino automatycznie odświeża sobie plik. IDE służy tylko do kompilacji i wgrywania programu do procka.
Do większych projektów, które podzielone są na kilka plików używam Platformio IDE:
http://platformio.org/platformio-ide
To już w ogóle bajka w porównaniu to oryginalnego edytora Arduino.
Być może w obecnej wersji już to poprawili, ale po zainstalowaniu w Win7 musiałem dodać ścieżkę do zmiennych systemowych (PATH), żeby kompilacja w ogóle ruszyła.
-
Wgrałem biblioteki i próbowałem kompilować przykład, ale otrzymałem error (na zdjęciu). Jutro połączę INT do Leonardo i zrobię test jeśli wyjaśni się problem mojego "error". Nie mam jeszcze HC05, czy mogę zrobić prowizorkę z konwerterem USB->RS232 o którym pisałem poprzednio. Mam aktualnie zrobiony model z dwoma MCP23017 i mogę podłączyć analogi do Leonardo. Chętnie włączę się do testowania programu.
(http://i700.photobucket.com/albums/ww5/vito_zm/MegaJoy%20error1.jpg) (http://s700.photobucket.com/user/vito_zm/media/MegaJoy%20error1.jpg.html)
-
Pomieszałem wersje, na GitHubie wylądowała nie ta, co trzeba. Teraz powinno być ok.
-
Czołem,
Panowie, to jest to! Niedawno przyszły dwa układy ProMicro od chinola. Nie miałem kiedy przetestować paczki ale dobrze się stało :). Wkładka jest o wiele bardziej interesująca. Dzięki 3.14ter za wkład!
-
Witam
To kod szkicu od encoderów
#include <Rotary.h> // biblioteka do encoderów
#include <Bounce2.h> // biblioteka dla przycisków eliminująca drganie styków
int led01 = 10; // pin diody LED
int led02 = 11; // pin diody LED
int led03 = 6; // pin diody LED
int but01 = 9; // pin przycisku
bool but01_st = false; // stan przycisku 1
int d = 5; // dlugosc impulsu zapalenia diody
Bounce debouncer = Bounce(); // inicjalizacja biblioteki
Rotary rot01 = Rotary(7, 8); // piny encodera 1
void setup()
{
Serial.begin(9600); // inicjalizacja serial monitora
pinMode(led01, OUTPUT); // ustawienie pinu diody led01
pinMode(led02, OUTPUT); // ustawienie pinu diody led02
pinMode(led03, OUTPUT); // ustawienie pinu diody led02
pinMode(but01, INPUT_PULLUP); // ustawienie pinu przycisku encodera
debouncer.attach(but01); // inicjalizacja biblioteki debouncer dla przycisku encodera
debouncer.interval(20); // ustawienia dla debouncer - długość opóźnienia
}
void encoder01 () // funkcja dla odczytu encodera
{
unsigned char result01 = rot01.process(); // odczyt stanu ecodera i przypisanie do zmiennej result01
if (result01 == DIR_CW ) { digitalWrite(led01, HIGH); delay(d); } // jeżeli encoder w prawo zapala diode 1 plus male opoznienie żeby było widać
else { digitalWrite(led01, LOW); } // jeżeli nie gasi diodę
if (result01 == DIR_CCW ) { digitalWrite(led02, HIGH); delay(d);} // jeżeli encoder w lewo zapala diode 2 plus male opoznienie żeby było widać
else { digitalWrite(led02, LOW); } // jeżeli nie gasi diodę
if (result01) // jeżeli encoder jest obracany
{
Serial.println(result01 == DIR_CW ? "Right" : "Left"); // wysyła na serial monitor tekst w zaleźności od kierunku
}
}
void przycisk01 () // funkcja przycisku na encoderze
{
debouncer.update(); // sprawdzanie czy przyciśnięty
if (debouncer.fell()) { but01_st = !but01_st; } // jeżeli tak - wykrywa zbocze i zmienia zmienną but01_st na przeciwny
if ( but01_st == true ) { digitalWrite(led03, HIGH); } // zapala diodę w zależności od stanu zmiennej but01_st
else { digitalWrite(led03, LOW); }
}
void loop() // główna pętla programu
{
encoder01();
przycisk01();
}
Starałem się wszystko opisać w komentarzach. To kod jaki napisałem jakiś czas temu, więc można jeszcze go poprawić, ale obsługa encodera a dokładnie biblioteki jest ok. W szkicu jest też obsługa biblioteki eliminującej drgania styków- Bounce2.h. Sorry za opóźnienie, ale jestem poza Warszawą - wracam za parę dni to będę bardziej dostępny. Jakby co to pytajcie.
pozdrawiam Zając
-
Byłem na urlopie ale już wracam do żywych.
Co do mojego skryptu - nie mam na tyle doświadczenia żeby go odpowiednio zoptymalizować ale realizuje potrzebne mi funkcje. :(
Co do HAT'ów - testowałem tą funkcję u siebie ale nie działała poprawnie - haty się blokowały, reagowały z opóźnieniem albo reagował tylko jeden kąt. Podejrzewam, że jest to kwestia optymalizacji ale skoro działa na zwykłych przyciskach to już nie będę się z tym bawił, bo mam dużo innej pracy z kokpitem.
Wyciąganie danych z BMS:
Korzystałem z tego tutoriala do podjęcia tematu:
https://www.youtube.com/watch?v=lW0JXoOFTjo
Myślę, że przechwycenie programem okienkowym napisanym w C# i wysłanie do portu szeregowego nie powinno być większym problemem.
Póki co zdążyłem jedynie pobawić się kontrolką i wyświetlaniem czy faktycznie przechwytuje i przechwytuje. :)
-
A HATswitche jakie wykorzystujecie? te mikro switche? Mi się zamarzyły haty z dużym wychyleniem. Jedyne co znalazłem to te popularne minijoysticki jak z gamepadów.
Ponieważ tworzę nową elektronikę dla mojego joya - to mam teraz dostępne min. 16 wejść analogowych.
Podpiąłem więc analogowe joysticki jako 4kierunkowy hat switch. I działa.
Kod trochę siermiężny, ale działa. Jak ktoś ma pomysł jak to zoptymalizować to śmiało:
//obsługa pierwszego hata
potHat1LR= muxShield.analogReadMS(3, pin_Hat1LR);
potHat1UD= muxShield.analogReadMS(3, pin_Hat1UD);
if (potHat1LR > hatProgD and potHat1LR < hatProgG){
hat1LR_Wychyl=0;
} else {
if (potHat1LR >hatProgG) {
hat1LR_Wychyl=1;
Joystick.setHatSwitch(0,hatRight);
hat1Kierunek="Prawo";
} else {
if (potHat1LR <hatProgD) {
Joystick.setHatSwitch(0,hatLeft);
hat1Kierunek="Lewo";
hat1LR_Wychyl=1;
}
}
}
if (potHat1UD > hatProgD and potHat1UD < hatProgG){
hat1UD_Wychyl=0;
} else {
if (potHat1UD >hatProgG) {
hat1UD_Wychyl=1;
hat1Kierunek="Gora";
Joystick.setHatSwitch(0,hatUp);
} else {
if (potHat1UD <hatProgD) {
Joystick.setHatSwitch(0,hatDown);
hat1Kierunek="Dol";
hat1UD_Wychyl=1;
}
}
}
if ( hat1LR_Wychyl==0 and hat1UD_Wychyl==0){
Joystick.setHatSwitch(0,-1);
hat1Kierunek="Srodek";
}
(http://www.mcd.ayz.pl/rozne/joy_zdjecia/nowa_elektronika.jpg)
-
Dzięki koledzy za włączenie się do tego wątku. Jest szansa, że kolega 3.14ter zaprojektuje sterownik (joystick), który będzie bardzo przydatny przy budowaniu kokpitów lub paneli dla symulatorów. Z tego co napisaliście wynika, że każdy stara się na własna rękę lepiej lub gorzej napisać dla swoich potrzeb szkic. Teraz jest szansa wymiany doświadczeń. Eksperymentowanie jest czasochłonne i może prowadzić do zniechęcenia.
Wracając do tematu. Szkic 3.14ter już działa w sensie kompilacji. Teraz połączę przerwania i wgram do kości. Powinien działać w moim testerze przycisków z MMJoy2. Następnie połączę konwerter USB->RS232 i sprawdzę monitorowanie. HC05 dopiero zamawiam. Dziękuje shopiK za szkic. Dzięki maciej za tutorial, to będzie następny temat do rozeznania. Dam znać jak działa szkic 3.14ter .
-
Ja robiłem pod Cougara a tam są microswitch'e.
-
shopiK
HATy z dużym wychyleniem? Wpadłem na taki pomysł (Twój software -> hardware): przy pomocy dość prostego układu można przerobić minijoystick na przełączniki.
Tak sobie myślałem: i tak trzeba jakoś mechanicznie zamontować ten minijoystick, raczej będzie to płytka + jakieś dystanse. A skoro już robimy płytkę, to można tam od razu wrzucić parę elemntów, które przetworzą analogowe sygnały na wyjścia logiczne. Do tego, wyprowadzając sygnał "Common" (patrz niżej na schemacie), można zastosować multipleksowanie. 4 Haty będą zajmować 8 pinów mikrokontrolera. Tyle samo co w wersji z liniami analogowymi, ale mogą to być dowolne wejścia logiczne, których zazwyczaj jest więcej. Wyjścia TOP,BOTTOM,LEFT,RIGT połączone są razem (komparatory mają wyjścia typu otwarty kolektor, można je sumować), to daje 4 piny. Wyjścia COMMON z każdego z HATów podłączamy do kolejnych 4 pinów. I teraz w programie:
COMMON1 = 0, reszta = 1 -> aktywny jest HAT 1, odczytujemy 4 linie Top itd.
COMMON2 = 0, reszta = 1 -> aktywny jest HAT 2, j.w.
itd. dla wszystkich 4 HATów.
Zasada działania jest bardzo prosta. Jeśli do suwaka potencjometru podłączymy masę, a oba końce "podwiesimy" przez resystory do VCC, to np. przesuwanie joysticka do góry będzie zmniejszać napięcie na linii TOP. Jeśli poziom będzie dość niski (ustalony przez dzielnik 10k-1k i podany na wejścia "-" ) komparator to wykryje i zewrze wyjście TOP_OUT do masy. Czyli zrobi dokładnie to co zrobiłby microswitch w klasycznym HAT.
Schemat wyglądałby mniej więcej tak:
(http://i.imgur.com/WwAV2F4.png)
Naturalnie muszę to sprawdzić jeszcze w praktyce.
-
Sprytna bestia jesteś :-)
-
Pytanie do 3.14ter dotyczy pin w Leonardo do którego mają być połączone przerwania INT. Napisałeś D6 a ja nie widzę takiego oznaczenia na schemacie. Ponieważ INT są konfigurowane jako otwarty kolektor to czy wejście w Leonardo jest na pullup.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Leonardo-pin.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Leonardo-pin.jpg.html)
-
Ach, znowu literówka. Już poprawione. To ma być D7:
(http://i.imgur.com/9adZ3Yr.png)
D7 trzeba ustawić jako wejście i wpisać 1 (pullup). Samo włączenie przerwania INT6 zrobione jest metodą klasyczną, przez działanie bezpośrednio na rejestrach.
Widzę właśnie, że Arduino przewiduje tam INT4. No i tak właśnie bywa z platformami wymyślonymi do błyskania LEDami dla artystów. W rzeczywistości, wg dokumentacji, na tym pinie jest INT6. Arduino ponumerowało sobie to po swojemu.
Jeszcze uwaga do używania tego przerwania: procesor potrafił się zawiesić, jeśli przerwania były zgłaszane bardzo szybko. Rozwiązałem to w ten sposób, że przerwanie zgłasza jedynie flagę, że są nowe dane i wyłącza się. Program główny sprawdza sobie flagę w pętli. Jeśli jest ustawiona, odbiera nowe dane z MCP23017, kasuje flagę i ponownie włącza INT6.
-
Panowie, chyba będzie mała zmiana planów.
Zacząłem szukać jakichś sensownych (niedrogich i dostępnych) przetworników AD dla bardziej precyzyjnych osi. Nie wygląda to za dobrze.
Cena takiego przetwonika będzie większa od całości płyki. Nie tędy droga.
Dlatego doszedłem do wniosku, że czas zmienić platformę na coś poważniejszego niź Arduino.
Mianowicie coś takiego:
http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and
(http://i.imgur.com/GUQjtJS.jpg)
Zalety:
- koszt ok. 10$,
- wbudowany programator/debugger,
- darmowe IDE (PSoC Creator),
- dość wypasiony procesor Cortex M3 z natywnym USB2.0, ale nie to jest najważniejsze,
- ultra elastyczna 32 bitowa architektura, zamiast zestawu peryferii posiada 24 uniwersalne bloki, z których możemy zbudować sobie dowolne moduły typu I2C, UART itd.,
- 20bitowy ADC na pokładzie (!),
- drugi 12 bitowy ADC na pokładzie,
- remapowanie pinów, tylko niektóre są na stałe przypisane do funkcji, resztę można sobie poustawiać do woli,
- a wszystko konfiguruje się graficznie.
Spróbowałem właśnie skonfigurować moduł USB wg napisanej wcześniej biblioteki dla Leonardo... i działa. System wykrył płytkę jako joystick.
Następnie spróbowałem ile funkcji sprzętowych będę mógł upadkować w procesor:
(http://i.imgur.com/KaXd67f.png)
Rezultat:
- 8 analogowych osi w pełnych 16bitach,
- 15 analogowych osi 12bit (przesunie się do 16),
- 2 sprzętowe wejścia dla enkoderów, z odkłócaniem i innymi bajerami,
- I2C - ten wykorzystamy do podłączenia MCP23017 i obsługi przycisków. Myślę, że nie warto marnować pinów w procesorze na tak trywialne rzeczy, jak guziki,
- UART i SPI jako okna do świata zewnętrznego i dalszej eskpansji (np. moduły z dodatkowymi enkoderami).
Chyba trzeba będzie założyć nowy wątek o tym projekcie, z Arduino nie będzie miał już nic wspólnego.
-
Dzięki za wyjaśnienie. Dla pewności na ATMEGA32U4 pin1 (D7) jest wyprowadzone na pin 7 DIGITAL pcb (moje zdjęcie). Podobnie czy RX to pin0 a TX to pin 1 na zdjęciu pcb Leonardo. Z SCL oraz SDA nie ma problemu. Pullup dla wejścia INT pin 7 pcb Leonardo zrobiłeś programowo. Czy muszę w związku z "pomyłką literówki" wgrać nowy program.
-
Nie trzeba nic wgrywać. Błąd był tylko w opisie. Kod jest w porządku.
-
Jesteś fachowcem i wiesz najlepiej co ma sens. W takim układzie to faktycznie pozostaje założyć nowy wątek. Moje możliwości intelektualne są ograniczone, ale chętnie piszę się jako tester. Może na forum znajdą się partnerzy do aktywnej dyskusji.
-
Gratulacje 3.14ter model pracuje poprawnie na Twoim szkicu, oczywiście tylko dla jednego MCP23017. Testowałem programem WB_Btn Tester. W związku z nową propozycją czekam na decyzje tzn. co mam kupić, aby można było testować nowy projekt. Czy moduł HC05 dla monitorowania mam zamówić. Nie testowałem analogów, czekam na decyzje co dalej.
-
Żeby uruchomić odczyt z drugiego MCP wystarczy odkomentować linie
280 - inicjalizacja
143 - odczytanie stanów wejść i wpisanie je do banku przycisków pod adres 1
HC05 generalnie może być bardzo przydatny w wielu sytuacjach. Dobrze jest mieć coś takiego w szufladzie. Ja zamówiłem ich kilka szt. i przekonfigurowałem na różne prędkości, 9600, 115200 i inne, żeby za każdym razem tego nie robić jak zajdzie potrzeba.
Do nowego projektu potrzebny będzie ów kit: CY8CKIT-059. Niestety nie wiem jak z dostępnością w PL. Ja zamawiałem go u Mousera, podejrzewam, że więksi dystrybutorzy jak Digikey, Farnell/Element14 powinni je mieć.
-
Otóż jest dostępny w miarę rozsądnej cenie:
http://pl.mouser.com/ProductDetail/Cypress-Semiconductor/CY8CKIT-059/?qs=PhR8RmCirEblciDRmpiVDw%3d%3d
http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and
http://pl.farnell.com/cypress-semiconductor/cy8ckit-059/dev-brd-cy8c5888lti-psoc-5-prototyping/dp/2476010
Czekam na wypłatę i nabywam :)
-
Zrobiłem zgodnie z sugestią 3.14ter i mam dostęp do 2 MCP23017. Teraz pozostaje sprawdzić analogi i czekać na kit CY8CKIT-059. Zgodnie z sugestią golasa zamówię pod jednym z podanych linków. Możliwości tego kitu wydają się bardzo atrakcyjne. Jest to przejście jakby na wyższy poziom. Ja się na to piszę, ale prawda jest taka, że projekt zależy wyłącznie od umiejętności 3.14ter. Moja rola to tak jak wspomniałem rola testera.
-
Projekt MegaJoy jest bardzo dobrym projektem i może być stosowany w budowie kokpitów. Kolejny projekt jest bardzo ambitny i jeśli się uda to będzie to kolejny bardzo dobry projekt, ale już z górnej półki.
Chciałbym dokończyć moje testy z projektem MegaJoy.
Co trzeba zrobić aby spełnił założenia napisane w komentarzu szkicu.
1.Dostęp do 128 wejść.
Aby mieć dostęp do 128 wejść trzeba dopisać pozostałe 6 rejestrów MPC3-6 tak jak dla MCP1, MCP2.
Adresy np.:
const int MCP1_SLAVE_ADDR = 0x20;
const int MCP2_SLAVE_ADDR = 0x27;
//....
const int MCP8_SLAVE_ADDR = 0x26;
Odczyt:
btnBank[0] = readMCP23017(MCP1_SLAVE_ADDR);
btnBank[1] = readMCP23017(MCP2_SLAVE_ADDR);
// ...
// btnBank[7] = readMCP23017(MCP8_SLAVE_ADDR);
Odblokować pozostale zakresy 32-128
for (i=1; i<16; i++)......
Dopisać inicjalizację dla MCP3-8 tak jak dla MCP1,2:
initMCP23017(MCP1_SLAVE_ADDR);
initMCP23017(MCP2_SLAVE_ADDR);
//...
initMCP23017(MCP8_SLAVE_ADDR);
2. Wejścia analogowe.
W założeniach jest 6 16 bit osi. 3.14ter sugerował, że program jest przygotowany na 4 osie od A0 do A3. Podłączyłem swój zestaw w następujący sposób. Joystick ośX na A0, ośY na A1, pot2 na A2 oraz pot1 na A3. Sprawdziłem na testerze analogów i działa to dosyć dziwnie podwójnie:
A0 ośX oraz obrót X A1 ośY oraz obrót Y A2 ośZ oraz obrót Z A3 oba słupki suwaka
Trzeba to sprawdzić.
3. Ostatnia sprawa to 4 HAT.
Czy mogę prosić o wyjaśnienie co z HAT1-4.
Co do mnie to mam zamiar zabrać się za monitorowanie MegaJoy.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_test%20MegaJoy.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_test%20MegaJoy.jpg.html)
-
Osie zaprogramowałem tak, żeby sprawdzić czy wszystkie działają, mając tylko 4 potencjometry do dyspozycji. Stąd niektóre są sprzężone. Ten skrypt to tylko taki test czy w ogołe wszystko działa i nadaje przez USB do PC. Nie jest pełnym programem joysticka.
W pętli głównej od komentarza "//analog inputs" zaczyna się przypisywanie osi.
Żeby odczytać oś analogową należy:
- podłączyć suwak potencjometru do któregoś z wejść analogowych
- wpisać oś od razu jedną instrukcją (np. dla osi X):
Joystick.setXAxis(analogRead(numer wejścia analogowego)<<6);
To "<<6" - przesunięcie w lewo 6 bitów to inaczej napisany iloczyn wynik*2^6, czyli *64. Wejścia ADC w AVR są 10 bitowe, a pełny zakres osi wysyłanej przez USB ma 16 bitów.
HATy
Obsługuje się je funkcją:
Joystick.setHatSwitch(numer HATa 0..3, położenie w stopniach 0...360 lub -1 dla OFF);
Położenie trzeba sobie wyliczyć samemu na podstawie rodzaju użytego HATa.
Muszę przyznać, że tą część przetestowałem najmniej (tylko generując różne wartości programowo). Akurat nie mam nic pod ręką, co mogłoby posłużyć za taki przełącznik. Tu mogą być jeszcze jakieś niespodzianki.
Zastanawiam się też czy używanie ustawienia w stopniach w ogóle ma sens. Ta wartość i tak zapisywana jest jako liczba 4 bitowa. Może od razu lepiej przyjąć docelowe wartości 0-8 odpowiadające położeniom góra, góra+prawo, prawo itd.
Czego nie było w pierwotnej bibliotece, a jest w mojej to dodatkowe funkcje do odczytywania wartości, np.:
Joystick.getXAxis(); zwraca uktualną wartość osi
Dlaczego tak? W celu oszczędzenia RAMu i dla bezpieczeństwa. Zmienne przechowujące wszystkie parametry joysticka są prywatne i reszta programu do dostęp do nich tylko poprzez odpowiednie funkcje. Te funkcje przydają się podczas monitowania działania joysticka przez UART:
uint16_t osX;
osX = Joystick.getXAxis();
term.print(F("Wartosc osi X="));
term.print(osX);
-
Osie działają prawidłowo, zrobiłem tak jak sugerowałeś. Z HAT poczekam, ponieważ też nie mam hat tylko przyciski. HAT-y podłączamy na wejście rejestru, czyli zmniejszamy liczbę dostępnych przycisków o 4 dla 1 HAT. Program, który używam do testów ma 2 HAT, czy ten który testowałeś z 4 HAT jest stabilny czy raczej nie.
-
Więc myślę, że o wiele praktyczniej będzie przepisać funkcję setHatSwitch, żeby jako argument przyjmowała stany przycisków Góra, Prawo, Lewo, Dół.
Wtedy będzie można po prostu wrzucić tam stany odczytane z MCP, bez niepotrzebnego przeliczania to na kąty.
Nawiasem mówiąc, czytając na forum o użyciu czujników Halla w joystickach przyszedł mi do głowy kolejny pomysł. Regulowanie zakresu poprzez zmianę rodzaju magnesów nie jest zbyt wygodne. Chyba powstanie kilka niewielkich, acz bardzo ułatwiających życie (budowę kokpitów znaczy się) gadżetów.
Ale to później.
-
Robiłem próby z konwerterem USB->RS232, ale pojawiły się problemy, dlatego zamawiam moduł bluetooth HC05. Znalazłem pod tym linkiem
https://botland.com.pl/moduly-bluetooth/2569-modul-bluetooth-hc-05-ze-zlaczami.html
Muszę także kupić odbiornik bluetooth i tutaj mam pytanie jaki, ponieważ ceny się znacznie różnią.
MegaJoy już pracuje z 6 osiami i teraz tylko potrzeba monitoringu oraz HAT. CY8CKIT-059 także zamówię, ale pod innym linkiem.
-
Vito jeżeli znalazłeś taniej to może podzielisz się informacją gdzie można zakupić za mniejsze pieniądze:)
-
U mnie po otwarciu linku z ostatniego mojego wpisu na dole są inne produkty i tam są odbiornik bluetooth od 8.50 zł do 60 zł. CY8CKIT-059 jeszcze nie sprawdzałem.
Wtedy będzie można po prostu wrzucić tam stany odczytane z MCP, bez niepotrzebnego przeliczania to na kąty.
Chciałbym nawiązać do tego cytatu. U mnie w drążku Cougara są 4 HAT-y gdzie ten od widoków teoretycznie powinien mieć 8 pozycji a praktycznie ma 4. Nie rozumiem różnicy pomiędzy 4 przyciskami na 4 kierunkach a HAT 4-kierunkowym. HAT-y także w sensie elektrycznym są przyciskami chyba, że jest inaczej. Może mi to ktoś wyjaśnić. Umieszczenie 4 przycisków na 4 kierunkach odpowiada położeniom kątowym czyli po co przeliczać kąty. Może czegoś nie dostrzegam.
-
Będzie kilka nowych funkcji w bibliotece do Arduino, głównie do szybszej obsługi przycisków i HATów.
Funkcje w pierwotnej bibiotece obsługują przyciski pojedynczo. W przypadku, kiedy jest ich sporo i jak u nas, są zgrupowane w 8 bitowe banki dzięki użyciu MCP23017, zamiast na piechotę sprawdzać każdy bit z osobna i ustawiać przyciski jeden za drugim, można po prostu wkopiować owe 8 bitów w odpowiednie miejsce.
Piszę właśnie dwie nowe funkcje, jedna jako argument przyjmować będzie 8 bitowy bajt ze stanami wejść. Przyda się dla różnorakich 8bitowych rejestrów przesuwnych, czy PCF8574. Trzeba tylko pamiętać o odwróceniu bitów, 1 oznacza przycisk wciśnięty. MCP23017 robi to automatycznie.
Druga funkcja, jako argument przyjmować będzie jedno słowo 16bitowe, specjalnie dla MCPka. Wystarczy podać tylko numer banku 0-15 (128 przycisków podzielone jest na 16 banków po 8 przycisków) i zmienną zwracanę przez f-cję readMCP2301.
HATy - pełny zestaw 4 szt. zajmie całego MCP. A skoro tak, to wygodniej będzie mieć funkcję typu "ten MCP odpowiedzialny jest tylko za HATy, odczytaj wszystko i poustawiaj tak, żeby działało".
Jeśli chodzi o ilość kierunków w HATach to to, co napiszę to tylko moje hipotezy, być może mylne.
Od strony sprzętowej HAT to po prostu 4 przyciski, które są w stanie wskazać 8 kierunków. W paczce danych, która wysyłana jest do komputera jeden HAT zajmuje 4 bity.
Jeśli działają tylko 4 kierunki, to możliwe, że problem leży po stronie programu, a ściślej deksryptora HID. Tam ustala się dokładnie ile i jakie dane będą nadawane.
-
W moim skrypcie próbowałem to robić w ten sposób, że jeżeli pojawiały się dwa sygnały np. prawo - góra to był to kąt 45 stopni, prawo 90, dół - prawo 135, dół 180, dół- lewo 225, lewo 270 i góra-lewo 315. Nie działało to wtedy poprawnie ale jakaś ścieżka pewnie do tego prowadzi.
-
.... jeżeli pojawiały się dwa sygnały np. prawo - góra to był to kąt 45 stopni, prawo 90, dół - prawo 135, dół 180, dół- lewo 225, lewo 270 i góra-lewo 315.
Faktycznie teraz kojarzę jak mogą działać HAT-y. Gdy robiłem metodą domową DCS w ICP to specjalnie zrobiłem prowadnicę w kształcie krzyża aby nie zwierały sąsiadujące przyciski. Tutaj mają zwierać dając dodatkowe 4 kąty.
-
Ufff... HATy działają. Dawno nic nie robiłem na AVR i pan Murphy uprzejmnie przypomniał (w postaci godziny zastanawiania się dlaczego wychodzą głupoty), że dostęp do stałych zapisanych we Flashu wymaga specjalnych funkcji. Jutro wrzucę nową wersję na Github.
(http://i.imgur.com/bUdqpE2.png)
4 HATy można podpiąć pod jednego MCP23017 i odczytać je jedną linijką.
-
Gratulacje i pytania, mam 2 MCP23017 oraz 16 przycisków tak jak na zdjęciach mojego modelu. Pytanie jak symulować HAT. Jeśli założę, że A0 to kierunek N, A1 E, A2 S oraz A3 to W, to naciśnięcie przycisków A1 oraz A2 powinno dać 135 stopni tak jak w Twoim przykładzie. Kolejne pytanie czy jest w programie przypisywanie dla wejść A0-A7, B0-B7 kierunków N,E,S oraz W dla 4 HAT.
-
No i ja tu wdepnę.... Będę miał na swoim panelu kontrolki podwozia, dzwignię podwozia i już gotowe wyłączniki pożarowe. Te w czasie działania odpowiednio się podświetlają i to chcę też mieć w swoim kokpiciku. Wiem, że za pomocą Arduino mogę to osiągnąć tylko nie wiem jeszcze jak i co. Myślę o nabyciu Arduino Mega, kontrolki będą diodowe, tylko nie wiem czy mogą być na 12V ? No i sam nie wiem co jeszcze będzie mi potrzebne, zapewne jakiś soft, bo jakoś trzeba zgrać działanie kontrolek w grze z tymi na kokpicie. Oczywiście przeczytam ten temat cały parę razy, tylko nie wiem czy ze zrozumieniem...
-
Padonis jak chcesz to możesz użyć kontrolek nawet na 230V :) kwestia dobrania jedynie przekaźników (ja osobiście preferuję dodatkowo optoizolację) :)
W projekcie trawiarki użyłem MOC3041 (http://www.elektroda.pl/rtvforum/viewtopic.php?p=13490774#13490774 | http://www.elenota.pl/?search=MOC+3041).
Ale tutaj myślę wystarczy Ci w zupełności przekaźnik 12V (np. NT73 12V) i jakiś tranzystor i gotowe :) Kwestia softu który wyłapie Ci w grze status i zada stan wysoki/niski na odp. porcie :)
Swoją drogą jak tak patrzę na to co robi 3.14ter to utwierdzam się w przekonaniu, że na 1-2 uC (odpowiednio mocnych) wraz z technologiami SPI/I2C dałoby radę zbudować cały kokpit używając prócz tych 2 x uC kolejnych bramek, rejestrów etc. :P
-
Ponieważ nie mam jeszcze HC05 to powróciłem to układu Leonardo wyjście Tx -> wejście MAX 232 -> konwerter RS232->USB oraz pc.
Połączenie Leonardo->konwerterUART/RS232-------->RS232/USB->PC jest poprawne, będzie działać. PuTTy to po prostu klient, używamy go jako bardziej rozbudowanego monitora Serial. PuTTy potrafi symulować stare terminale typu V100, przez co, oprócz wysyłania gołego tesktu można używać go jako zdalnego wyświeltacza, ustawiać kolory, wyłączać kursor, przesuwać go itp.
Połączyłem tylko TX z Leonardo i uruchomiłem program Terminal v.1.9b ustawiając go na 115200, 8 bit oraz 1 STOP, ale nie odbiera. Czy muszę zainstalować program PuTTy aby odbierać dane z MegaJoy.
-
golas->
Dokładnie, system modułowy, który można rozbudowywać, ograniczony tylko ilością danych, które możemy upchać w jedną ramkę danych HID (64 bajty).
Tymczasem jest spory update biblioteki (https://github.com/hexeguitar/MegaJoystick).
Dotyczy głównie HATów. W sumie można je podłączyc i ustawiać na 5 różnych sposobów:
- podając kąt ustawienia - to przyda się, gdy ustawienie HAT będzie z innego źródła niż przyciski, jakieś zewnętrzne dane nadawane w takim formacie,
- podając bezpośrednio numery pinów do których podłączony jest HAT. Przydatne, gdy jest jedna szt. i wykorzystuje się pomieszane, akurat wolne piny w Arduino,
- dwa HATy podłączone do jednego 8 bitowego portu, np. połówki MCP23017,
- cztery HATy jednocześnie, zastostowanie głównie z 16 bitowymi ekspanderami, jak MCP23017,
- na koniec wisienka - dopisałem funkcję obsługi HATa przez analogowy mini joystick. Wykorzystuje dwie linie analogowe. Można skonfigurować próg załączenia, tzn. ile trzeba wychylić, żeby zadziałało to jako wciśnięcie przycisku.
(https://github.com/hexeguitar/MegaJoystick/blob/master/schematics/MegaJoystick_HAT.png?raw=true)
W programie przykładowym są różne opcje testowania HATa. Wystarczy odkomentować jedną z linijek i przekompilować program.
-
Ponieważ nie mam jeszcze HC05 to powróciłem to układu Leonardo wyjście Tx -> wejście MAX 232 -> konwerter RS232->USB oraz pc.Połączyłem tylko TX z Leonardo i uruchomiłem program Terminal v.1.9b ustawiając go na 115200, 8 bit oraz 1 STOP, ale nie odbiera. Czy muszę zainstalować program PuTTy aby odbierać dane z MegaJoy.
Ten program nie obsługuje komend V100 ustawiających kolory, kursor itd. Powinno być jednak coś widać.
A TX z Leonardo idzie na RX max232?
-
U mnie działa HAT zrobiony z joysticka ośX oraz ośY tak mam połączony joystick Ao, A1. Pozostałe opcje połączenia HAT sprawdzę i dam znać. Mam 2 rejestry i mogę zrobić pełny test.
Martwi mnie problem z TX. TX w Leonardo jest na D1 (ozn. na pcb TX->1) i jest wyjściem sygnału, który trafia na pin 10 (T2IN) w MAX232. Podłączyłem na wyjściu Leonardo TX LED z szeregowym rezystorem. Migotanie czerwonego (mojego) LED jest prawie niezauważalne w porównaniu do LED TX na pcb Leonardo. Mam wrażenie, że na wyjściu Leonardo TX brak sygnału. Płyta testowa z MAX232 oraz podłączonym konwerterem RS232->USB jest sprawna, sprawdzałem z platformą codeking HSC. Ustawiłem terminal v1.9b na 115200, 8 bit, 1 STOP, brak znaków na odbiorze. Może jest jakiś prosty sposób sprawdzenia wyjścia TX z Leonardo.
-
W takich wypadkach idealny jest oscyloskop lub analizator logiczny, ale zdaję sobie sprawę, że to nie są narzędzia, które każdy hobbysta ma pod ręką.
U mnie czerwony LED podłączony do D1 przez 2.2k do masy praktycznie cały czas się świeci.
Mało prawdopodobne, ale może uszkodził sie port w Atmedze?
Spróbuj może podłączyć dwa LEDy i wgrać prosty sktypt testujący D0 i D1.
void setup() {
pinMode(0,OUTPUT);
pinMode(1,OUTPUT);
}
void loop() {
digitalWrite(0,LOW);
digitalWrite(1,HIGH);
delay(500);
digitalWrite(0,HIGH);
digitalWrite(1,LOW);
delay(500);
}
Diody powinny migać naprzemian.
-
Vito nadajesz standardowo na serial?
void setup(){
Serial.begin(9600);
}
void loop(){
Serial.print("wstaw tekst wstaw tekst byle nie hello wordl");
}
Bo jeżeli tak to dokumentacja mówi jasno:
Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data using the ATmega32U4 hardware serial capability. Note that on the Micro, the Serial class refers to USB (CDC) communication; for TTL serial on pins 0 and 1, use the Serial1 class.
Czyli powinieneś wywołać:
void setup(){
Serial1.begin(9600);
}
void loop(){
Serial1.print("wstaw tekst wstaw tekst byle nie hello wordl");
}
-
Mam kilka pytań. Na początek stary problem tzn. TX. Porty TX oraz RX są ok sprawdziłem testem 314ter. W programie MegaJoy podłączenie LED do TX Leonardo zapala diodę tak jak u 3.14ter. Golas masz rację, ale w programie MegaJoy jest już to uwzględnione. Podejrzewam, że problem jest po stronie programu Terminal v1.9b. Na zdjęciu jest pokazane ustawienie. Jest też pokazane działanie joysticka jako HAT.
(http://i700.photobucket.com/albums/ww5/vito_zm/test-TX.jpg) (http://s700.photobucket.com/user/vito_zm/media/test-TX.jpg.html)
Mam problemy z testem opcji HAT.
Mam połączone 16 przycisków do MCP23017 (adress 20). Mogę je przełączyć do drugiego MCP23017 o adresie 27. W testerze vbk odpowiada to zapalaniu lamp od 1 do 32.
1.Metoda 2.
Odkomentuję #define HAT_TEST_BUTTON_LIST.
Są włączone 4 funkcje :
Joystick.setHatSwitch(0,6,5,4,3);
Joystick.setHatSwitch(1,6,5,4,3);
Joystick.setHatSwitch(2,6,5,4,3);
Joystick.setHatSwitch(3,6,5,4,3);
gdzie nr HAT-a jest od 0 do3, ale numery wejść są te same. Jak ta numeracja ma się do mojej numeracji 1-32 (dla 2 rejestrów).
W moim testerze vbk nie mam reakcji na HAT, jest reakcja na przyciskach. Jest reakcja od joysticka na HAT1, może trzeba wyłączyć tę funkcję.
2. Metoda3.
Odkomentuję #define HAT_TEST_8BIT oraz wpisuję:
Joystick.setHatSwitch(0,readMCP23017,(20)); //wpisane beda HAT0 i HAT1
dostaję komunikat o błędzie- no matching function for call to "MegaJoystick_::........."
Co należy wpisać do tych funkcji dla np. rejestru o adresie 20:
//Joystick.setHatSwitch(0,readMCP23017(MCP1_SLAVE_ADDR));//wpisane beda HAT0 i HAT1
//Joystick.setHatSwitch(2,readMCP23017(MCP1_SLAVE_ADDR)>>8); // HAT2 i HAT3
Dalej nie sprawdzałem , ponieważ muszę rozwiązać opcje 2 i 3.
Ten znak cool pojawił się zamiast liczby8. 3.14 ter zna tę funkcję.
-
Problemy z portem szeregowym:
odłącz całkowicie Arduino i podłącz razem TX i RX w przejściówce (normalnie podpięte są do D0 i D1). To stworzy pętlę. To co wpiszesz w terminalu w PC powinno natychmiast pojawić się w oknie odbioru. Tym sposobem sprawdzisz czy PC nadaje i odbiera w ogóle cokolwiek.
Funkcja
Joystick.setHatSwitch(0,6,5,4,3);
służy do obługi HATa w przypadku, gdy jest podłączony bezpośrednio do którychś z portów Arduino. Można ją użyć z MCP23017, ale wymagałoby to niepotrzebnego sprawdzania bitów, przesuwania itp. Do tego celu przeznaczone są inne funkcje. To tylko test, wpisałem te same porty dla 4 HATów, żeby sprawdzić ich działanie za jednym razem.
W zapisie
Joystick.setHatSwitch(0,readMCP23017,(20));
są dwa błędy:
- ten przecinek po readMCP23017. To jest funkcja, bezpośrednio po nazwie w nawiasach podaje się argumenty.
- 20 to wartość w systemie dziesiętnym, właściwy adres jest w systemie szesnastkowym: 0x20, 0x20 = 32 dec. Czyli albo readMCP23017(0x20), albo readMCP23017(32). A najlepiej zdefiniować sobie gdzieś na początku programu stałe:
const int MCPx_SLAVE_ADDR = 0xXX; //gdzie duże XX to adres układu, a mały x to numer układu.
a potem w programie używać tylko nazwy. Kod wydaje się bardziej zrozumiały i intuicyjny.
Spróbowałem właśnie użyć program Terminal v1.9b. Ostatnia wersja z 2014.
Niestety nie jest w stanie połączyć się z modułem Bluetooth (numer COM wyskakuje na liście, ale nie można się do niego podłączyć). Natomiast użycie go z przejściówką USB-UART skutkuje natychmiastowym zawieszeniem się programu. Nie wiem w czym problem i chyba nie będę wnikał. Inne terminale (Termite, RealTerm) pracują bez problemu. Oczywiście pokazują "krzaczki", gdyż nie dekodują komend, tak jak to robi PuTTy.
W Twoim przypadku, używając PuTTy wystarczy w oknie startowym przestawić rodzaj trasmisji na Serial, wpisać COM11 i 115200 jako prędkość. Można również podać nazwę sesji, np. COM11_115200 i zapisać do późniejszego użycia. Nie trzeba będzie za każdym razem wpisywać od nowa.
(http://i.imgur.com/m4prWbo.png)
Warto jeszcze przejść do zakładki Window i zmienić "Rows" na więcej niż 24, np 35.
-
Kurna, ja chciałem tylko parę kontrolek, a to o czym mówicie to jakaś magia - jeszcze....
-
W Twoim programie faktycznie są już zdefiniowane stałe.
const int MCP1_SLAVE_ADDR = 0x20;
const int MCP2_SLAVE_ADDR = 0x27;
Zrobiłem tylko odkomentuję #define HAT_TEST_8BIT , ale daje eror tak jak na zdjęciu.
TX zwarte z RX po stronie TTL pracuje poprawnie. Zainstaluję PuTTY i zobaczę może będzie dobrze.
(http://i700.photobucket.com/albums/ww5/vito_zm/error-hat8.jpg) (http://s700.photobucket.com/user/vito_zm/media/error-hat8.jpg.html)
TX działa jeśli ustawimy terminal na HEX. Teraz instaluję PuTTy
-
Mój błąd, powinno być
Joystick.set2HatSwitch(0,readMCP23017(MCP1_SLAVE_ADDR)); //wpisane beda HAT0 i HAT1
Joystick.set2HatSwitch(2,readMCP23017(MCP1_SLAVE_ADDR)>>8); // HAT2 i HAT3
Github już uaktualniony.
-
Uruchomiłem program PuTTy, działa widać na obrazkach. Tylko po ekranie latają takie zielone prostokaty (jeden widać na zdjęciu). Mnie to nie przeszkadza.
(http://i700.photobucket.com/albums/ww5/vito_zm/PuTTy-2.jpg) (http://s700.photobucket.com/user/vito_zm/media/PuTTy-2.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/PuTTy-3.jpg) (http://s700.photobucket.com/user/vito_zm/media/PuTTy-3.jpg.html)
W nowych upgrade w opcji 4 HAT u mnie przyciski 5-8 realizują HAT1, przyciski 9-12 realizują HAT2 oraz przyciski 13-16 HAT3. Przyciski 1-4 działają jako przyciski. Joystick realizuje HAT0.
W testerze vbk naciśnięcie np. przycisku 5 powoduje zapalenie zarówno lampki 5 jak i strzałki N w HAT1.
Metodą 2 nie ma sensu się zajmować, ponieważ działa na bezpośrednich portach Leonardo.
Pozostaje do sprawdzenia metoda 4. Metodę 4 można zastąpić metodą 3 wywołując dwie funkcje co było pokazane w przykładzie 3.14ter. Po sprawdzeniu metody 4 dam znać jak działa.
Czy mogę prosić o wyjaśnienie jak testować w moim modelu metodę 1 HAT_TEST_DEGREE.
-
Po resecie procesora, albo przeładowaniu programy okno terminala powinno wyglądać normalnie. Prawdopodobnie Putty połączył się z Leonardo już po starcie programu. Kursor i cała reszta ustawiana jest tylko raz podczas startu.
Jeśłi chodzi o test metody 1, to zachęcam do przeczytania komentarza w programie, który umieściłem przed samą częścią testu:
//### Metoda 1 ###
//Jako parametr wejsciowy funkcja przyjmuje numer HATa (0-3) i kat w stopniach, (zakres 0-360, -1 odpowiada OFF)
//przyklad czyta analoghowa wartosc wejscia A0, mapuje ja na zakres -1 ... 360 i ustawia HATy
int16_t angle = analogRead(0);
angle = map(angle,0,1023,0,360);
if (angle < 5) angle = -1;
Joystick.setHatSwitchDg(0,angle);
W zasadzie ta metoda jest dodana tylko dla przypadków, gdy HAT nie będzie zbudowany z przycisków albo potencjometrów, a jego źródłem będzie coś innego, jakiś inny sensor nadający wartość liczbową w stopniach.
Jak widać powyżej, jako sygnał wejściowy użyłem potencjometru podłączonego do A0. Wartość ADC jest mapowana z 0-1023 na 0-360, a wartości 0-5 dodatkowo oznaczają HAT OFF.
Ustawienie będzie trochę skakać ze względu na szumy przetwornika.
-
Wszystkie opcje działają prawidłowo. Nie sprawdzałem tylko metody 2, ponieważ musiałbym połączyć przyciski do pin Leonardo.
Wracając do PuTTY to kursor porusza się przypadkowo cały czas po ekranie. Wystąpił inny problem z moim modelem RS232 ->konwerter RS232->USB oraz TX Leonardo. PC kilka razy mi się zawiesił i nastąpił restart pc. W związku z czym rezygnują z mojej opcji RS232 i zakupię konwerter HC05. Na Allegro jest z konwerterem napięć http://allegro.pl/show_item.php?item=5756899669 . Mam nadzieję, że będzie odpowiedni oraz, że po stronie PC wystarczy dowolny konwerter np. https://botland.com.pl/moduly-bluetooth/3561-modul-bluetooth-20-na-usb.html
-
Chciałbym podziękować koledze 3.14ter za wspaniały projekt zrobiony w tak krótkim czasie i najważniejsze, że działający oraz dla nas dostępny . Jeśli będziesz realizował kolejny projekt ten ambitniejszy to jestem do dyspozycji jako tester.
-
Także dziękuję 3.14ter :)
-
Panowie, to jeszcze nie koniec :) Mam już kilka nowych pomysłów jak dalej usprawnić bibliotekę.
Od strony sprzętowej myślę, że najpierw skupię się na nieco mniejszej wersji na Arduino. Ta platforma, pomimo ograniczeń, jest jednak bardzo popularna, tania i szeroko dostępna.
Mniejszej, tzn. standardowo płytka będzie zawierać zestaw do obsługi podstawowej wersji jaką obsługuje DirectX, a więc:
- 8 analogwych osi. 4 z nich będą obługiwane zewnętrznym przetwornikiem A/C 12bit, reszta będzie 10 bitowa,
- 2x MCP23017 na pokładzie do obsługi 32 przycisków,
- dodatkowe gniazda z I2C, do których będzie można podłączyć zewnętrzne moduły z kolejnymi kośćmi MCP,
- 2x HAT, wersja na przyciskach. Ilość można rozszerzyć przez użycie osi analogowych lub dodatkowych MCP23017,
- chwilowo nie będzie dedykowanej obsługi enkoderów. Myślę, że to zadanie dla oddzielnego modułu, który będzie odczytywał ileś tam enkoderów i generował zdarzenia typu "wciśnij przycisk". Dodatkowy plus - nie będzie na stałe związany z biblioteką i sprzętem. Będzie można go użyć w innych konstrukcjach, które posiadają wystarczającą ilość wejść.
Jeden z pomysłów na rozszerzenie biblioteki to swego rodzaju system "plug&play" dla modułów z MCP, każdy rozszerzający system o dodatkowe 16 przycisków.
Maksymalnie podłączyć możemy do 8 szt. MCP na jednej magistrali I2C. Na tyle pozwalają 3 wejścia adresowe. Akurat dobrze się składa - to daje 128 przycisków.
Procesor, zaraz po starcie sprawdzałby kolejne adresy (0x20 - 0x27) i automatycznie konfigurował wykryte moduły.
Generalnie chodzi o to, żeby ograniczyć programowanie do podstawowej konfiguracji sprzętowej, a resztę zautomatyzować jak tylko się da.
Obawiam się, że nie będę już w stanie działać tak szybko, jak przez ostatnie dni. Robota wzywa. Ale z czase myślę,że powstanie całkiem uniwersalny system do wielu zastosowań. Upgrade joystików, kokpity i co tam jeszcze wymyślicie :)
-
A ja mam pytanko, jak sobie radzicie z zakłóceniami... Mam mały problem jeszcze ze "skaczącymi" nieco wartościami potencjometrów. Na płytce prototypowej jest ok, ale jak przewody są dłuższe, to już się zaczyna "letka wariacja". Zastosowałem proste uśrednianie wartości. Nie dałem jeszcze ekranowanych przewodów. No i nie wiem, czy nie zastosować stabilizowanej przetwornicy napięcia do zasilania potencjometrów. Może po prostu arduino nie wyrabia. Macie jakieś przemyślenia na ten temat?
-
Zawsze możesz dać za potka czy innego sensora halla układ adc (np MCP320* 12bit albo MCP330* 13bit) który wynik da Ci już cyfrowy i po kablu puścisz dalej bez zakłóceń niż w przypadku gołego wyniku z sensora.
BTW:
Ja właśnie otworzyłem paczkę z TME z KMZ60 x 3 + SS495A1 + MCP3208 i teraz przeprojektowuję swój koncept joy'a :P wywalę z płytki głównej 3x74HC165 i dam je jako osobne płytki x5 co da 40 przycisków (32+2 haty)).
Teraz kwestia co do samego andruta naszego - czy jest sens projektowania całej płytki bazowej pod podzespoły samego arduino (robimy tj. klona) czy bardziej opłacalne będzie zrobienie serii płytek modułowych np. rejestr przesuwny po SPI/I2C (74HC165D lub MCP23017) lub sensor + przetwornik (np. KMZ60+MCP3201/MCP3301) dla pojedynczych osi lub moduł wielokanałowych przetworników ADC (2-8kanałów?), płytka pod enkodery no i oczywiście całość spinana do płytki głównej w którą wpięte było by arduino. Moim zdaniem fajnie byłoby zrobić taki 'ujednolicony' system i projekty płytek - może gotowe do zamówienia w jakiejś firmie?
-
Rozwiązanie, które mam już przetestowane w praktyce (sprzęt estradowy) planuję zastosować również w bazowej wersji płytki.
Każde wejście analogowe będzie wyglądać tak:
(http://i.imgur.com/Li8NV8C.png)
1. Potencjometry podłączone kablami ekranowanymi, 3 lub 4 (łatwiej dostępne) żyły w ekranie. Ekran połączony z masą tylko z jednej strony - przy gniazdku na płytce.
2. Cała część analogowa zasilona z oddzielnego niskoszumnego stabilizatora 3.3V. To napięcie będzie użyte jako AREF w Arduino, ADC będzie mierzył napięcie z zakresu 0-3.3V. Kolejna zaleta tego rozwiązania to ochrona przed zwarciem. Zastosuję jakiś mały stabilizator na ok. 100mA, może mniej. W przypadku zwarcia VDDAF do masy (może się zdarzyć podczas okablowania) ograniczy on prąd i ochroni port USB. USB zresztą też będzie miało swój zestaw zabezpieczeń.
3. Zaraz na wejściu 1 filtr RC usuwający śmieci powyżej 1.5kHz. Dioda BAT54S + rezystor 1k zabezpieczają wejście przez przepięciami, ujemnymi napięciami itp. Standardowe zabezpieczenie.
4. Dalej mamy wtórnik napięciowy na wzmacniaczu operacyjnym. Rezystor 2M2 nie obciąża praktycznie wcale potencjometru lub czujnika Halla, ale polaryzuje wejście do masy w przypadku, gdy nic nie jest połączone. Zostawianie "wiszących w powietrzu" niespolaryzowanych wejść nie jest dobrą praktyką. Wtórnik napięciowy ma niską impedancje wyjściową, zalecaną do wysterowania wejścia ADC.
5. Na końcu jeszcze jeden filtr RC, umieszczony blisko wejścia ADC. W momencie próbkowania przetwornik generuje dość sporą szpilkę:
(http://i.imgur.com/TIQmpK3.png)
To jest zrzut ekranu z oscyloskopu, program MegaJoy, wejście A0, odłączony potencjometr.
Parę innych czynników ma na to wpływ, ale możemy przyjąć, że dla klasycznego podłączenia potencjometru prosto do wejścia ADC, te szpilki będą propagować po całym okablowaniu. A zwłaszcza, gdy potencjometry będą w okolicy środkowego położenia. Ważne jest, żeby te szpilki zostały wygaszone jak najbliżej wejścia ADC. M.in. z tego również wynika zalecenie, żeby na wejścia ADC podawać sygnał o niskiej impedancji. Wtórnik napięciowy to załatwia, a drugi filtr nie pozwala na to, żeby zakłócenia latały po całej płytce i kablach. Przy okazji dodatkowo tłumi szum.
6. Wtórnik ma jeszcze jedno zadanie - ochrania i separuje wejście ADC od świata zewnętrznego. Łatwiej i taniej jest wymienić tani wzmacniacz operacyjny niż cały procesor, gdyby doszło do jakiejś awaryjnej sytuacji.
Żeby choć trochę poprawić sytuację zastosowałbym po pierwsze ekranowane kable, po drugie filtr RC 1k-10k (dobrać doświadczalnie)+100n do masy umieszczony przy samym wejściu Arduino.
Jeszcze odnośnie kwestii zasilania. Najprawdopodobniej przewidziane będzie dodatkowe gniazdo MicroUSB i automatyczny przełącznik zasilania. Jest cała masa tanich zasilaczy z wyjściem MicroUSB (np. te do RaspberryPi). Układ po wykryciu zewnętrznego zasilania przełączy się na nie, a zaszumione USB zostawi w spokoju.
Zastanawiam się też na opcją dodania sterowników LED na I2C. Joystick nie odbiera danych z PC, ale co można zrobić, to np. podświetlenie przycisków. Każdy z przycisków miałby dodatkowy rejestr do konfiguracji podswietlenia, coś w rodzaju:
BtnXled = 0 ; //brak
BtnXled = 1; // toggle, wciśnij -zapala LED, następne go gasi
BtnXled = 2; //momentary, LED świeci tylko, gdy przycisk jest wciśnięty, tak jak kontrolki w windows
128 LEDów plus cała reszta układu to już może być za dużo dla jednego portu USB. W takim wypadku zalecane będzie zasilanie zewnętrzne.
-
Jest tyle informacji, że nie wiem od czego rozpocząć. Rozpocznę od analogów. To co proponuje 3.14ter jest profesjonalnym rozwiązaniem tak się to robi co nie ozn., że nie pojawią się problemy. Można szybko przeliczyć jaki będzie minimalny skok kwantyzacji dla przetwornika 10 bit dla zakresy napięć 0-3,3V. Są to przetworniki liniowe bez kompresji dla małych poziomów.
Jeszcze odnośnie kwestii zasilania. Najprawdopodobniej przewidziane będzie dodatkowe gniazdo MicroUSB i automatyczny przełącznik zasilania. Jest cała masa tanich zasilaczy z wyjściem MicroUSB (np. te do RaspberryPi). Układ po wykryciu zewnętrznego zasilania przełączy się na nie, a zaszumione USB zostawi w spokoju.
Czy mogę prosić o wyjaśnienie. Arduino może być zasilane albo z USB albo z źródła zew. 7-12V przez gniazdo Power Barrel Jack. Jeśli podamy napięcie z zew. to napięcie z USB będzie zablokowane. Nie śledziłem schematu Leonardo, ale tak przypuszczam.
Część cyfrowa tzn. MCP23017 będzie zasilana z 5V z Leonardo a część analogowa z 3.3V także z Leonardo, czy mam rację?
Cała część analogowa zasilona z oddzielnego niskoszumnego stabilizatora 3.3V. To napięcie będzie użyte jako AREF w Arduino, ADC będzie mierzył napięcie z zakresu 0-3.3V
Czy to napięcie 3.3V jest podawane na wejście IOREF, czy jest to zewnętrzy zasilacz 3.3V.
Co do części cyfrowej to jeśli dobrze zrozumiałem ten fragment:
.....standardowo płytka będzie zawierać zestaw do obsługi podstawowej wersji .....
Czy planujesz na bazie Leonardo zaprojektowanie schematu ideowego oraz płytę pcb realizującą wymienione założenia?
Golas wstrzymaj się z swoim projektem, ponieważ jak zauważyłeś projekt 3.14ter dopiero się tworzy. Tempo jest niesamowite w porównaniu do innych projektów, które były tworzone przez miesiące a nawet lata.
-
Projekt 3.14ter'a będzie także wykonany, spokojnie :P nikt nie broni przecież zrobienia kilku kontrolerów zarówno elektrycznie jak i mechanicznie nie? :)
Powracając do płytek - moim zdaniem jeżeli byłoby zainteresowanie jakiejś grupy osób (5-10?) wtedy można by się było pokusić o zrobienie płytek w jakiejś firmie, która zrobi to porządnie dwustronnie wraz z soldermaskami - chodzi mi oczywiście o panelizowane układy modułów + płytki centralnej :) wtedy koszt zakupu gotowych płytek byłby bardzo porównywalny do wytworzenia ich samemu (a jakość na pewno większa u fachowca).
-
Projektuję całkiem nową płytkę, opartą o ATMEGA32U4. Będzie to układ kompatybilny z Arduino. Znaczy to też, że najpierw trzeba będzie wgrać bootloader przy pomocy jakiegoś zewnętrznego programatora do AVR. Od biedy może to tego posłużyć nawet inne Arduino.
Zastanawiałem się nad użyciem gotowych modułów, ale doszedłem do wniosku, że skoro i tak trzeba będzie lutować dość sporo elektroniki naokoło Arduino, to w sumie większy sens będzie miało zaprojektowanie nowej płytki od podstaw. Zoptymalizowanej pod to do czego ma służyć, z porządną filtracją zasilania, zabezpieczeniami, wygodnymi złączami i wg ogólnych zasad projektowania urządzeń z mikrokontrolerami.
Całkiem zapomniałem o MCP3208. Używałem w ostatnim projekcie 4ro kanałowy MCP3204 i jakoś tak mi został w pamięci. Zmieniłem projekt na MCP3208 i będzie 8 12bitowych osi. Dzięki golas za "cynk" ;)
Zastosowanie 3.3V dla części analogowej praktycznie nic nie zmienia od strony cyfrowej, rozdzielczości ADC, zakresu itd. Potencjometry zamiast 0-5V będą podawać 0-3.3V. Na wejściu VREF (napięcie odniesienia, górna granica skali) przetwornika również będzie 3.3V. Jedynie co trzeba jeszcze sprawdzić, to czy czujniki Halla z wyjściem analogowym mogą pracować z takim napięciem zasilania.
IOREF - nie mam takiego wejścia w moim Leonardo. Jest tylko AREF, jest to pin Atmegi do podawania zewnętrznego napięcia referencyjnego dla ADC lub to podłączenia kondensatora filtrującego wewnętrzne źródło. Standardowo Arduino używa VCC jako referencji dla ADC, ale można to programowo przełączyć na pin AREF.
W moim układzie nie będzie to miało znaczenia, bo pokładowy przetwornik Atmegi nie będzie używany.
Co może trochę odstraszać, to większość elementów będzie w technologii SMT. Chociaż ja uważam osobiście, ze SMT jest o wiele prostsze do lutowania od technologii przewlekanej. Wymaga jedynie odrobinę wprawy i dobrego topnika.
Płytki na 100% wykonane fabrycznie.
-
Osobiście preferuję montaż powierzchniowy :) elementy zazwyczaj tańsze, zajmuje mniej miejsca i mimo, że kilka lat temu wyłożyłem ponad 600 złociszy na proxxona micromota 50ef wraz z zasiłką i stojakiem co by wiertło 0.5mm robiło otwór 0.5 a nie 1mm :P to i tak jestem za SMT ;p oprócz pinheadów! te obowiązkowo tradycyjnie przez dziurę! :P bo i tańsze sporo i gorzej wyrwać ;)
3.14ter - ja się na fabryczne płytki piszę jak nic :)
Co do samych sensorów które nas najbardziej interesują :) czyli potsy i czujniki halla - magnetorezystancyjne (dzis testuję KMZ60+MCP3208 [kmz datasheet (http://cache.nxp.com/documents/data_sheet/KMZ60.pdf?pspll=1)]) etc. uważam, że powinniśmy uderzać w 16bitowe rozdzielczości - różnica cenowa nie jest jakaś mega ogromna (patrząc i tak na nie małe koszta całościowe) - stosując dobrej jakości sensory można uzyskać naprawdę sensowne wyniki 12bit - 4096 | 16bit - 65536 - 16'to bitowe są choćby w warthogu którego tak wiele osób chwali za precyzję działania :)
Dodatkowo kwestia zakłóceń - im bliżej mamy czujnika przetwornik adc tym powinno być moim zdaniem lepiej - tutaj kwestia dyskusyjna? :P Ja osobiście wolałbym nawet pojedyncze/podwójne moduły z adc i czujnikiem do mocowania jako płytka i od tego do głównej płytki połączenie - cyfrowy sygnał vs. analogowy nawet w ekranowanym przewodzie powinien się lepiej zachować na korzyść cyfry (pomijam, że można na module dać dodatkowe filtry/kondensatory etc jeżeli są potrzebne) :)
Całość jak najbardziej modułowa :) w końcu nie każdy potrzebuje od razu 8osi i setki przycisków z masą enkoderów oraz hatów :P
-
Gniazda i piny jak najbardziej tradycyjnie, zgadzam się w pełni!
Przetworniki przy czujnikach - z jednej strony tak. Z drugiej dłuższe i wielokrotne połączenia np. na magistrali SPI mogą zrujnować komunikację. Przerabiałem ostatnio przy obsłudze wyświetlaczy TFT.
Muszę zamówić parę czujników halla do testów i sprawdzić to w praktyce.
-
Ja właśnie testuję SS495A1 - całkiem całkiem czujnik zwłaszcza, że bipolarny - niestety moje magnesy neodymowe ze starych hdd'ków mają dziwne pola lub już bardzo słabe (dyski rozebrane w celu odzyskania magnesów mają połowę tego co ja na liczniku nabite :) ), niemniej jednak 10bit to widzę już, że za mało, 12 pewnie na orczyk i przepustnice wystarczy - na joy'a już może być mało zwłaszcza, jak założymy, że drąg będzie miał min 30cm od gimbala.
Właśnie trawią się płytki pod KMZ60 i MCP3208 - termotransfer wyszedł całkiem całkiem mimo, że dawno go nie robiłem - obaczym, czy trawiarka faktycznie utrzyma zadane 45 stopni, jak nie wycieczka po laminat i b327 w poniedziałek :P
-
Nasza dyskusja to w jakimś sensie dyskusja o założeniach do projektu. Jeśli założymy, że będzie płyta główna z uP 32u4 z interfejsami oraz innymi dodatkami to będą płyty satelity dla interfejsów np. I2C oraz SPI.
Jeśli planujemy zastosować MCP3204/8 na płycie satelicie komunikujący się po I2C to nie ma chyba sensu korzystać z przetwornika ADC w 32u4 (Ao-A5). Natomiast trzeba zrobić zabezpieczenia przed zakłóceniami o których wspomniał 3.14ter właśnie na płycie satelicie. Drugi problem to zasilanie płyty głównej oraz płyt pomocniczych. Ja mam u siebie 2 zasilacze od pc, które zasilają niezależnie lewą oraz prawą burtę w kokpicie.
I ostatnia sprawa, która mi się nasuwa to programowanie. Trzeba założyć maksymalną konfigurację np. 8 MCP23017 oraz wspomniany MCP3204/8 oraz inne czujniki.
3.14ter już o tym wspomniał, że pewne sprawy program rozpozna tzn. wyposażenie hardware, ale być może każdy użytkownik będzie musiał w programie Arduino zrobić małą korekcję pod swoje potrzeby. To zależy od możliwości programowych 3.14ter. Nie ma sensu robić coś na wzór MMJoy2, ponieważ jest to przerost formy nad treścią. Wystarczy funkcjonalny program z opisem jak zmieniać parametry w programie jeśli będzie taka potrzeba. To takie moje przemyślenia na gorąco.
-
Skoro o założeniach projektu.
Czytam trochę ten wątek. Pisałem też na privie do Vito z prośbą o wyjaśnienie dlaczego korzystając z platformy arduino zajmujecie się takimi systemami jak mmjoy. Przyznam że nie do końca to jeszcze rozumiem. A wynika to chyba z dwóch różnych podejść do tematu. I żeby nie było. Nie krytykuję, nie oceniam, co lepsze itp. Zajmuję się ostatnio stworzeniem nowej wersji kontrolera lotu (kopii znanego urządzenia - zdjęcie poniżej). Już są chętni na takie coś, więc tworzę sobie też dokumentację, obliczam koszty itp. Tworzę też jakąś elektronikę opartą o arduino. Ale właśnie. Padła tu propozycja pytanie - czy byliby chętni do wyprodukowania takich modułów elektroniki. Ja pewnie na ten rok potrzebowałbym kilku. Ale:
Tak sobie myślę jako klient "mojego produktu". Powinno to urządzenie działać jak każdy joystick. Czyli - plug'n'play. Na pewno nie chciałbym kupować urządzenia do którego uruchomienia potrzebna znajomość mmjoya, czy innych dodatkowych programów. W ten sposób piszę swoją wersję oprogramowania. Ale zdaję sobie sprawę, że to wyważanie otwartych drzwi, bo koledzy mają stosowną wiedzę i zwyczajnie zrobią to lepiej.
I teraz jakby wracając - te dwa podejścia:
1. Robimy moduł elektroniki dla końcowego odbiorcy - gracza, który buduje sobie joya, albo producenta joysticków - moduł, który ma określoną ilość osi i przycisków - klient do gniazdka na kablu podpina potencjometr i działa.
2. robimy moduł dla świadomego budowniczego kokpitów - z masą opcji konfiguracyjnych, z dużą ilością podmodułów wykonawczych itp.
Czego ja bym chciał, czytając ten wątek. Chciałbym mieć dostęp do pierwszej opcji. Buduję mechaniczny joy podpinam wyprodukowany moduł, który kupujący podpina do komputera i działa. W takim przypadku całość oprogramowania musi być po stronie modułu elektroniki ( a nie że musiałby klient sobie konfigurować coś w mmjoyu)
Moduł musi być jeden a nie kilka różnych. - żeby łatwo to było zainstalować - ewentualny nadmiar wejść, np. zbędne osie wyłączać albo automatycznie, albo zworką.
Czyli taki ograniczony (brak możliwości rozbudowy) moduł, ale gotowy jako całość i bezproblemowy.
Jeszcze raz, żeby nie było. Naprawdę nie krytykuję, tylko piszę, co by mi się przydało. Takich modułów kilka bym zakupił (dołożyłbym się do produkcji). Ten przydługi post można by chyba streścić do pytania: dla kogo taką elektronikę budujemy? Co jest nam potrzebne?
(http://mcd.ayz.pl/rozne/joy_zdjecia/nowe_metalowe.jpg)
-
Ja obojętnie czy bardzo rozbudowane konfigurowalne czy gotowe do działania i tak chcę zakupić :) Poza tym, jeżeli nawet ustawisz zawczasu pod klienta wersję 'advanced' to może on dostać właśnie urządzenie plug'n'play :)
-
ShopiK poruszył bardzo ciekawy problem. Faktycznie można zapytać dla kogo ten projekt i tutaj nie będzie jednoznacznej odpowiedzi, ponieważ każdy ma inne potrzeby oraz umiejętności wykorzystania takiego projektu. Może przybliżę ten problem na swoim przykładzie, ponieważ zajmuję się tym od lat.
Na początku był słynny MJoy16 oraz SVMapper. Tutaj sprawa była dosyć prosta i nie wymagała prawie żadnych umiejętności.
MJoy16 miał ograniczone możliwości dla budowania kokpitów, ale był wystarczający dla budowy paneli.
W moim przypadku pojawiła się OpenCockpit z swoim softem SIOC oraz całą rodziną hardware. Tutaj wymagana była już wiedza potrzebna do pisania skryptów oraz konfigurowania różnych płyt. Nawet teraz po kilku latach maciej z forum też ma ten system u siebie.
Następnie pojawił się na naszym forum codeking z swoją wspaniałą platformą HSC oraz SIMOUT i SimIN. Tutaj także jest potrzebna wiedza do pisania skryptów. Moim zdanie HSC jest jedna z najlepszych platform.
Zapomniałem wspomnieć , że pojawili się jeszcze inni twórcy hardware oraz soft np. Skalarki. Ten system ma u siebie w kokpicie EGHI.
Drejku zastosował gotowe rozwiązanie softu oraz hardware, ale wyspecjalizowane pod symulator.
Kolejny programista z naszego forum Damos zrobił dwa kontrolery DMKeys8 oraz DMJoy. Pierwszy emuluje klawiaturę drugi jest widziany jako joystick. Damos zrobił program konfiguracyjny w formie graficznej, gdzie konfiguracja jest trywialna. Jednocześnie możliwości przypisania klawiatury oraz tworzenia sekwencji są imponujące. Są też przewidziane zabezpieczenia programowe itp.
Tak jak kiedyś wspomniałem traktuję elektronikę jako hobby, dlatego zainteresowałem się ostatnio Arduino. Ponieważ zauważyłem, że koledzy już u siebie stosują te kontrolery to założyłem ten wątek. W ten sposób dotarłem do platformy MMJoy2, którą chciałem poznać. Mogę stwierdzić, że jest to bardzo dobre rozwiązanie dla osób nie lubiących pisać skryptów oraz wgłębiać się w "teorię". Konfigurowanie jest w formie graficznej czyli klikanie. Są dołączone programy testujące. Generalnie jest tam to co teraz zrobił 3.14ter, ale na innych rejestrach jeśli chodzi o wejścia cyfrowe. Są też analogi z możliwością połączenia czujników czy przetworników ADC wielokanałowych. Można MMJoy2 zaprogramować na ProMicro i będzie działać. Zakończyłem moje testy z MMJoy2 z dwóch powodów. Po pierwsze problem enkoderów o czym pisałem oraz pojawienia się na forum 3.14ter.
Tutaj otworzył się nowy rozdział historii, ponieważ z tego co zauważyłem kolega 3.14ter dysponuje zarówno wiedzą jak i praktyką. Wspomnę tylko o jego uwagach na temat zakłóceń w analogach. Ja mam o tym trochę pojęcie co to znaczy zakłócenia jeśli kodujemy próbkę na poziomie mV. Po za tym zna się na programowaniu. Na ogół programiści nie są specami od hardware i na odwrót. To co proponuje 3.14ter może być bardzo przydatne dla budowniczych paneli lub kokpitów. Pytanie na ile ma to być uniwersalne. Przykład enkodery, czy ma być opcja enkoderów jeśli jest już DMKeys8 itp. Moim zdaniem niech autor sam zdecyduje co ma szansę zrobić. Użytkownik może korzystać z tych funkcji, które potrzebuje.
Na koniec sprawa o której pisze shopiK oraz golas tzn. konfigurowanie lub plug'n'play. Myślę, że 3.14ter znajdzie sposób na rozwiązanie tego problemu. Jeszcze jedno przyszło mi na myśl. Pisaliście koledzy swoje szkice dla swoich zastosowań i wiecie, że jest to pewien wysiłek. Zauważcie jak elegancko rozwiązał ten problem 3.14ter tworząc funkcje i je w odpowiednim miejscu wywołując. Program jest bardzo czytelny. Należy tylko się cieszyć, że pojawił się na naszym forum kolega 3.14ter, który może nam ułatwić życie. Trochę się rozpisałem, ale tak myślę co nie znaczy, że mam rację.
-
Poruszyli
-
Poruszyliśmy dobry temat. Dokładne zaplanowanie koncepcji projektu to podstawa. Z mojego podwórka mogę dodać, że usiłowanie upakowania nieliczonych ilości opcji, skomplikowana procedura obsługi to pułapka. Dobrze rozwiązane urządzenie jest proste i wygodne w obsłudze, robi to co ma robić i nie rozprasza użytkownika.
Dlatego też o projekcie na Arduino, a właściwie Atmedze32U4 myślałem bardziej w katerogiach "Hurriego". Może nie jest najlepszy w swojej klasie i brakuje mu do czołówki, ale z drugiej strony zbudowany jest z w miarę tanich i łatwo dostępnych podzespołów, ma zestaw podstawowych opcji (ilość osi, przycisków..), wybacza wiele niezbyt jeszcze doświadczonemu kierownikowi.
Oprócz tego dodatkowe gniazda z interfejsami I2C i SPI mogą posłużyć to dalszej rozbudowy układu.
Dla kogo byłby ten projekt. Od samego początku dla mnie była to sprawa jasna: dla hobbystów budujących swoje kokpity, ulepszających joysticki. Projekt typu "open source". Konfiguracja nie musi być strasznie skomplikowana i całość można zautomatyzować do kilku prostych funkcji. Ewentualnie jeszcze prościej - zaplanować stałą mapę ustawień. Użytkownik będie musiał podłączyć się do odpowiednich wejść, jeśli chce użyć danej funkcji.
Drugi, high-endowy projekt dla bardziej wymagających użytkowników, taki "Spit" mógłby być zbudowany na szybszym procesorze PSoC5LP.
Górne ograniczenie w tym momencie to ilość danych w paczce HID. Biblioteka arduino wykorzystuje maksymalną ilość 64 bajtów. Ograniczenie ilości wejść w prostszych wersjach sprzętowych jest banalnie proste - po prostu można uch nie używać, nie podłączać nic do wejść analogowych (procesor będzie nadawał cały czas 0), nie podłączać przycisków, czy HATów. Dane będą lecieć do PC, ale skoro tam nie będą przypisane do żadnych fukncji, to chyba nie ma problemu (możliwe, że jest tu jakiś haczyk, nie wiem).
Czego mi brakuje, to wiedzy praktycznej z budowy kokpitów, listy rzeczy, które są niezbędne, które są pożądane. Mogę zaprojektować cuda-niewidy, tylko pytanie, czy w ogóle ktoś z tego skorzysta i czy niepotrzebnie nie będziemy zwiększać ceny urządzenia.
Myślę, że dobrą koncepcją będzie budowa "Hurrie-Joya" jako pierwszego, prostszego i tańszego w budowie, łatwego w obsłudze uniwersalnego joysticka. Na bazie zdobytych doświadczeń, później można zabrać się za "Spit-Joya" (podoba mi się ta analogia :)
Jeszcze mam takie pytanie natury technicznej. Jakiego rzędu odległości czujnik - płytka bazowa trzeba założyć w projekcie?
Już wiem skąd te podwójne posty. Przełączanie języka klawiuatury w win jest pod alt-shift. Przy szybkim pisaniu chyba wcisnąłem do tego "s" i post się wysłał.
Uprzejmie proszę o usunięcie poprzedniego posta.
-
Rozmyślań technicznych ciąg dalszy.
Spójrzcie co uzyskałem po dodaniu prostego filtru (średnia krocząca z 8 wartości) do zwykłych 10bitowych wejść 32U4 (zrzuty ekranu z VKB joytester):
(http://i.imgur.com/3XkLb6F.png)
Dla porównania tak wygląda wyjście Saiteka St290 Pro:
(http://i.imgur.com/d8qtjsI.png)
A tu porównanie, Saitek vs wejście A0 32U4 (suwak ma podłączony 100n do masy) i ten sam sygnał po filtrze cyfrowym. Skala identyczna dla wszytkich przebiegów, rozciągnąłem ją tylko w pionie:
(http://i.imgur.com/wzguABR.png)
-
!!! A taki filtr cyfrowy to zaimplementowałeś w bibliotece? Gdzie można znaleźć taki kod?
-
Nie ma go w bibliotece, będzie częścią nowego programu na którym testuję inne pomysły.
Zasada jest taka:
void ADCLowPassFilter(void)
{
static volatile uint32_t filt[FILTER_ARRAY_SIZE];
uint16_t temp16;
uint8_t i;
for (i = 0; i <FILTER_ARRAY_SIZE; i++)
{
adcRawData[i] = scanner.getValue(scanOrder[i]);//tu możda dać analogRead(i), jeśli wejścia podłączone są do A0-A5
temp16 = adcRawData[i];
if ((temp16 >(filt[i] + k_LPfltFeedforward)) ||
((filt[i]>k_LPfltFeedforward)&&(temp16 < (filt[i] - k_LPfltFeedforward))))
{
filt[i] = temp16;
}
else
{
filt[i] *= k_Ravg_size;
filt[i] += temp16;
filt[i] /= (k_Ravg_size+1);
}
adcFilteredData[i] = filt[i];
}
}
Zabierałem się już do napisania obsługi ADC poprzez przerwania, tak, żeby nie blokował programu, ale jak zwykle w przypadku Arduino, już ktoś to zrobił.
Do automatycznego skanowania kilku wejść ADC użyłem biblioteki:
https://github.com/merose/AnalogScanner
Na zewnątrz mam zadeklarowane kilka tablic:
#define FILTER_ARRAY_SIZE 6 // skanujemy 6 wejsc analogowych
uint16_t adcRawData[FILTER_ARRAY_SIZE]; // to czyste wejścia ADC, w zasadzie ta tablia nie będzie potrzebna, ale chciałem mieć te wartości dla porównania
uint16_t adcFilteredData[FILTER_ARRAY_SIZE]; // tu zbierane są przefiltrowane wartości wejść ADC
Stałe:
const int k_Ravg_size = 7; //rozmiar średniej. (n^2 - 1)
const uint16_t k_LPfltFeedforward=10; //a to sprytny trick. Jeśli wartość wejścia ADC przekroczy ustaloną tu wartość, to filtr się wyłączy. Zapewnia to lepszą dynamikę przy szybkich zmianach i podążanie za sygnałem źródłowym. Bez tego filtr wprowadzałby opóźnienia np. przy szybkim ruchu drągiem.
A dalej w programie dostęp do przefiltrowanych parametrów mamy po prostu przez tablicę adcFilteredData[numer wejscia ADC];
Kod funkcji nie jest jeszcze do końca zoptymalizowany. Testowałem właśnie jego działania i czasem dobrze jest mieć trochę nadmiarowych zmiennych do obserwacji działania.
-
No muszę przyznać, że fajnie to działa. Trochę za długo trzyma jeśli się ruszy drąga po chwili bez ruchu. Ale kod fajny - dużo lepiej stabilizuje niż moja średnia arytmetyczna :-) Bardzo dziękuję
-
Z mojego podwórka mogę dodać, że usiłowanie upakowania nieliczonych ilości opcji, skomplikowana procedura obsługi to pułapka.
Całkowicie zgadzam się z tym poglądem. I znowu wrócę do projektu MMJoy2. Twórca chciał zrobić uniwersalny sterownik (joystick), który ma realizować bardzo dużo funkcji nawet sterowanie LED. Moje testy z enkoderami wypadły negatywnie. Mógłbym na forum pytać o przyczyny, ale doszedłem do wniosku, że MMJoy2 można stosować tylko w ograniczonym zakresie.
To co proponuje 3.14ter ma sens tzn. realizacja kontrolera typu joystick na bazie Atmedze32U4 a później po doświadczeniach realizacja bardziej zaawansowanego na bazie szybszego procesora PSoC5LP.
-
Ograniczenie ilości wejść w prostszych wersjach sprzętowych jest banalnie proste - po prostu można uch nie używać, nie podłączać nic do wejść analogowych (procesor będzie nadawał cały czas 0)
Jak w arduino nic nie podłączę (a nie zepnę do masy) to na wejściach pojawiają się losowe wartości.
-
Jak w arduino nic nie podłączę (a nie zepnę do masy) to na wejściach pojawiają się losowe wartości.
ShopiK ma rację, jeśli dla analogów program jest przygotowany na odbiór wszystkich wejść to na wejściu nie połączonym do źródła będzie szum. Można to rozwiązać na dwa sposoby, albo program rozezna tę sytuację np. uśredniając w jakimś odcinku czasu lub coś podobnego, albo tak jak w MJoy16 zworka na wejściu nieaktywnym do masy.
-
I jeszcze zauważyłem u siebie (a także gdzieś czytałem o tym problemie), że nie umasione, wiszące w powietrzu wejścia zakłócają te podpięte... Faktycznie tak jest.
-
Bardzo dobrą robotę tu robicie. Coraz bardziej podoba mi się Arduino. Prawdopodobnie też zdecyduję się na wykorzystanie tej platformy w zakresie eksportu danych z DCS. Planowałem samodzielnie grzebać w export.lua ale teraz myślę że szkoda na to tracić czas – na Arduino osiągnę pożądany efekt szybciej.
W każdym razie to co robicie pozwala mi (pomimo tego że nie mam jeszcze Arduino) wstępnie poznać i pozytywnie ocenić to rozwiązanie - i za to właśnie dzięki :564:.
-
I jeszcze zauważyłem u siebie (a także gdzieś czytałem o tym problemie), że nie umasione, wiszące w powietrzu wejścia zakłócają te podpięte... Faktycznie tak jest.
Dlatego docelowo w układzie wejściowym wtórnik na wzmacniaczu operacyjnym ma dodatkowy rezystor 2M2 do masy na wejściu +. 2M2 równolegle do potencjometu 10k-50k nie robi praktycznie żadnej różnicy. A jeśli źródło zostanie odłączone, trzyma wejście na potencjale masy. Przetestowałem to właśnie w praktyce: szum, gdy wejście wisi w powietrzu i po podłączeniu rezystora.
(http://i.imgur.com/itFms7H.png)
Czas na kolejną funkcję. Porównywałem Saiteka z naszym układem i Saitek pomino nędznej elektroniki o wiele ładniej wracał do pozycji środkowej. Na 100% charaktrerystyka nie jest liniowa, raczej logarytmiczna w celu zapewnienia większej precyzji w okolicy zera. Na szczęście ATMEGA posiada sprzętowy mnożnik i możemy użyć y=x^2 na obu połówkach zakresu.
Po użyciu filtrów z poprzedniego posta wartość zmiennej przepuścić można przez poniższą funkcję:
uint16_t applyResponse16(uint16_t data)
{
uint16_t output;
uint32_t t32;
if (data &_BV(15))
{
data = data - 0x7FFF;
t32 = ((uint32_t)data) * data;
output = (t32>>15) + 0x7FFF;
}
else
{
t32 = ((uint32_t)data) * data;
output = (data<<1) - (t32>>15); //2*data - (data^2)
}
return output;
}
otrzymując coś takiego (czerwony= ch-ka liniowa, czarny=semi log)
(http://i.imgur.com/EvRS5SM.png)
-
Na 100% charaktrerystyka nie jest liniowa, raczej logarytmiczna w celu zapewnienia większej precyzji w okolicy zera.
Z tego co pamiętam gdy 20 lat wstecz zajmowałem się pośrednio projektowaniem koderów i dekoderów dla kanałów stereo w radiofonii to przechodziliśmy z charakterystyki liniowej przetworników na nieliniową dla małych sygnałów po to aby uzyskać lepszy stosunek sygnał/ szum kwantyzacji. W praktyce była to charakterystyka logarytmiczna.
-
Nie no... Patrząc na te funkcje - stopuję z pisaniem swojego programu :-) Czekam na efekt i montuję u siebie :-)
-
Hehe, czyli we dwóch czekamy na soft gotowy :) Ja oprócz czekania próbuję dobrze osadzić czujnik w pedałach, ale dobrać odpowiednio magnes(y) i odległości :P masakra
-
Mógłbyś dokładniej opisać te problemy?
Zakładam, że celem jest uzyskanie takiego przełożenia kąta obrotu na napięcie, żeby pokryć pełny zakres wejścia przetwornika i do tego pracować w liniowym regionie charakterystyki czujnika.
Jeśli problem jest w tym, że pełne wychylenie drąga w obie strony nie powoduje, że na wyjściu czujnika pojawi się 0-5V, to możemy na to coś zaradzić elektronicznie, do tego analogowo, żeby nie tracić rodzielczości przetwornika.
Po tych paru, myślę, że udanych eksperymentach z cyfrowym filtrowaniem zacząłem się zastanawiać, czy 16bit będzie naprawdę niezbędne.
W tej chwili wejście jest 10 bitowe, ta wartość jest przesuwana (mnożona) 6 bitów w lewo, tak aby otrzymać zmienną 16 bitową. Mimo to, wartość ciągle jest skwantowana jest 1024 poziomy. Ale - te schodki wpuszczamy na filtr cyfrowy operujący na 16 bitach. Schodki są wygładzane. Ciągle mamy 1024 dostępne poziomy, ale zmiany zachodzą łagodnie.
Może okaże się, że 12bitowy zewnętrzny przetwornik + porządne czyste zasilanie + kilka matematycznych operacji w rezultacie da całkiem niezłe rezultaty.
Postaram się udostępnić prosty skrypt to czytania 4 osi (X,Y,Z,Zrot). Narazie z użyciem wewnętrznego ADC 32U4.
-
Ta pogoń za bitami też mnie zastanawia. Jest to oczywiście szeroko dyskutowane na forach. A zastanawia mnie, bo przecież do gry/symulatora i tak wszystko idzie przez directX? Czy gry faktycznie wykorzystują faktycznie te 16 bitów?
-
Na tyle, na ile się orientuję, to w deskryptorze HID podajemy zakres wartości dla analogowych osi. Możemy tam podać dowolny zakres, ograniczony pewnie do potęg 2. DirectX po odebraniu danej i tak rzutuje i przesuwa zmienną na 16bitowy int. Chyba tak to działa. VKB_JoyTester pokazuje wszystkie osie jako 0-65535 i obok wartość Step, która wskazuje jaka jest rodzielczość sygnału źródłowego. Raczej możemy założyć, że gry/simy dostają wartości 16 bitowe.
-
Ta pogoń za bitami też mnie zastanawia
Z tego co pamiętam z mojej dawnej pracy z kanałami stereo dla przesyłania muzyki przez sieć to rezygnowaliśmy z 2 ostatnich bitów przetwornika liniowego po to aby zyskać na przesyłanym cyfrowym paśmie. Stosowaliśmy tak jak wspomniałem kompresję dla małych sygnałów oraz tzw. przeplot, ale to było inne zagadnienie. Może także w naszym przypadku nie potrzeba tak dokładnych przetworników.
-
Analogowy przedwzmacniacz dla halotronów i innych źródeł sygnału, gdzie ważne jest centrowanie i identyczny zakres działania w górę i w dół trochę się rozrósł:
(http://i.imgur.com/XYfbaIi.jpg)
Jeden kanał wymaga jednego poczwórnego wzmacniacza operacyjnego, ale za to:
- Posiada zabezpieczenia i filtry pierwotnej wersji.
- Pozwala na ustawienie wzmocnienia osobno dla górnej i dolnej połówki. Potencjometry w moim ST290 posiadają niejednakowy zakres dla dodatnich i ujemnych wychyleń. Podejrzewam, że w przypadku halotronów też tak będzie. Przy pomocy trymerków (docelowo precyzyjne wieloobrotowe) można sobie dokładnie poustawiać zakresy tak, aby pokrywały pełne 0-VREF przetwornika i zapewniały maksymalne wykorzystanie rozdzielczości.
- 3 potencjometr, niewidoczny na fotce, służył będzie do dokładnego ustawienia punktu zerowego.
W przypadku użycia halotronów, użyłbym magnesów takich, żeby wyjście dawało Pi*oko +/- 1/3 zakresu. Przetwornik będzie pracował na w miarę ładnym liniowym zakresie. Potem, przy pomocy powyższego układu, będzie można porozciągać górną i dolną połówkę tak, aby osiągały 0V i 5V, czy inne max napięcie przetwornika. No i oczywiście wycentrować dokładnie zero. To chyba załatwi sprawę z dobieraniem magnesów i odłegłości. Co ważniejsze, w domenie analogowej, bez utraty bitów.
Raczej nie ma sensu robić aż takich skomplikowanych operacji dla wszystkich osi. Myślę, że dodatkowa analogowa płytka z takimi układami dla 4 osi byłaby dobrym rozwiązaniem.
Czytałem właśnie, że ludzie chwalą
-
Hmm biorąc pod uwagę koszta dodatkowej płytki oraz elementów do niej, nie wiem, czy nie pokryły by się z kosztami ADS1115 - 16bitowy ADC - tak tylko mówię :) Dziś testuję ustawienie dwóch magnesów na łożysku tocznym 8x22x7 bo akurat zostało mi z projektu jedno.
(http://simhq.com/forum/files/usergals/2014/11/full-37484-90675-1061108610831083_107610741072_1084107210751085108010901072.jpg)
Chodzi mniej więcej o takie umieszczenie, aby ruch osi zmieniał dokładnie pole magnetyczne - wtedy czujnik bipolarny jaki akurat mam zczyta te wartości imho całkiem precyzyjnie :)
-
... TLE 5010. Ma 16 bit, ale pytanie jest, czy przy zakresie wychylenia ok. 40% to 16 bit będzie w pełni wykorzystane? Dotyczy to też innych przetworników 16 bit wrzucanych na prosto na wyjście czujnika bez dodatkowego dopasowania sygnału.
Cały czas chodzi o mi to, czy da się łatwo i precyzyjnie ustawić magnesy i ich odległości od czujnika, żeby wychylenie drążka dawało na wyjściu np 0-5VDC. Jak to wygląda w praktyce?
-
Golas możesz przedstawić swoje rozwiązanie. Mam na myśli jak wygląda fizyczny model do testów i jakie są potrzebne elementy elektryczne. Coraz bardziej myślę o modzie dla mojej przepustnicy, może to jest ten moment. Mogę także włączyć się do testów, ale muszę zrobić jakiś model.
-
Zaprojektowałem płytkę jako mały moduł dla jednej osi. Może być wpięty pomiędzy potencjometr albo czujnik, a wejście ADC.
Zamówiłem kilka szt. w OSHPark. Przyjdą za parę tygodni i przetestuję układ. A wygląda to tak:
(http://i.imgur.com/DtwOj4x.png)(http://i.imgur.com/9JoHc5V.png)
(http://i.imgur.com/CKbJgMa.png)
Ze względu na rozmiar zdecydowałem się na małe trymerki SMD. Powinny byc ok, zwłaszcza jeśli po wytrymowaniu moduł zabezpieczy sie np. rurką termokurczliwą.
Wejście PWR umożliwia zasilenie układu napięciem większym niż zakres ADC (czasem może się przydać). Można to ominąć przez zlutowanie zworki JP1.
Tak abstrahując od projektu joysticka, ten moduł mógłby znaleźć zastosowanie w naprawie innych joystików. Potencjometry w nich używane często są jakimiś specjalnymi seriami o mniejszym kącie działania (ST290 ma 45 stopniowe). Stosując ten moduł można użyć zwykłych, lub lepszej klasy standardowych potków o zakresie 300°. Będą działać tylko na krótkim odcinku, który możemy porozciągać do pełnego zakresu.
-
Zapraszam do przetestowania osi z filtrowaniem i zmienioną ch-ką., umownie będę ją nazywał "log".
Potrzebna będzie biblioteka AnalogScanner.
Podłączenia:
- X = A0, log
- Y = A1, log
- Z = A2, lin
- Zrot = A3, log
Program czyta też przyciski z jednego MCP23017. UART wyłączyłem. Na tym etapie właściwie nie jest już potrzebny. Do tego, wysyłanie całego pakietu danych zajmowało trochę czasu na czym cierpiała częstotliwość odświeżania parametrów joysticka.
Kod:
/*
MegaJoystick library test
for ATMEGA32U4 based Arduino boards
copyright (c) 2016, Piotr Zapart
128 buttons
6 16bit axis
17 16bit sliders
4 HATs
Connections:
UART (Serial1) use VT100 terminal emulator like PuTTy
D0-2k2-AdapterTX
D1-2k2-AdapterRX
I2C:
MCP23017 SCL - Arduino SCL -2k2-|
|-Vcc (pull ups)
MCP23017 SDA - Arduino SDA -2k2-|
D7 (INT6) - MCP23017 INTA+INTB (set to open collector)
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <arduino.h>
#include <MegaJoystick.h>
#include <Wire.h>
#include <BasicTerm.h>
#include <AnalogScanner.h>
//#include "resp.h"
#define FILTER_ARRAY_SIZE 6
#define ADC_BITS 10
//#define DEBUG_UART
const int MCP1_SLAVE_ADDR = 0x20;
const int MCP2_SLAVE_ADDR = 0x27;
const int k_Ravg_size = 7; //ADC running average size (2^n -1)
const uint16_t k_LPfltFeedforward=10;
bool btnUpdateRequest = true;
static volatile uint16_t adcRawData[8];
static volatile uint16_t adcFilteredData[8];
uint16_t temp16;
// Creates an instance of the analog pin scanner.
AnalogScanner scanner;
// The order in which we should scan the analog pins.
int scanOrder[] = {A0, A1, A2, A3, A4, A5};
const int SCAN_COUNT = sizeof(scanOrder) / sizeof(scanOrder[0]);
// ### deklaracje funkcji ###
void initMCP23017(uint8_t slaveAddr); //deklaracja funkcji inicjalizujacej
uint16_t readMCP23017(int8_t slaveAddr); //deklaracja funkcji odczytywania stanu portow
void sendUARTreport(void); //funkcja wysylajaca raport na terminal typu VT100 (np putty)
void updateJoyButtons(void); //
void drawUARTstartup(void);
void drawUARTbargraph(uint8_t column, uint8_t row, uint16_t value);
void ADCLowPassFilter(void);
BasicTerm term(&Serial1);
// -------------------------------------------------------------------------------------
// semi log taper
uint16_t applyResponse16(uint16_t data)
{
int32_t temp32;
uint16_t output;
uint32_t t32;
int16_t data_int =(data-0x7FFF);
if (data &_BV(15))
{
data = data - 0x7FFF;
t32 = ((uint32_t)data) * data;
output = (t32>>15) + 0x7FFF;
}
else
{
t32 = ((uint32_t)data) * data;
output = (data<<1) - (t32>>15); //2*data - (data^2)
}
return output;
}
// -------------------------------------------------------------------------------------
/*
ADC lowpass filter
*/
void ADCLowPassFilter(void)
{
static volatile uint32_t filt[FILTER_ARRAY_SIZE];
uint16_t temp16;
uint8_t i;
for (i = 0; i <FILTER_ARRAY_SIZE; i++)
{
adcRawData[i] = scanner.getValue(scanOrder[i]);
temp16 = adcRawData[i];
if ((temp16 >(filt[i] + k_LPfltFeedforward)) ||
((filt[i]>k_LPfltFeedforward)&&(temp16 < (filt[i] - k_LPfltFeedforward))))
{
filt[i] = temp16;
}
else
{
filt[i] *= k_Ravg_size;
filt[i] += temp16;
filt[i] /= (k_Ravg_size+1);
}
adcFilteredData[i] = filt[i];
}
}
// -------------------------------------------------------------------------------------
/*
Funkcja inicjalizujaca uklad MCP23017
wszystkie piny jako input + pullup
argument: adres I2C
BANK0 = 0 - wykorzystamy sekwencyjny zapis,
adres jest automatycznie inkrementowany
po kazdej operacji zapisu bajtu
*/
void initMCP23017(uint8_t slaveAddr)
{
// IODIRA -> IODIRB
Wire.beginTransmission(slaveAddr);
Wire.write(0x00); //IODIRA
Wire.write(0xFF); //portA = wejscia, adres skacze do 0x01=IODIRB
Wire.write(0xFF); //0x01 IODIRB = wejscia
Wire.write(0xFF); //0x02 IPOLA = odwrotna polaryzacja, przycisk wcisniety = 1
Wire.write(0xFF); //0x03 IPOLB = jw.
Wire.endTransmission();
// Pull-ups
Wire.beginTransmission(slaveAddr);
Wire.write(0x0C); //GPPUA
Wire.write(0xFF); //podciagnij wejscia A do VCC,nowy adres = 0x0D=GPPUB
Wire.write(0xFF); //podciagnij wejscia B do VCC
Wire.endTransmission();
//INTA & INTB - aktywne i otwarty kolektor
Wire.beginTransmission(slaveAddr);
Wire.write(0x04); //GPINTENA
Wire.write(0xFF);
Wire.write(0xFF);
Wire.endTransmission();
Wire.beginTransmission(slaveAddr);
Wire.write(0x0A); //IOCON, dla BANK = 0
Wire.write(_BV(2)|_BV(6)); //ODR = 1, MIRROR = 1
Wire.endTransmission();
}
// -------------------------------------------------------------------------------------
// Funkcja odczytujaca stany portow GPIOA i GPIOB
// stan zwracany jest w postaci 16bitowego slowa,
// gdzie jeden bit odpowiada jednemu przyciskowi
uint16_t readMCP23017(int8_t slaveAddr)
{
uint8_t output[2];
uint8_t index = 0;
Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adress
Wire.write(0x12); //ustaw wewnetrzny adres na GPIOA
Wire.endTransmission(); //I2C stop
Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adres
Wire.requestFrom(slaveAddr,2,false); //grzecznie popros o 2 bajty
//po odczytaniu GPIOA wewnetrzny adres
//automatycznie zostanie zwiekszony o 1.
//czyli wyladuje na GPIOB
//"true" na koncu generuje I2C stop i zwalnia
//magistrale, Wire.endTrasmission nie jest potrzebny
while (Wire.available())
{
output[index] = Wire.read(); //wpisz GPIOA i B do tablicy
index++;
}
Wire.endTransmission();
return uint16_t(output[0] | ((output[1])<<8)); //zgrupuj oba bajty w 16 bitowe slowo
}
// -------------------------------------------------------------------------------------
/*
128 buttons, 16 buttons pro MCP23017 = 8 banks
*/
//3 rodzaje odczytywania stanu przyciskow
// pojedynczo, w 8 bitowym bloku i 16 bitowym bloku
// odkomentowac jedna z ponizszych linii
//#define BUTTON_SINGLE_READ
//#define BUTTON_8BIT_READ
#define BUTTON_16BIT_READ
void updateJoyButtons(void)
{
// czytanie stanu przyciskow pojedynczo
#ifdef BUTTON_SINGLE_READ
uint8_t i;
uint16_t btnBank[8];
btnBank[0] = readMCP23017(MCP1_SLAVE_ADDR);
//btnBank[1] = readMCP23017(MCP2_SLAVE_ADDR);
// ...
// btnBank[7] = readMCP23017(MCP8_SLAVE_ADDR);
Joystick.setAutoSend(false); //wylaczamy autosend, bedzie wyslany jeden raz na koncu
for (i=0; i<16; i++)
{
if (btnBank[0] & (1<<i)) Joystick.setButton(i,1);
else Joystick.setButton(i,0);
if (btnBank[1] & (1<<i)) Joystick.setButton(i+16,1);
else Joystick.setButton(i+16,0);
//...
// if (btnBank[2] & (1<<i)) Joystick.setButton(i+32,1);
// else Joystick.setButton(i+32,0);
// if (btnBank[3] & (1<<i)) Joystick.setButton(i+48,1);
// else Joystick.setButton(i+48,0);
// if (btnBank[4] & (1<<i)) Joystick.setButton(i+64,1);
// else Joystick.setButton(i+64,0);
// if (btnBank[5] & (1<<i)) Joystick.setButton(i+80,1);
// else Joystick.setButton(i+80,0);
// if (btnBank[6] & (1<<i)) Joystick.setButton(i+96,1);
// else Joystick.setButton(i+96,0);
// if (btnBank[7] & (1<<i)) Joystick.setButton(i+112,1);
// else Joystick.setButton(i+112,0);
}
//Joystick.sendState();
//Joystick.setAutoSend(true);
#endif
// 8 bitowy blok, dla przykladu jeden z portow pierwszego MCO23017
#ifdef BUTTON_8BIT_READ
Joystick.setButtonBank8(0,readMCP23017(MCP1_SLAVE_ADDR)); //zapisuje bank 0
Joystick.setButtonBank8(1,(readMCP23017(MCP1_SLAVE_ADDR))>>8); //zapisuje bank 1
//setButtonBank8(2,readMCP23017(MCP2_SLAVE_ADDR)); //zapisuje bank 2
//setButtonBank8(3,(readMCP23017(MCP2_SLAVE_ADDR))>>8); //zapisuje bank 3
#endif
// 16 bitowy blok
#ifdef BUTTON_16BIT_READ
Joystick.setButtonBank16(0,readMCP23017(MCP1_SLAVE_ADDR)); //zapisuje bank 0 i 1
//setButtonBank16(0,readMCP23017(MCP2_SLAVE_ADDR)); //zapisuje bank 2 i 3
#endif
}
// -------------------------------------------------------------------------------------
void drawUARTbargraph(uint8_t row, uint8_t column, uint16_t value)
{
char bar[17];
uint8_t i;
term.position(row,column);
for (i=0;i<16;i++)
{
if ((value>>12)>i) bar[i] = '#';
else bar[i] = ' ';
}
bar[16] = '\0';
term.print(bar);
}
// -------------------------------------------------------------------------------------
void sendUARTreport(void)
{
uint8_t i,j;
//Buttons
//j = bank number
for (j=0;j<8;j++)
{
term.position(j+3,0);
for (i=0;i<16;i++)
{
if (Joystick.getButton((j<<4)+i)) //j*16+i=button No
{
term.set_color(BT_RED, BT_BLACK);
term.write('1');
}
else
{
term.set_color(BT_CYAN, BT_BLACK);
term.write('0');
}
term.write(' ');
}
term.print("\t");
}
term.set_color(BT_WHITE, BT_BLACK);
drawUARTbargraph(13,9, Joystick.getXAxis());
drawUARTbargraph(14,9, Joystick.getYAxis());
drawUARTbargraph(15,9, Joystick.getZAxis());
drawUARTbargraph(16,9, Joystick.getXAxisRotation());
drawUARTbargraph(17,9, Joystick.getYAxisRotation());
drawUARTbargraph(18,9, Joystick.getZAxisRotation());
drawUARTbargraph(19,9, Joystick.getSlider(0));
drawUARTbargraph(20,9, Joystick.getSlider(1));
term.position(21,9); term.print(Joystick.getHatSwitch(0));term.print(F(" "));
term.position(22,9); term.print(Joystick.getHatSwitch(1));term.print(F(" "));
term.position(23,9); term.print(Joystick.getHatSwitch(2));term.print(F(" "));
term.position(24,9); term.print(Joystick.getHatSwitch(3));term.print(F(" "));
}
// -------------------------------------------------------------------------------------
void drawUARTstartup(void)
{
// puTTY terminal
term.init();
term.cls();
term.show_cursor(false);
term.position(0,0);
term.set_attribute(BT_NORMAL);
term.set_attribute(BT_BOLD);
term.print(F("Arduino Joystick Monitor\t"));
term.set_attribute(BT_NORMAL);
term.position(1,0);
term.print(F("Button status:\t"));
term.position(2,0);
term.print(F("0 1 2 3 4 5 6 7 8 9 A B C D E F\t"));
term.position(12,0);
term.println(F("Axis:\t"));
term.println(F("X=\t"));
term.println(F("Y=\t"));
term.println(F("Z=\t"));
term.println(F("Xrot=\t"));
term.println(F("Yrot=\t"));
term.println(F("Zrot=\t"));
term.println(F("Slider0=\t"));
term.println(F("Slider1=\t"));
term.println(F("HAT0=\t"));
term.println(F("HAT1=\t"));
term.println(F("HAT2=\t"));
term.println(F("HAT3=\t"));
}
// -------------------------------------------------------------------------------------
// INT6 interrupt, ktos cos wcisnal
ISR(INT6_vect)
{
btnUpdateRequest = true;
EIMSK &= ~(1<<INT6); // wylacz przerwanie
}
// -------------------------------------------------------------------------------------
void setup()
{
// INT6
pinMode(7,INPUT_PULLUP);
digitalWrite(7,HIGH);
EICRB |= (1<<ISC61);//|(1<<ISC60); // wyzwalane zboczem opadajacym
EIMSK |= (1<<INT6); // uruchom przerwanie
//Piny uzyte go testowania HAT bez uzycia MCP23017
pinMode(6,INPUT_PULLUP);
pinMode(5,INPUT_PULLUP);
pinMode(4,INPUT_PULLUP);
pinMode(3,INPUT_PULLUP);
Serial1.begin(115200);
while (!Serial1);
Joystick.begin();
Wire.begin();
scanner.setScanOrder(SCAN_COUNT, scanOrder);
scanner.beginScanning();
#ifdef DEBUG_UART
drawUARTstartup();
#endif
initMCP23017(MCP1_SLAVE_ADDR);
//initMCP23017(MCP2_SLAVE_ADDR);
Joystick.setAutoSend(false);
}
void loop()
{
//odczytaj przyciski jesli sa nowe dane
if (btnUpdateRequest == true)
{
updateJoyButtons();
btnUpdateRequest = false;
EIMSK |= (1<<INT6); // ponownie uruchom przerwanie INT6
}
//analog inputs
ADCLowPassFilter();
//os X - log
temp16 = applyResponse16(adcFilteredData[0]<<6);
Joystick.setXAxis(temp16);
//os Y - log
temp16 = applyResponse16(adcFilteredData[1]<<6);
Joystick.setYAxis(temp16);
//os Z - lin
Joystick.setZAxis(adcFilteredData[2]<<6);
// os Zrot - log
temp16 = applyResponse16(adcFilteredData[3]<<6);
Joystick.setZAxisRotation(temp16);
// ########## HATs ###########
// 5 sposobow uaktualniania stanu HATow
// odkomentowac jedna z ponizszych deklaracji
//#define HAT_TEST_DEGREE
//#define HAT_TEST_BUTTON_LIST
//#define HAT_TEST_8BIT
//#define HAT_TEST_16BIT
//#define HAT_TEST_ANALOG
#ifdef HAT_TEST_DEGREE
//### Metoda 1 ###
//Jako parametr wejsciowy funkcja przyjmuje numer HATa (0-3) i kat w stopniach, (zakres 0-360, -1 odpowiada OFF)
//przyklad czyta analoghowa wartosc wejscia A0, mapuje ja na zakres -1 ... 360 i ustawia HATy
//int16_t angle = analogRead(0);
angle = map(angle,0,1023,0,360);
if (angle < 5) angle = -1;
Joystick.setHatSwitchDg(0,angle);
#endif
#ifdef HAT_TEST_BUTTON_LIST
//### Metoda 2 ###
// funkcja przyjmuje numer HATa i nuery pinow czterech przyciskow w kolejnowsci gora, prawo, dol, lewo
// pamietac o odpowiednim ustawieniu wejsc! input+pullup
// niezbyt efektywna w metoda, uzywac jesli nie ma innej opcji
Joystick.setHatSwitch(0,6,5,4,3);
Joystick.setHatSwitch(1,6,5,4,3);
Joystick.setHatSwitch(2,6,5,4,3);
Joystick.setHatSwitch(3,6,5,4,3);
#endif
#ifdef HAT_TEST_8BIT
//### Metoda 3 ###
// sluzy do jednoczesnego odcyztania dwoch HATow podlaczonych do 8bitowego portu
// np polowa MCP23017.
// Zakladamy, ze 2 HATy podlaczone sa do jednego MCP23017 w sposob opisany ponizej:
//(Right, Down, Left, Up, Hat0 Hat1)
// 7 6 5 4 3 2 1 0
// R1 D1 L1 U1 R0 D0 L0 U0
Joystick.set2HatSwitch(0,readMCP23017(MCP1_SLAVE_ADDR)); //wpisane beda HAT0 i HAT1
Joystick.set2HatSwitch(2,readMCP23017(MCP1_SLAVE_ADDR)>>8); // HAT2 i HAT3
#endif
#ifdef HAT_TEST_16BIT
//### Metoda 4 ###
//Zakladamy, ze 4 HATy podlaczone sa do jednego MCP23017 w sposob opisany ponizej:
//(Right, Down, Left, Up, Hat0 Hat1,Hat2,Hat3)
//F E D C B A 9 8 7 6 5 4 3 2 1 0
//R3 D3 L3 U3 R2 D2 L2 U2 R1 D1 L1 U1 R0 D0 L0 U0
Joystick.set4HatSwitch(readMCP23017(MCP1_SLAVE_ADDR));
#endif
#ifdef HAT_TEST_ANALOG
//### Metoda 5 ###
//analogowy mini joystick uzyty jako HAT switch. Wymagane dwa wejscia analogowe
//argumenty:
//numer HATa, analogowy pin osi X (lewo/prawo), analogowy pin osi Y (gora/dol), prog zadzialania 0-10
Joystick.setHatSwitchAnalog(0,0,1,8); //HAT0, A0=x, A1=y, prog = 8
#endif
Joystick.sendState();
#ifdef DEBUG_UART
sendUARTreport();
#endif
}
-
Otóż zaopatrzywszy się w długopisy BICa :) robię coś na kształt tego:
(http://www.geneb.org/images/bearing_magnets_and_shaft.jpg)(http://www.simpits.org/geneb/wp-content/uploads/2011/05/control_arm_mounting.jpg)(http://www.simpits.org/geneb/wp-content/uploads/2011/05/pitch_and_roll_halls.jpg)
Mocowaniem wyfrezowane/wycięte będzie jutro - dzisiaj jest 'sklejone' z plasteliny :P
Ogólnie wytłumaczone mocowanie poprawne czujnika/magnesu jest dostępne tutaj: LINK (http://www.mycockpit.org/forums/content.php?r=88-Hall-Effects-Sensors-to-make-a-joystick)
-
Zniknął już przycisk modyfikacji posta ;/ ew mod/admin może scalić posty?
(http://i.imgur.com/GXbIm9E.png)(http://i.imgur.com/Cfs3YBZ.jpg)
'Z ręki' kręcone bez stałej osi na 10bitowym przetworniku atmegi bez żadnej filtracji w mmjoy'u - jutro będę opracowywał system montażu na pojedyncze osie.
Użyte magnesy to neodymy z dysków twardych 5x5x1,5mm oraz HONEYWELL SS495A1
-
Dzięki golas za informację. 3.14ter na czym ma polegać test. Mam 4 pots oraz jeden joystick i 2 MC23017. Mogę podłączyć pots do wejść A0-A3 i obserwować programem VBK JT zmieniając zakresy i obserwując charakterystyki. Czy chodzi o sprawdzenie działania programu. Pots są połączone bezpośrednio do Arduino bez filtrów.
-
Zastanawiam się, czy nie warto byłoby użyć takich magnesów :)
http://www.magnesy.eu/mp-10-x-6-x-4--n38---magnes-neodymowy-t-2301.html
-
Zaprojektowałem płytkę jako mały moduł dla jednej osi. Może być wpięty pomiędzy potencjometr albo czujnik, a wejście ADC.
Zaraz, bo się pogubiłem. To jest płytka takiego filtro/wmacniacza sygnału? Jaki koszt? 4szt by mi się przydały na początek.
-
Coraz częściej słyszę właśnie o OSHPark - jak tam z cenami i wysyłką do Polski? Bo jeżeli cenowo faktycznie jak w opisie to lepiej niż w polsce z dokumentacjami do pojedyńczych pcn
-
Gdzie mogę pobrać biblioteki AnalogScanner.h oraz resp.h.
-
Znalazłem brakujące biblioteki AnalogScaner.h oraz resp.h mam nadzieję, że są dobre. Widzę, że resp.h jest zablokowana w programie.
Kompilacja jest ok sprawdzę później mój model i dam znać.
-
Sprawdziłem program na moim modelu. MCP23017 adres 20 działa, osie działają zgodnie z założeniami tzn. A0->X, A1->Y, A2-> Z oraz A3->obr Z. Przejście przez środek jest logarytmiczne z wyjątkiem osi Z (przejście liniowe).
-
Zaraz, bo się pogubiłem. To jest płytka takiego filtro/wmacniacza sygnału? Jaki koszt? 4szt by mi się przydały na początek.
Tak jest, w zamierzeniu miał to być mały pojedynczy moduł, którym można udoskonalić również już istniejące kontrolery.
Zanim udostępnię projekt, chciałbym go sprawdzić w działaniu. Niby prosty układ i raczej nie powinno być niespodzianek, ale pan Murphy rzadko chodzi spać.
Po zweryfikowaniu projektu udostępnię go w bazie OSHpark. Będzie można jednym klikiem od razu zamówić sobie płytki w setach po 3 szt. Za jeden set wyszło coś koło 6$. W wersji podstawowej przesyłka jest darmowa jako list w kopercie bąbelkowej. Jak z jej przebiegiem do PL, niestety nie miałem okazji sprawdzać, rzadko bywam obecnie. Nie powinno być problemów.
OSHPark używam do niewielkich płytek, gdyż płaci się u nich od cala^2. W tej kategorii są nawet tańsi od Chin. Jakość płytek jest bardzo dobra, a do tego są po prostu ładne. Firma wywodzi się od jednego zapaleńca hobbysty, który chciał stworzyć tańszą opcję profesjonalnych płytek dla takich jak on. I muszę przyznać, że sporego rozwoju ciągle są aktywni w tych rejonach. Już za to mają u mnie plus :)
Np. jakiś czas temu udostępniłem na ich stronie jeden z moich projektów. Tak im się spodobał, że wylądował na ich blogu, a na drugi dzień w skrzynce znalazłem kupon na 10$! Przydał się wczoraj.
Znalazłem brakujące biblioteki AnalogScaner.h oraz resp.h mam nadzieję, że są dobre. Widzę, że resp.h jest zablokowana w programie.
Kompilacja jest ok sprawdzę później mój model i dam znać.
#include "resp.h" można spokojnie usunąć. To pozostałość po testach, nie jest żadną biblioteką, tylko dodatkowym plikiem z tablicą wartości dla funkcji log. Końcowo użyłem prostszej metody.
-
Mam już moduł XM-15 odpowiednik HC05. Różni się tym, że posiada konwerter napięć. Kupiłem go na Allegro http://allegro.pl/show_item.php?item=5756899669
Mam też moduł bluetooth 2.1 na USB po stronie pc kupiony także na Allegro http://allegro.pl/show_item.php?item=5229707460&snapshot=MjAxNi0wOC0wN1QxMToxNjozNFo7YnV5ZXI7NDE0ZjFkZDVhNjExZTc3MGVmOTZhMGU1ODE1NjI2YmQxZjgwNjQ2OWU1M2VkYzZmOGI4NTkzMTYxZjAxM2Y5Yg==
Przy pomocy kolegi 3.14ter udało się sparować XM-15 z pc. W Internecie pod linkiem http://www.braesidewebdesign.com/electroblog/XM-15B jest przykład połączenia modułu XM-15 z Arduino UNO oraz prosty przykład szkicu do komunikacji z pc.
#include <SoftwareSerial.h>
SoftwareSerial Bluetooth(10, 11); // (RX, TX)
void setup()
{
pinMode(9, OUTPUT); // this pin will pull the XM-15B CE pin HIGH to enable the module
digitalWrite(9, HIGH);
Serial.begin(9600);
Serial.println("AT Command:");
Bluetooth.begin(9600); // XM-15B default speed
}
void loop()
{
// read from XM-15B ==> Serial Monitor
if (Bluetooth.available())
Serial.write(Bluetooth.read());
// read from Serial Monitor ==> XM-15B
if (Serial.available())
Bluetooth.write(Serial.read());
}
Po uruchomieniu tego przykładu zgłasza się na monitorze szeregowym napis AT Command: zgodnie z setup. Wpisanie komendy AT i jej wysłanie nie powoduje żadnej reakcji (powinno być OK). Pytanie czy faktycznie mój moduł XM-15 komunikuje się z pc. Jak to można sprawdzić.
-
Mam problem co dalej z moja komunikacją przez bluetooth. Zagadnienie jest dla mnie nowe, dlatego błądzę. Wiem, że niektórzy mają u siebie ten rodzaj komunikacji i może coś doradzą. Zrobiłem zrzuty na 3 obrazkach. Wydaje się, że moduły powinny się komunikować. Pytanie dlaczego w szkicu (przykładzie) z mojego poprzedniego post nie ma odpowiedzi na komendę AT czyli OK. Niebieska dioda LED w XM-15 migoce zgodnie z opisem na monitorze szeregowym jest napis "AT Command:" , ale brak odpowiedzi na AT. Testy wykonałem na UNO.
(http://i700.photobucket.com/albums/ww5/vito_zm/sp-3.jpg) (http://s700.photobucket.com/user/vito_zm/media/sp-3.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/sprz-1.jpg) (http://s700.photobucket.com/user/vito_zm/media/sprz-1.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/sprz-2.jpg) (http://s700.photobucket.com/user/vito_zm/media/sprz-2.jpg.html)
Nie jestem pewny czy ma sens przejście na Leonardo i testowanie programu MegaJoy z modułem XM-15 jeśli są problemy w UNO i prostym szkicu testowym. Przy okazji pytanie do 3.14ter. Jak połączyć pin CE/CLR z XM-15, czy z Leonardo (jaki pin) czy do VCC. Co do pozostałych pinów w XM-15 to RXD z pin TX (1) oraz TXD z RX(0) w Leonardo. Czy ostatnia wersja MegoJoy ma komunikację przez putty. Mam nadzieję, że w końcu bluetooth zadziała.
-
Adaptery Serial/Bluetooth, jak HC05, HC06, XM-15 pracują w dwóch trybach:
- normalny tryb komunikacji, połączenia:
Adapter TX - badany układ RX
Adapter RX - badany układ TX
GND - GND
VCC - VCC
i nic więcej. Zakładam, że jest już sparowany z PC i widoczny w systemie jako dodatkowe jeden/dwa porty COM. Po włączeniu zasilania dioda miga dość szybko. Uruchamiamy PuTTy, czy inny terminal w PC i wybieramy numer COM wykrytego wcześniej adaptera, prędkość transmisji (fabrycznie 9600) i resztę parametrów jeśli potrzeba. Po ustanowieniu połączenia dioda moga dwukrotnie co jakiś czas. (tak jest w HC05, XM-15 może mieć inaczej). Układ jest gotowy do pracy.
- tryb komend AT. Jest to jakby wejście w ustawienia adaptera. W tym trybie przyjmuje on tylko zestaw komend, których wykaz można znaleźć w sieci. Ustawia się np. standardową prędkość transmisji, czy nazwę adaptera z jaką pojawi się on po przeskanowaniu otoczenia przez Bluetooth. Żeby ten tryb odpalić potrzebna jest zazwyczaj jakaś dodatkowa operacja. W HC05 musiałem zewrzeć jeden z pinów do masy i przeresetować adapter. W XM-15 jest to chyba ta linia CE. Ale, ale... jak to bywa z chińskimi producentami, wcale tak nie musi być, często istnieje kilka wersji sprzętowych pod tą samą nazwą. Najlepiej zajrzeć do dokumentacji, która niestety napisana jest w czystym Chinglish prosto z translatora.
W zasadzie użycie tego trybu nie jest potrzebne do normalnej pracy, używamy go jedynie, gdy chcemy zmienić jakieś ustawienia.
Do przetestowania komunikacji PC<-->XM-15 należy:
1. Zewrzeć TX z RX w XM-15, utworzy to pętlę.
2. Uruchomić program terminala na PC. Nie wiem czy to wina mojego systemu, czy programu, ale nie udało mi się jeszcze poprawnie nawiązać połączenia przy pomocy Terminal1.9b. Listuje wszytkieg porty COM, ale w rozwijanym menu są tylko dwa, nie te co trzeba oczywiście. Oprócz PuTTy używam i polecam również Termite (http://www.compuphase.com/software_termite.htm), jest nawet w polskiej wersji językowej.
3. Prosto z fabryki XM=15 ustawiony jest na 9600baud, 8N1, itd. Standardowe ustawienie.
4. Wpisujemy cokolwiek i wysyłamy. To samo powinno wrócić z powrotem.
Jeszcze odnośnie numerów COM. Po wykryciu adaptera przez Win pojawiają się u mnie dwa nowe numery. Jeden z nich nie działa. Trzeba spróbować obydwóch lub zajrzeć głębiej w ustawienia sprzętowe XM-15. Gdzieś tam powinien pojawić się właściwy numer.
Jeśli tak jest, to komunikacja działa. Zostawiamy już to 9600 i w programie joysticka zmieniamy linijkę
Serial1.begin(115200); na Serial1.begin(9600);
-
Dzięki 3.14ter za informacje. U mnie jest tak jak na obrazku COM12 i COM13 gdzie COM12 jest tym do komunikacji. Po wpisaniu w PuTTy COM12 program jest gotowy do działania. W XM-15 dioda z migającej świeci ciągle.
Z komendami AT na razie daję sobie spokój i instaluję XM-15 do Leonardo. Następnie odpalę program MegaJoy. Jeśli nie potrafię zmienić komendami AT ustawienia fabrycznego 9600 na 115200 to faktycznie zrobię to w programie MegaJoy. Dam znać jak poszło.
-
3.14ter wspomniałeś o ile się nie mylę, że w ostatniej wersji MegaJoy wyłączyłeś transmisję, czy możesz to sprawdzić. U mnie kursor w putty jest na początku i czeka.
-
W starszej wersji MegaJoy działa komunikacja po bluetooth. W najnowszej jest transmisja wyłączona. Dzięki 3.14ter za pomoc, teraz zobaczę co z tymi komendami AT. Dobrze byłoby zwiększyć transmisję na 115200
-
Odkomentowanie linii:
#define DEBUG_UART
w nowszej wersji włączy ponownie nadawanie raportu przez UART.
Jedna rzecz jeszcze z trybem AT. HC05 i XM-15 wymagają, żeby na końcu komunikatu automatycznie dołączać znaki CR+LF. Trzeba to zaznaczyć w ustawieniach terminala. Może w tym był problem.
-
Dzięki za informacje. Na koniec pytanie. Chcę próbować testować te komendy AT.
W jakim układzie testowym czy ten mój stary z UNO czy może z Leonardo. Jak połączyć czy przez porty TX, TX w Arduino czy dowolny port tak jak w moim przykładzie. Jaki użyć do tego szkic. Może jest gdzieś jakiś opis jak to zrobić.
-
Na tyle, na ile udało mi się zrozumieć translatorowy angielski, to XM-15 działa nieco inaczej niż HC05.
Wejście CE to chip enable, główny włącznik modułu. Pin jest podwieszony do VCC, więc domyślne ustawienie jest ON. Możemy go zostawić w spokoju i nie podłączać, albo podłączyć do VCC.
Wg dokumentacji, XM-15 póki nie nawiąże połączenia przez Bluetooth z hostem, pozostaje w trybie AT. Po nawiązaniu połączenia przechodzi automatycznie do trybu DATA. Dlatego należy wyłączyć wszystkie inne terminale, które mogą próbować podłączyć się przez Bluetooth i przestawić moduł z AT na DATA.
Do nadawania komend AT potrzebujemy drugi adapter. Akurat w tym przykładzie z linku było to UNO.
Skrypt tworzy drugi programowy port serial, stąd można użyć innych pinów niż sprzętowe RX i TX.
XM-15 TX -> UNO 10 (RX)
XM-15 RX <- UNO 11 (TX)
GND - GND
VCC - VCC
Schemat jest poprawny i powinien działać. SerialMonitorem z Arduino łączysz się z Uno. Upewnij się tylko, żeby na końcu dołączał NL+CR, te dwa dodatkowe znaki, nowa linia i powrót karetki.
-
Dzięki 3.14ter, już działa. Jeśli damy powrót karetki i wyślemy AT to odpowie OK. Jeśli ustawimy zarówno NL i CR to na komendę AT odpowie -5. Niby trywialna sprawa, ale zabrało to trochę czasu. Teraz mogę ustawić na większą prędkość nadawania. Jeszcze raz dziękuje za pomoc i za zabranie Twojego czasu, dzięki.
-
Po ostatnich moich doświadczeniach z transmisją radiową (bluetooth) wpadłem na pomysł aby zastosować tę technikę do innych kontrolerów. Chcę wykonać testy z SimOUT oraz modułem XM-15. Połączenie SimOut z pc wymaga konwertera USB-RS232. Mam zamiar usunąć MAX232 oraz jego otoczenie i zastąpić go modułem XM-15. Ponieważ moduł ma regulator napięcia to nie potrzeba dodatkowych rezystorów redukujących napięcie 5V.
Z tego co zrozumiałem to możemy takich modułów XM-15 mieć kilka współpracujących z modułem USB (bluetooth) w pc wystarczy tylko komendami AT zmienić nazwy i ustawić parametry transmisji szeregowej. W platformie HSC ustawiamy tylko odpowiedni port COM.
Reasumując opłaciło się drążyć temat, ponieważ można to wykorzystać także w innych kontrolerach. Dzięki 3.14ter za pomoc w tym temacie.
-
Zauważyłem dzisiaj w wątku http://il2forum.pl/index.php/topic,17010.new.html#new #35, że kolega sznink zrobił u siebie to samo co 3.14ter tzn. zastosował to samo filtrowanie x2. Ma problemy z zakresami, ale może proponowany moduł przez 3.14ter rozwiąże ten problem.
-
Przepraszam za offtopa, czy jest szansa na rozwinięcie tematu CY8CKIT-059 . Czy raczej potraktować zapowiedź jako egzotyczne wcięcie? Na aliexpresie moduły 049 chodzą po 6- 7 dolców.
-
Narazie jedziemy z projektem na Arduino. Jeśli nie uda mi się stworzyć pełnego projektu na PSoC5LP, to przynajmniej postaram się napisać podstawową bibliotekę, podobną do tej na Arduino.
Uwaga!
049 != 059
049 to PSoC4, 059 PSoC5LP
-
Jak duża różnica jest między 049, a 059 jeśli chodzi o przydatność do naszych celów?
-
Dość istotna: 049, czyli procesor typu PSoC4 nie posiada USB.
-
Dziękuję za odpowiedź :)
-
Zrobiłem kolejne testy. Zmieniłem szybkość transmisji na 115200 oraz nazwę MX-15. Teraz pracuje z MegaJoy z prędkością 115200. Tutaj wystąpił ciekawy problem. Jeśli wpiszemy komendę AT+UART=115200,1,0 to jest problem w monitorowaniu MegaJoy programem PuTTY (tekst jest nieczytelny, generalnie bałagan). Musi być deklaracja 115200,0,0. Myślałem może, że to dotyczy bitu STOP, ale nie mam pojęcia dlaczego tak się dzieje. Fabryczne ustawienie MX-15 to 9600,0,0 i w tym ustawieniu pracuje także z MegoJoy przez PuTTY. Ważne, że pracuje może ktoś to wyjaśni.
Zainstalowałem program Termite 3.2. Jest bardzo prosty i niezawodny. Można komunikować się po bluetooth pc (Termite 3.2) z UNO (szeregowy monitor) programem do konfiguracji modułu MX-15.
Do monitorowania przy pomocy MX-15 oraz PuTTY używałem starszych wersji MegoJoy. W najnowszym programie MegaJoy odblokowanie #define DEBUG_UART nie pomogło, ale to jest to zrobienia.
Chcę w przyszłosci stosować moduły MX-15 do komunikacji z SimOUT. Zastanawiam się nad problemem konfiguracji oraz parowania większej liczby tych modułów. Czy należy na początek zmienić nazwy oraz przepływność (w zależności od potrzeb) a później parować z pc. Każdy moduł będzie komunikował się po innym COM oraz z innymi parametrami. Czy tak to należy zrobić.
-
Na wstępie chciałbym pogratulować kolegom tworzącym ten wątek - kawał porządnej profesjonalnej roboty. Jak znajdę chwilę czasu to się z chęcią przyłączę :).
Zauważyłem dzisiaj w wątku http://il2forum.pl/index.php/topic,17010.new.html#new #35, że kolega sznink zrobił u siebie to samo co 3.14ter tzn. zastosował to samo filtrowanie x2. Ma problemy z zakresami, ale może proponowany moduł przez 3.14ter rozwiąże ten problem.
Niestety nie korzystałem z własnego kodu, a z możliwości jaką udostępnia MMJoy2. Z moich testów wynika, że ta funkcjonalność bardzo dobrze sprawdza się w przypadku sensorów Alegro A1302. Natomiast dla potencjometrów jest już gorzej, co nie znaczy że kompletnie nie nadaje się do użytku. Dzięki włączonemu filtrowaniu mogę używać jednego z potencjometrów na dźwigni przepustnicy joysticka Saitek X45 (oryginalnie przeznaczonego dla steru kierunku - ja go używam jako zoom). Bez filtrowania w moim przypadku ten potencjometr był bezużyteczny.
Chmm. Przypomniało mi się, że kiedyś mega_mozg_13 (twórca MMJoy2) coś pisał na temat implementacji. Poszukałem i ... znalazłem (http://simhq.com/forum/ubbthreads.php/topics/3902564/Re:_MMJoy_-_Build_your_own_USB#Post3902564 (http://simhq.com/forum/ubbthreads.php/topics/3902564/Re:_MMJoy_-_Build_your_own_USB#Post3902564)):
Look here: https://code.google.com/p/mmjoy/source/browse/
Folder: common_libs
File: MMJoy.c
Function: Axis_Filter()
PS: All project materials are open source.
Read more: http://simhq.com/forum/ubbthreads.php/topics/3899105#ixzz4H3pbHWPw
Follow us: @SimHQ on Twitter | SimHQ on Facebook
Niestety od tego posta projekt zmienił lokalizację i gdzie teraz są kody źródłowe w tej cyrylicy?
-
Niestety nie korzystałem z własnego kodu, a z możliwości jaką udostępnia MMJoy2.
Ja także przeszedłem ten etap tzn. MMJoy2, ale w celach poznawczych. Trochę o tym pisałem na początku tego wątku. Pojawił się 3.14ter i sytuacja zmieniła się radykalnie. Nie spotkałem na forach zbyt dużo specjalistów tej klasy. Dla nas jest to duża szansa, że powstanie coś nowego i to z najwyższej półki.
-
Zrobiłem kolejne testy. Zmieniłem szybkość transmisji na 115200 oraz nazwę MX-15. Teraz pracuje z MegaJoy z prędkością 115200. Tutaj wystąpił ciekawy problem. Jeśli wpiszemy komendę AT+UART=115200,1,0 to jest problem w monitorowaniu MegaJoy programem PuTTY (tekst jest nieczytelny, generalnie bałagan). Musi być deklaracja 115200,0,0. Myślałem może, że to dotyczy bitu STOP, ale nie mam pojęcia dlaczego tak się dzieje. Fabryczne ustawienie MX-15 to 9600,0,0 i w tym ustawieniu pracuje także z MegoJoy przez PuTTY. Ważne, że pracuje może ktoś to wyjaśni.
http://www.linotux.ch/arduino/HC-0305_serial_module_AT_commamd_set_201104_revised.pdf
Strona 8 i 9. W skrócie, 0 jako drugi parametr oznacza 1 bit stop, następne 0 to brak parzystości. Czyli standardowe parametry jakie używane są w terminalach.
Zainstalowałem program Termite 3.2. Jest bardzo prosty i niezawodny. Można komunikować się po bluetooth pc (Termite 3.2) z UNO (szeregowy monitor) programem do konfiguracji modułu MX-15.
Do monitorowania przy pomocy MX-15 oraz PuTTY używałem starszych wersji MegoJoy. W najnowszym programie MegaJoy odblokowanie #define DEBUG_UART nie pomogło, ale to jest to zrobienia.
Chcę w przyszłosci stosować moduły MX-15 do komunikacji z SimOUT. Zastanawiam się nad problemem konfiguracji oraz parowania większej liczby tych modułów. Czy należy na początek zmienić nazwy oraz przepływność (w zależności od potrzeb) a później parować z pc. Każdy moduł będzie komunikował się po innym COM oraz z innymi parametrami. Czy tak to należy zrobić.
U mnie odblokowanie DEBUG_UART uruchamia komunikację. Problem leży pewnie gdzieś indziej.
Udało mi się sparować dla moduły HC-05. Pojawiły się dwa nowe porty COM. Oprócz nazw każdy moduł ma jeszcze swój adres bluetooth, coś jak adres MAC karty sieciowej. Teoretycznie każde urządzenie powinno mieć swój indywidualny numer, ale jak wiemy, producenci dalekowschodni często robią różne skróty i może się okazać, że dwa moduły będą miały taki sam. W takim wypadku adres można zmienić komendami AT.
A ja tymczasem czekam na zamówione czujniki halla i przetworniki AD do testów. Układ na 32U4 ciągle ewoluuje. Poczekam aż przyjdą płytki z małym analogowym kalibratorem osi i przetestuję go w praktyce.
-
Dzięki za wyjaśnienia, to tłumaczy zachowanie PuTTY (2 bity STOP zamiast 1). Sprawdziłem jeszcze raz ostatnią wersję MegaJoy oraz wpływ #define DEBUG_UART.
Jeśli //#define DEBUG_UART to kursor w PuTTY na początku i brak informacji, w Termite 3.2 nic się nie dzieje.
Jeśli #define DEBUG_UART (odblokowany) to w PuTTY bez zmian natomiast w Termite 3.2 przesyłane są informacje.
W przedostatniej wersji MegaJoy jest ok. Jeśli jest aktualna wersja to spróbuję jeszcze raz ją pobrać.
Mam ciekawy problem związany generalnie z bluetooth. MX-15 ma swoje 2 porty OM12 i 13 i po COM12 pracuje z MegaJoy. Chciałem ten sam MX-15 zmusić do pracy z urządzeniem SimOUT, które komunikuje się z pc przez konwerter USB-RS232. Na wejściu SimOUT jest MAX232, który zamienia poziomy sygnałów ma TTL. SimOUT jest sterowany przez platformę HSC, gdzie można konfigurować RS232. Nie udało się nawiązać komunikacji, jest to pokazane na zdjęciu.
(http://i700.photobucket.com/albums/ww5/vito_zm/MX-15-HSC.jpg) (http://s700.photobucket.com/user/vito_zm/media/MX-15-HSC.jpg.html)
Teoretycznie powinno działać, ale może każdy MX-15 chce komunikować się z swoim kontrolerem, czyli w moim przypadku drugi MX-15. Może te COM12, 13 są zarezerwowane tylko dla MegaJoy a nowy MX-15 z nowymi COM dla SimOUT.
-
Sytuacja z define DEBUG_UART już się wyjaśniła jest o.k. W ostatniej wersji MegaJoy przy testach z MX-15 zmieniłem szybkość transmisji na 9600, dlatego w PuTTY nie działało, ponieważ był ustawiony na 115200. Teraz dopiero sobie o tym przypomniałem.
-
Nie znam schematu płytki SimOut, ale z tego co widać na fotkach, to ominąłbym całą część RS232, wyjął scalak MAX232 z podstawki i do odpowiednich pinów podłączył moduł bluetooth.
Naturalnie, jeśli PuTTY jest połączone z COM12, to SimOut nie da rady się podłączyć, port jest zajęty.
MX-15, jak i HC-05 może pracować jako slave (standardowe ustawienie, sam nie nawiązuje połączenia, tylko może je odebrać), albo master. Jeśli mamy dwa moduły, jeden slave, a drugi master to można je połączyć razem. Akurat w naszym przypadku nie jest to potrzebne, bo chcemy komunikować się z PC.
W tym przypadku adapter USB-Bluettoth wpięty do PC będzie pracował jako master, a MX-15 jako slave.
-
Można powiedzieć, że połączenie SimOUT z pc jest trywialne. MAX232 jest w moim modelu usunięty i jego miejsce zajmuje MX-15. TX modułu MX-15 jest połączone z pin 2 (RXD) układu Attimy 2313. Po stronie pc jest moduł bluetooth połączony do USB. Układy Attimy 2313 mają swoje adresy zapisane w pamięci (programujemy każdy uP z unikatowym adresem ). Wszystkie uP są na nasłuchu, komunikaty odbiera tylko ten którego adres jest zgodny z adresem w komunikacie. Komunikacja jest tylko w jednym kierunku od pc do Attimy 2313. Czyli bardzo prosty układ.
SimOUT musi pracować z platformą HSC. Jak widać na zdjęciu ustawiamy w HSC parametry RS232 i tutaj wybrałem port COM12 po którym jest transmisja MX-15. W HSC jest opcja testowania połączenia RS232. Widać na zdjęciu, że jest komunikat "Błąd połączenia Port CMO12 nie is...". Mnie się wydawało, że program w Attimy 2313 można oszukać zamieniając MAX232 na MX-15. Mogę próbować zapytać twórcę HSC oraz SimOUT czy taka komunikacja jest możliwa.
Próbuję to rozwiązać dlatego, że na forum jest dużo użytkowników SimOUT. Twórca tego kontrolera codeking tak to zaprojektował, że trzeba zastosować konwerter USB-RS232 na zewnątrz SimOUT. Gdyby udało się zrobić komunikację po bluetooth to można zamienić MAX232 na MX-15 robiąc małą modyfikację na pcb.
-
Wg informacji na stronie SimOUT, parametry portu szeregowego do komunikacji to:
Ustawienia połączenia: prędkość 57600, 8 bitów danych, 2 bity stopu, brak bitów parzystości, brak uwierzytelnienia
Czyli XM-15 trzeba przestawić komendą AT:
AT+UART=57600,1,0
-
Dzięki, będę próbował. Ja zmieniałem parametry RS232 po stronie HSC na takie jakie są w MegaJoy. Może faktycznie zmienić w MX-15 na takie jakie są w HSC. Dam znać czy się udało.
-
Raczej trzeba. UARTy w ATTINY2313 na płytce są programowo na stałe ustawione na tą prędkość i zmiana w programie po stronie PC nic nie da.
-
Kolejny gadżet do kolekcji zaczął działać: konwerter enkoder->2 przyciski lewo/prawo.
Oparty na małym i tanim ATTINY25, ma tylko jedno zadanie: poprawnie odczytywać kręcenie enkoderem i symulować przyciśnięcia dwóch przycisków: obrót w lewo lub obrót w prawo. Te wyjścia będzie można podłączyć do dowolnych wejść MCP23017 i używać enkoderów jako przycisków.
Działa na przerwaniach i sprytnym algorytmie (nie mojego autorstwa), który od razu zawiera w sobie dodatkową eliminację drgań styków.
Obsługuje dwa rodzaje enkoderów: pełnokrokowe i półkrokowe, rodzaj wybiera się zworką.
Nie wiem, czy to sprawdzi się w praktyce, ale wpadłem na pomysł jak wyeliminować gubienie kroków (generowanych przyciśnięć). W praktyce odkłócanie przycisków może czasem wymagać stabilnego stanu przez ok. 50ms. To sporo, a stanowczo za dużo, jeśli szybko pokręcimy enkoderem. Rozwiązałem to tak, że generator "kliknięcia" przyciskiem ma stały czas impulsu, procesor zlicza ilość kroków wygenerowanych enkoderem, a potem wyklika sobie w odpowienim tempie tą ilość tak, aby docelowy układ zarejestrował wszystkie.
Zalety: nie gubi kroków.
Wady: przy szybkim kręceniu enkoderem kliknięcia generowane są z opóźnieniem. Przy średnich i wolnych tempach nie ma problemu.
(http://i.imgur.com/3iKb77m.jpg)
Przy tak niskich cenach mikrokontrolerów można pokusić się o system rozproszony z niewielkimi modułami, które przeznaczone są do pojedynczych zadań i wykonują je dobrze, wyjścia są zunifikowane i kompatybilne z modułem centralnym. Będą też łatwiejsze do użycia dla tych bez dużego zaplecza elektronicznego.
To chyba nie ostatni modulik na Tiny25. Niestety procesor jest za mały, żeby go użyć w środowisku Arduino. Potrzebny będzie programator do AVR (np. USBasp).
-
Zmieniłem ustawienia MX-15 na takie jakie są zapisane w Attiny 2313 i nie ma komunikacji. Może faktycznie jest to temat dla twórcy HSC oraz SimOUT codeking.
SimOUT nie może pracować samodzielnie tylko z platformą HSC. Komunikacja pomiędzy PC (HSC) a płytą SimOUT jest przez konwerter USB-RS232, który w zasadzie jest przeźroczysty. AtTiny 2313 umieszczone w SimOUT mają taki sam program, różnią się tylko adresem ID. Komunikaty z pc wysyłane są do wszystkich uP, ale odbiera tylko ten z właściwym adresem. Prawdopodobnie odpowiada na wysłaną komendę.
Jeśli zmienimy sposób przesyłania komunikatów wprowadzając moduł bluetooth po stronie pc oraz MX-15 po stronie SimOUT to moduł MX-15 w sensie komunikacji nie jest przeźroczysty musi nawiązać połączenie z modułem w pc dopiero później możliwa będzie komunikacja HSC w pc oraz SimOUT. Może zastąpienie konwertera USB-RS232 oraz MAX232 na moduły bluetooth to za mało. Może trzeba coś zrobić w programie HSC lub Attiny 2313. Pozostaje zapytać codeking.
Co do ATTINY25 to pomysł jest ciekawy. Faktycznie to będzie działać. Dziwiło mnie w MMJoy2, że jest opcja wyboru 4 enkoderów połączonych do rejestrów. U mnie to nie działało tutaj będzie działać.
Jest jeszcze jedna sprawa związana z przyciskami (nie enkoderami). Czy MegaJoy ma załączać przy ON czy OFF czy jeszcze inaczej. W MMjoy2 wprowadzono kilka opcji. To tak przy okazji.
-
Okazało się, że mam jeszcze jednego ATTINY2313. Zaprogramowałem jednym z programów do LEDów. Udało mi się nawiązać połączenie między HSC, a tiny2313 przy pomocy adaptera USB-UART na FT232. Wygląda na to, że program HSC ma jakiś problem ze współpracą z modułami bluetooth. Nie może otworzyć połączenia, które wiem, że działa, bo do HC-05 ustawionego na 57600,8N2 mogę podłączyć się przy pomocy Termite.
W programie MegaJoy przyciski są wyzwalane stanem niskim, czyli zwarcie do masy. Jeśli chodzi o implementację działania na osi czasowej (astabilne, bistabilne itd.) to jeszcze o tym nie myślałem. Program zajmuje ok. 45% pamięci, jest jeszcze sporo miejsca na dodatkowe funkcje.
-
Dzięki za testy, to się zgadza z tym co zauważyłem u siebie. Napisałe na pw do codeking, może coś wymyśli.
Czy MegaJoy ma załączać przy ON czy OFF czy jeszcze inaczej.
Ta moja uwaga jest niepotrzebna, ponieważ MegaJoy trzyma stan ON tak długo jak długo naciskamy przycisk oraz OFF gdy go puścimy tak wynika z testu WKB Tester
Tak myślę, że jestem za bardzo "skażony" różnymi kontrolerami i dlatego ciągłe porównywanie, co nie ma sensu. Każdy kontroler powinien spełniać swoje założenia i w jakimś sensie wyróżniać się w niektórych parametrach. Nie ma sensu robić uniwersalnego kontrolera, ponieważ tracimy na jakości. Jako przykład mogę podać DMKeys8, który został zaprojektowany tak aby realizował sekwencje kombinacji klawiaturowych z możliwością różnych opcji typu ON, OFF. Kontroler typu joystick nie ma możliwości realizacji tych funkcji. Z drugiej strony DMKeys8 nie ma opcji kontroli analogów. Mógłbym jeszcze wymienić SimOUT oraz MMJoy2, które też mają swoje specjalizacje.
Z tego co napisał 3,14ter to MegaJoy będzie w pewnym sensie uniwersalny, ale ważną jego cechą będzie schemat oraz pcb kontrolera oraz tzw. córek, współpracujących z płytą matką. MMJoy2 też ma cechy uniwersalności, ale na moje wyczucie jest "przedobrzony" tzn. za dużo tej uniwersalności i pewne funkcje mogą pracować wadliwie (w moich testach enkodery). Schemat oraz pcb autor pozostawił do rozwiązania użytkownikom.
Trochę się rozpisuję, ale wynika to z tego, że mam u siebie różne kontrolery i ciągle je porównuję. Jeśli 3.14ter zrealizuje swój projekt to będziemy mieli bardzo dobry kontroler.
-
https://github.com/MMjoy/mmjoy_en/tree/master/PCB (https://github.com/MMjoy/mmjoy_en/tree/master/PCB) - tutaj masz PCBki jak i w folderze po rozpakowaniu archiwum - do przeglądania służy http://www.abacom-online.de/updates/Sprint-Layout60_Viewer.exe (http://www.abacom-online.de/updates/Sprint-Layout60_Viewer.exe)
-
Dzięki golas za linki. Przejrzałem i faktycznie temat MMJoy2 wydaje się dopracowany, jeśli powstało aż tyle pcb dla peryferiali oraz Arduino w tym dla wersji ProMicro. Na ile testowałeś MMJoy2 tzn. jakie jego opcje. Mam na uwadze nie tylko analogi ale przyciski, przełączniki, modyfikatory oraz enkodery. Próbowałem na początku tego wątku wciągnąć do dyskusji posiadaczy MMJoy2, ale się nie udało. Moje testy są nie pełne, ponieważ trafiłem na problemy np. z enkoderami i musiałbym wejść na forum MMJoy2 i tam pytać jak rozwiązać problemy. Jeśli ktoś ma pełniejszą praktyczną (testy na modelu) wiedzę na temat MMJoy2 to może się nią podzieli. Ma to o tyle sens, że może być przydatne przy projekcie MegaJoy.
-
Płytka modułu do enkoderów wyszła niewiele większa niż sam enkoder. Zaprojektowana jest pod enkodery ALPS serii STEC11. Myślę, że te tanie chińskie są kompatybilne (jadą, sprawdzę wkrótce).
(http://i.imgur.com/YpfFvG5.png) (http://i.imgur.com/jPxSG0P.png)
Nie miałem akurat modelu 3D enkodera ALSP i użyłem innego z takim samym rozstawm pinów oprócz tych montażowych.
Wyjście wbudowanego przycisku enkodera jest odkłócane małym filtrem RC i wyprowadzone na dwa dodatkowe piny (BTN).
H/F to zworka do wyboru rodzaju enkodera, pełnokrokowy/półkrokowy.
Sprawdziłem też działanie prototypu przedwzmacniacza/kalibratora do wejść analogwych z czujnikiem SS495 zamontowanym metodą "na długopis" i z wykorzytaniem części oryginalnego potencjometru:
(http://i.imgur.com/85PMH68.jpg)
Czujnik zamontowany jest na niewielkiej kratownicy lutowanej z 1mm srebrzanki. Całość trzyma się na oryginalnych pinach potencometru. Jest dość sztywna, ale i na tyle elastyczna, że po montażu udało mi się niemal idealnie wycentrować oś lekko naginając płytkę z czujnikiem. Przy takim ustawieniu i magnesach niewiadomego pochodzenia zakres wychylenia drążka generował +/- 1.4V wokół osi 2.5V. Układ wzmocnił to do pełnego zakresu wejścia ADC. Ewentualne nieliniowości górnej i dolnej połówki można sobie dokładnie wytrymować.
-
Jestem pewny jeśli chodzi o enkodery, że będzie ok. Bardzo pomysłowy prototyp widać, że masz praktykę, gratulacje.
-
Hmm odnośnie samego czujnika i mocowania to ja planuję zmajstrować coś takiego (planuję bo póki co mam mały przestój z pracami wszelakimi)
http://il2forum.pl/index.php/topic,17724.msg341240.html#msg341240 (http://il2forum.pl/index.php/topic,17724.msg341240.html#msg341240)
-
Kolejny gadżet do kolekcji zaczął działać: konwerter enkoder->2 przyciski lewo/prawo.
Oparty na małym i tanim ATTINY25, ma tylko jedno zadanie: poprawnie odczytywać kręcenie enkoderem i symulować przyciśnięcia dwóch przycisków: obrót w lewo lub obrót w prawo. Te wyjścia będzie można podłączyć do dowolnych wejść MCP23017 i używać enkoderów jako przycisków.
Dodam tylko, że będzie także działać w MMJoy2, gdzie są inne rejestry CD4021. Nie będzie działać z matrycą diodową, ale to nas nie interesuje.
Problem z enkoderami był od zawsze czyli od MJoy16, gdzie Damos zaprojektował dodatkową płytę aby zwiększyc liczbę enkoderów. Rozwiązanie 3.14ter jest bardzo dobrym pomysłem, ponieważ rozwiązuje wszystkie problemy na poziomie płytki córki, której wymiary są tak małe, że nie stanowią problemu w instalacji.
Z ciekawostek to koncepcja X-Plane oparta na Arduino pod tym linkiem http://b58.svglobe.com/ oraz ciekawy sposób komunikacji https://www.b4x.com/b4r.html
-
Po kilku dniach powróciłem do testów MegaJoystick oraz MMJoy2 testując analogi. Na zdjeciu jest pokazany mój zestaw do testów dla ProMicro (MMJoy2) oraz Leonardo (MegaJoystick). Potencjometry są wspólne (przekładam sznur). Testy wykonałem programem VKB_JoyTester. Dla MegaJoystick wykresy wypadły źle widać to na zdjęciu. Jestem pewny, że kilka dni wcześniej były inne wygładzone z przejściem nieliniowym przez środek charakterystyki. Sprawdziłem jak to wyglada w MMJoy2 i tam przebiegi są wygładzone.
Zastanawiam się co się mogło uszkodzić. W MMJoy2 są opcje ustawiania parametrów dla osi joysticka. U mnie jest step 63, bez filtru oraz precision 10 (wybór zakresy 8-14).
W MegaJoystick dla ustawienia potencjometrów na środku mam oś X 32749 step 1, oś Y 32695 step 2, oś Z 32447 step 64 oraz oś rZ 32766 step 1. Pozostałe dwie osie rX oraz rY nie reagują (A4, A5).
Zastanawiam się czy mogę jakoś znaleźć przyczynę moich problemów tzn. jakiś uproszczony program np. dla jednej osi czy coś podobnego.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_model.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_model.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/MegaJoystick-analog-wyk.jpg) (http://s700.photobucket.com/user/vito_zm/media/MegaJoystick-analog-wyk.jpg.html)
-
Wspominałem o tym w którymś poście. Włączenie obsługi UART i nadanie całego pakietu znaków zajmuje sporo czasu, a nic w procesorze nie dzieje się jednocześnie. Wystarczy zakomentować linię UART_DEBUG i przebiegi powiny być płynne.
Program MegaJoystick jest przykładem użycia funkcji z biblioteki. rX i rY nie są jeszcze zaimplementowane.
Jeśli ch-ka ma być liniowa, po ustawieniu Zrot dodajemy:
Joystick.setXAxisRotation(adcFilteredData[4]<<6);
Joystick.setYAxisRotation(adcFilteredData[5]<<6);
A jeśli mają być nieliniowe:
temp16 = applyResponse16(adcFilteredData[4]<<6);
Joystick.setXAxisRotation(temp16);
temp16 = applyResponse16(adcFilteredData[5]<<6);
Joystick.setYAxisRotation(temp16);
Dziś dostałem płytki przedwzmacnaiczy do halotronów. Po pierwszych testach wszystko działa ok, chociaż wprowadziłbym parę zmian.
(http://i.imgur.com/5eN0265.jpg)
-
Dzięki za wyjaśnienie. Po zablokowaniu sendUARTreport() przebiegi są płynne. Faktycznie gdy wprowadziłeś #include <AnalogScanner.h> to zablokowałeś raportowanie przez PuTTy. Moje eksperymenty trochę powodują zamieszanie i zapominam co zmieniałem w MegaJoystick.
-
Dotarły płytki do enkoderów. Przetestowałem jedną szt. Działa w porządku.
(http://i.imgur.com/9HYeRv7.jpg)
I jeszcze film jak to wygląda w praktyce:
https://www.youtube.com/watch?v=Wu3WuwwYTMM
-
Wygląda to bardzo dobrze. Jak będzie widziany enkoder w MegaJoystick, czy będzie jakaś deklaracja czy jako zwykłe przyciski.
-
Standard HID dla joysticków nie przewiduje jakichś specjalnych obiektów typu enkoder, a więc musimy użyć normalnych wejść przycisków.
Dojechała też paczka z tanimi enkoderami z Chin. Obracanie działa w porządku, ale ten wbudowany przycisk to totalna porażka. Działa raz na jakiś czas, chyba, że wciśnie się go bardzo mocno. Pewnie styki zaśniedziały.
Acha, moduł nie będzie działał w matrycach, gdyż wyjścia są logiczne 0-VCC. Można go przerobić, żeby działał i w matrycach przycisków, ale jedynie kosztem powiększenia PCB i dodatkowych elementów. W tej chwili nadaje się do użycia w układach z ekspanderami I2C i rejestrami szeregowymi.
Zamówiłem trochę więcej płytek, kilka szt. mogę polutować i zaprogramować, gdyby ktoś był chętny - dajcie znać na priv.
Projekt udostępnię jak tylko uda mi się napisać jakąś sensowną dokumentację.
-
Można go przerobić, żeby działał i w matrycach przycisków, ale jedynie kosztem powiększenia PCB i dodatkowych elementów. W tej chwili nadaje się do użycia w układach z ekspanderami I2C i rejestrami szeregowymi.
Nie ma sensu przerabiania, powinien działać z I2C oraz rejestrami.
-
Zastanawiam się, czy nie warto byłoby użyć takich magnesów :)
http://www.magnesy.eu/mp-10-x-6-x-4--n38---magnes-neodymowy-t-2301.html
Jeśli dobrze zrozumiałem opis, to kierunek magnesowania jest niewłaściwy, powinien być taki:
http://www.magnesy.eu/mp-10a-x-5-x-5--n35h---magnes-neodymowy-t-2715.html
Sprawdziłem podobne (http://www.magnetmax.de/Neodym-Ringmagnete/Ringmagnet-O-10-0-x-5-0-x-5-0-mm-Neodym-N45-vernickelt-diametral::90.html), tylko o sile ok. 700g. SS495 głupieje kompletnie, sensor chyba się przesterowywuje.
Natomiast do KMZ60 będą w porządku, zgodnie z aplikacją zresztą:
(http://cdn.electronics-eetimes.com/electronics-eetimes.com/sites/default/files/styles/inner_article/public/import/2011-0484_nxp_bldc_motor_key_visual_hr.jpg)
-
Panowie, mam takie pytanko, steruję przekaźnikiem poprzez Arduino. Przekaźnik jest sterowany stanem niski, nie posiada zworki, tak by go przestawić na sterowanie stanem wysoki. Czy mogę to zrobić w Arduino jakoś softowo. Taki mam to zapisane, ale nie wiem co można dopisać by zmienić działanie.
/* use '#define DCSBIOS_DEFAULT_SERIAL' instead if your Arduino board
* does not feature an ATMega328 or ATMega2650 controller.
*/
#define DCSBIOS_IRQ_SERIAL
#include "DcsBios.h"
DcsBios::LED handleGearWarning(0x1026, 0x4000, 2);
DcsBios::LED gearLSafe(0x1026, 0x1000, 3);
DcsBios::LED gearNSafe(0x1026, 0x0800, 4);
DcsBios::LED gearRSafe(0x1026, 0x2000, 5);
DcsBios::LED lEngFire(0x10da, 0x0008, 6);
DcsBios::LED apuFire(0x10da, 0x0010, 7);
DcsBios::LED rEngFire(0x10da, 0x0020, 8 );
void setup() {
DcsBios::setup();
}
void loop() {
DcsBios::loop();
}
-
Nie prościej zastosować tranzystor?
-
(http://processors.wiki.ti.com/images/f/f2/Launchpad_images_LED_npn_voltages.png)
Rb = 10k
Ra = 220R - 1k (jasność diody)
Tranzystor = BC547C lub jakiś inny NPN
Sygnał z kontrolera wchodzi na bazę tranzystora przez Rb.
VCC może być wyższe niż 5V.
Jeśli chcesz wysterować więcej LEDów z jednego wyjścia, to po prostu połącz pary LED+Ra równolegle. Ważne, żeby każdy LED miał swój rezystor Ra.
Dioda zaświeci się jeśli na wejściu pojawi się stan wysoki.
Podłączanie przekaźnika bezpośrednio do portów AVRa, jeśli tak masz to teraz podłączone, jest raczej ryzykowne i nie zalecane. Zazwyczaj robi się to z użyciem tranzystora, jak powyżej.
Programowa zmiana działania ze stanu aktywnego wysokiego na niski wymaga modyfikacji biblioteki DcsBios. Dokładniej plik LEDs.h, linie 20 i 22. Trzeba zamienić 0 na 1 i odwrotnie.
https://github.com/dcs-bios/dcs-bios-arduino-library/blob/master/Leds.h
Oczywiście spowoduje to, że wszystkie wyjścia LEDów będą działać odwrotnie.
Ja bym po prostu wziął pierwszy lepszy tranzystor NPN z szuflady i podłaczył jak na powyższym schemacie.
-
Dzięki wielkie, wszystko jasne. Przekaźniki mam gotowe na płytkach, takie jak te - http://x3.cdn03.imgwykop.pl/c3201142/comment_so73n11cVYsOijG1zYuMSgCu9Kurrevz.jpg .
Ich zastosownie wymuszają u mnie diody w 3 kontrolkach, to paski taśmy diodowej 12V https://www.youtube.com/watch?v=RHsZz9zbtkA . Reszt kontrolek będzie miała
tradycyjne diody. Zakupię przekaźniczki z możlwością zmiany stanu sterowania.
-
Czyli są to gotowe moduły z przekaźnikami, a nie jeden "goły". Nawet z optyczną izolacją wejść. Bardzo dobrze!
Poczekaj z tym kupowaniem nowych przekaźników :).
Niestety nie mam DCSa, żeby sprawdzić działanie w praktyce, ale spróbuj wykonać poniższe operacje (dodałem obsługę stanów aktywnych dla LEDów w bibliotece):
1. Poszukaj katalogu, gdzie zainstalowała się biblioteka. Jeśli robiłeś to automatycznie z poziomu IDE Arduino to będzie chyba gdzieś w dokumentach/danych aplikacji.
2. Będzie tam plik Leds.h. Robimy na wszelki wypadek kopię zapasową i podmieniamy zawartość oryginału na poniższą:
#ifndef __DCSBIOS_LEDS_H
#define __DCSBIOS_LEDS_H
#include "Arduino.h"
#include "ExportStreamListener.h"
#define ACTIVE_LOW 0
#define ACTIVE_HIGH 1
namespace DcsBios {
class LED : public Int16Buffer {
private:
unsigned char pin;
unsigned char active;
unsigned int mask;
public:
LED(unsigned int address, unsigned int mask, char pin, char active) : Int16Buffer(address), mask(mask), pin(pin), active(ACTIVE_HIGH) {
pinMode(pin, OUTPUT);
}
virtual void loop() {
if (hasUpdatedData()) {
if (getData() & mask) {
digitalWrite(pin, active ? 1:0);
} else {
digitalWrite(pin, active ? 0:1);
}
}
}
};
}
#endif
3. Nowa wersja dodaje opcję ustawienia stanu aktywny niski lub wysoki dla poszczególnych LEDów. Dlatego w programie, przy definicji LED trzeba będzie dodać po jednym argumencie funkcji, np.:
/* use '#define DCSBIOS_DEFAULT_SERIAL' instead if your Arduino board
* does not feature an ATMega328 or ATMega2650 controller.
*/
#define DCSBIOS_IRQ_SERIAL
#include "DcsBios.h"
DcsBios::LED handleGearWarning(0x1026, 0x4000, 2, ACTIVE_LOW);
DcsBios::LED gearLSafe(0x1026, 0x1000, 3, ACTIVE_HIGH);
DcsBios::LED gearNSafe(0x1026, 0x0800, 4, ACTIVE_LOW);
DcsBios::LED gearRSafe(0x1026, 0x2000, 5, ACTIVE_LOW);
DcsBios::LED lEngFire(0x10da, 0x0008, 6, ACTIVE_HIGH);
DcsBios::LED apuFire(0x10da, 0x0010, 7, ACTIVE_HIGH);
DcsBios::LED rEngFire(0x10da, 0x0020, 8, ACTIVE_LOW );
void setup() {
DcsBios::setup();
}
void loop() {
DcsBios::loop();
}
4. Pozmieniaj sobie LOW na HIGH (ostatni parametr) wg uznania, wgraj nowy soft do procka i daj znać czy działa.
Program skompilował się poprawnie, powinno być ok.
-
Kurna no niestety już zamówiłem tego typu przekaźniki http://1.bp.blogspot.com/-w3lyS18L7EI/VgedGgxaSRI/AAAAAAAAP6Y/6APtm_jTS6o/s1600/IMG_2889.jpg . No ale sprawdzę to co napisałeś. Na szczęście nie są drogie te przekaźniczki.
-
Jestem pod wrażeniem wiedzy 3.14ter. Może uda się znaleźć sposób na wyświetlanie alarmów w układzie Arduino - symulator BMS4. Do tego tematu muszę się przygotować i dopiero wtedy zapytać.
Teraz chciałbym wrócić do tematu enkodery z uwzględnieniem także MegaJoystick. Zrezygnowałem z testów enkodera zaprojektowanego przez 3.14ter (pcb, uP oraz reszta) z prostej przyczyny, ten projekt już jest sprawdzony. Teraz można go po prostu zamówić dla konkretnego panelu z enkoderami w kokpicie. Na podstawie moich doświadczeń z enkoderami oraz różnymi kontrolerami mogę stwierdzić, że jeśli projektujemy sterowanie na bazie MMJoy2 lub MegaJoystick to musimy zastosować projekt 3.14ter. Ma on jedną ważną zaletę nie przekłamuje. Jest to ważne np. przy precyzyjnym strojeniu częstotliwości.
W DMKeys8 można zastosować zwykły enkoder, który bardzo rzadko przekłamuje i można trochę pozmieniać parametry filtrowania. W SimIN można także zastosować enkoder, ale to wymaga układu wejściowego SimOUT oraz konwertera USB-RS232. Nie pamiętam jak było z przekłamaniami. To tyle na temat enkoderów oraz moich doświadczeń w tym temacie.
-
Zgodnie z zapowiedzią chciałbym przedstawić mój pomysł projektu realizującego wyświetlanie alarmów w BMS 4.33 za pomocą Arduino Leonardo. Mamy już zrealizowane różne kontrolery odczytujące układy wejściowe typu przycisk, przełącznik, enkoder. Posiadam dwa typy kontrolerów pozwalające odczytać alarmy w BMS. Jeden to układ z OpenCockpis sterowany z SIOC oraz FAST. Drugi oparty na platformie HSC codeking oraz kontrolerze SimOUT.
To drugie rozwiązanie wymaga konwertera USB - RS232 oraz układu MAX 232 do zamiany sygnałów liniowych na TTL. Zamiana uP ATTINY 2313 na Leonardo uprościłaby ten układ.
Na załączonym szkicu przedstawiłem projekt oparty na Leonardo i podobny do SimOUT (fragmentu realizującego LED). Sterownik realizuje sterowanie 48 LED wyświetlanych dynamicznie a nie statycznie. Potrzeba tylko jednego układu ULN 2803 oraz 6 złączy 10 pin i 6 rezystorów. LED pracują w układzie z wspólną anodą.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Leonardo-LED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Leonardo-LED.jpg.html)
W bibliotece FlightData.h są między innymi 3 rejestry 32 bitowe o nazwie LightBits, LightBits2 oraz LightBits3. Na 32 pozycjach tych rejestrów są wskaźniki odpowiednich alarmów w BMS. Najmłodszy adres to 0x1 co odpowiada wskaźnikowi (1) na zerowej pozycji rejestru, najstarszy to 0x80000000 co odpowiada wskaźnikowi alarmu (1) na pozycji 31 rejestru.
Codeking w HSC zaprojektował tzw. moduły wejścia w tym moduł FalconData, który jest zbiorem zmiennych w BMS w tym również wspomnianych 3 rejestrów. Są też moduły wyjścia w tym SimOut.
W skrypcie do HSC dla BMS jest tylko kilka deklaracji oraz funkcji np.
variable $lightBits { module = "FalconData"; id = "lightBits"; type = int; direct = in; }
variable_changed $lightBits
$led_001_008 = GetBitState( $lightBits , 1 )
Jak widać jest to bardzo prosto zrobione. Jest skojarzenie wyjścia SimOut z wybranym alarmem i jeśli jest zmiana stanu alarmu to zostanie to przekazane do określonego LED.
W uproszczeniu tak to można przedstawić.
Pytanie do 3.14ter czy można to zrealizować w prosty sposób w Leonardo. Dodam tylko, że codeking w module ma 3 pliki F4SharedMem.dll, FalconData.dll oraz FalconData.
W Internecie znalazłem bibliotekę dla BMS
http://www.foinikas.org/ftp/public/Falcon%20BMS/Docs/Other%20Documentation/Flight%20Data.h
Twórca FlightData.h jest lightning, adres jego strony https://svn2.assembla.com/svn/lightningstools/
Realizacja takiego projektu byłaby bardzo przydatna dla budowniczych paneli dla BMS.
-
Czas na mały update z postępu prac.
Dużo się zastanawiałem nad ogólną koncepcją projektu joysticka, bazując na sugestiach kolegów i przemyśleniach, doszedłem do wniosku, że system modułowy będzie najlepszy. Może nawet nie tyle modułowy, co rozbity na kilka mniejszych autonomicznych joysticków z możliwościa ich rozszerzenia.
Celem jest wyeliminowanie konieczności prowadzenia setek kabli przez ruchome przeguby, idealnie byby to tylko jeden kabel usb, albo tylko zasilanie (o tym za chwilę). Do tego posiadanie kilku osobnych joysticków/kontrolerów w systemie pozwoli na traktowanie częsci symulatora jako osobne urządzenia.
I tu dochodzimy do decyzji, którą musiałem podjąć - odejście od platformy Arduino, która niestety w porównaniu do obecnych rozwiązań na mikrokontrolerach wprowadza dużo ograniczeń.
Nie znaczy to, że cała dotychczasowa praca poszła na marne. Biblioteka i przykładowy program działają poprawnie. Na ich bazie, plus całej gamie istniejących bibliotek do Arduino (przetworniki AC np.) można tworzyć sobie przeróżne werjse joysticków. W tej chwili program zajmuje około 40% pamięci Flash, a więc jest jeszcze sporo miejsca na dalsze rozszerzenia.
Atutem użycia arduino, oprócz dostępnych bibliotek, jest śmieszna cena gotowych modułów (co prawda ceny oryginalnych płytek są już mniej zabawne). Jeśli miałbym zaprojektować nową płytkę zgodną z Arduino, to niestety, ale ten atut odpada. Do tego dostajemy bagaż ograniczeń 8 bitowej platformy AVR.
Gwoździem do trumny były problemy z użyciem kilku płytek Leonardo/Pro Micro, ale tak, żeby pojawiały się w systemie pod innymi nazwami. Próbowałem coś w tym temacie zadziałać, nawet grzebiąc edytorem hex w kodzie bootloadera, bezskutecznie. Wygląda na to, że nazwa "Arduino Leonardo" jest na stałe przypisana w sterowniku windowsa. Można ją zmienić, ale wtedy zmieni się ona dla wszystkich podłączonych płytek.
Tak więc sięgnąłem po nowoczesny 32 bitowy ARM i powstał projekt tego typu:
(http://i.imgur.com/iq2RzNy.gif)
(http://i.imgur.com/xsyj5u2.gif)
Co jest na podkładzie:
- 4 wejścia analogwe 15bit z pełnymi wzmacniaczami dla osi głównych,
- 2 wejścia analogowe 11bit z uproszczonymi wzmacniaczami,
- 16 wejść dla przycisków,
- 3 wejścia dla enkoderów (sprzętowe dekodery),
- 2 wejścia dla HAT,
- port I2C do rozszerzeń (dodatkowe moduły z ADC i przyciskami)
Płytka ma rozmiar 50x85.5mm i jak widać jest dość gęsto upakowana.
Z komputerem łączy się bezprzewodowo przez Bluetooth 4.0. Jest to ciągle urządzenie HID nie wymagające specjalnych sterowników. Płytkę można umieścić gdzieś w pobliżu przycisków, czujników i z zewnątrz podłączyc tylko zasilanie 9-12VDC.
W ramach testów udało mi się podlączyć i sparować 3 różne moduły pod różnymi nazwami.
(http://i.imgur.com/WPZRosm.png)
Po urlopie zamówię płytki i zabiorę się za zbudowanie prototypu. Sercem układu jest gotowy atestowany moduł ARM Cortex M0 + radio Bluetooth 4.1 f-my Cypress, tej od PSoC5LP. Myślę, że nie powinno być problemów ze stabilnością połączenia. Co prawda jest to BLE, czylu Bluetooth Low Energy z opcjami hibernacji, oszczędzania energii, ale zamierzam to wszystko powyłączać. W naszym przypadku ważnejsza jest stabilna transmisja niż pobór energii, który i tak będzie dość niski.
vito-zm
W przypadku HSC w sumie nic nie stoi na przeszkodzie, żeby jeden większy procesor reagował na wszystkie adresy i odpowiednio dekodował dane wypuszczając je na multipleksowane wyjścia dla LEDów. Kwestia wczytania się w protokół transmisji i napisania odpowiedniego dekodera. Myślę, że to zadanie na trochę później.
W Twoim układzie trzeba jeszcze zastosować tranzystory od strony anod. Cały prąd pobierany przez diody będzie płynął z górnych 6 pinów. W tym wypadku ULN2803 zabezpiecza tylko dolne 8 pinów. Rezystory ograniczające prąd powinny być raczej od strony katod i po jednym na każdą diodę.
(http://embedded-lab.com/blog/wp-content/uploads/2011/03/Lab11_Circuit_SevenSegmentMultiplexing.jpg)
-
Może nieprecyzyjnie wyjaśniłem koncepcję działającego SimOut. Skupię się tylko na realizacji 7segLED oraz LED. Codeking zrobił swój projekt lepiej od przykładów książkowych. Zastosował wspólną anodę co nie ma większego znaczenia. Na zdjęciu widać, że można podpiąć 5 wyświetlaczy 7segLED lub 40 LED (na schemacie jest tylko 8). Komunikacja z n procesorami ATTINY 2313 jest po jednym drucie. Każdy procesor ma ten sam wkład (program), ale z różnym ID (adresem). Komunikaty są standardowe dla RS 232. Pomyślałem o Arduino dlatego, że ProMicro lub Leonardo ma mechanizm komunikacji jako HID i można uprościć interfejs komunikacyjny pc - kontroler realizujący np. sterowanie LED. Można oczywiście zrobić statyczne sterowanie LED i uprościć programowanie Arduino. Dla nas od symulatora BMS główny problem to przechwytywanie danych z symulatora. DCS ma ten problem dla Arduino rozwiązany my od BMS niestety nie.
Twój projekt jest uniwersalny i rozwojowy i nie zależy od typu symulatora ponieważ jest widziany jako joystick. My musimy niestety także wyświetlać alarmy, dlatego zapytałem o możliwość rozwiązania tego problemu.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_IMG_20160917_0001.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_IMG_20160917_0001.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/m_IMG_20160917_0002.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_IMG_20160917_0002.jpg.html)
-
Mnie chodziło bardziej o sam układ elektroniczny. ULN2803 w przypadku statycznego sterowania LEDów ma jak najbardziej sens. Diody można zasilić nawet z większego napięcia zasilania i z większym prądem, bez obawy przekroczenia dopuszczalnych 20mA dla AVR.
W przypadku sterowania multipleksowanego, jak na Twoim schemacie, niestety nie wystarczy, gdyż paczka 8 LEDów zasilania jest praktycznie z jednego z 6 pinów sterujących. Zakładając, że mamy włączone wszystkie 8 diod naraz i rezystor 100R, jak na schemacie, całkowity prąd jaki wypłynie z jednego z pinów będzie, jak na fotce poniżej:
(http://i.imgur.com/2madQBK.jpg)
(http://i.imgur.com/4GAXXSI.jpg)
Pewnie nie upali to procesora, gdyż obciążenie będzie impulsowe, na czas trawnia odświeżenia danego bloku diod. Nie mniej jednak to 50% przekroczenie normy i jednak bym go unikał.
Następna sprawa to sposób włączenia LEDów, z jednym rezystorem na 8 diod od strony anody. Owszem, to działa, z jasnymi diodami i wyświetlaczami pewnie nawet nie widać różnicy, ale takie włączenie powoduje to, że im więcej diod świeci się w danym bloku, tym słabiej one świecą. Sprawdziłem to naocznie na modelu ze zdjęcia. Zapalanie kolejnych segmentów powoduje, że ogolna jasność wyświetlacza spada.
Osobne rezystory od strony katody, jak na schemacie, który wkleiłem, powodują to, że przez każdy LED płynie taki sam prąd i jasność jest stała.
W praktyce - jeśli ta zmiana nie przeszkadza, nie ma sesnu zmieniać układu. Od strony anod zastosowałbym jednak tranzystory PNP.
Jeśli chodzi o sam program i zastąpienie TINY2313 od Ledów przez Arduino. Jest to jak najbardziej wykonalne, aczkolwiek jest kilka kwestii do rozstrzygnięcia.
W pliku SimOUT.pdf sam protokół transmisji jest ładnie opisany. HSC wysyła strumień danych na ustawiony port COM. Arduino zgłasza się jako COM, więc tu nie ma problemu. Wystarczy napisać program, który będzie reagował na adresy 21-80 i dekodował odpowiednio komendy włączania/wyłączania Ledów.
Teraz pytanie czy chcemy Arduino wykorzystać jako "centralkę" i posłać strumień danych COM gdzieś dalej do innych modułów? Zakładająć, że potrzebujemy więcej niż 40 Ledów.
Dwa Arduino zgłoszą się jako dwa różne porty COM, więc nie da się do nich nadawać jednocześnie.
Leonardo posiada dwa porty COM, jeden USB-HID i drugi klasyczny, sprzętowy. Skrypt mógłby posyłać strumień danych z portu COM\USB na drugi port COM (Serial1). Te dane można posłać dalej do kolejnych modułów. System wyglądałby mniej więcej tak:
(http://i.imgur.com/3kBML2G.png)
Leonardo działa jako centralka i adapter USB->COM. Odbierałby dane z pierwszego adresu, 21 i je dekodował dla własnego zestawu LEDów. Cały strumień przekierowany jest też na Serial1, a ten podłączony do kolejnych modułów, które nie muszą już być z USB. Wystarczy zwykłe Nano na M328.
To trochę tak, jakby zastąpić każdego z ATTINY23 jedną płytką Arduino.
-
Muszę Tobie przyznać rację. Nie liczyłem oraz nie mierzyłem prądu. Codeking prawdopodobnie zrobił założenie, że alarm wystąpi może w max. 50% paczki 8 LED czyli w 4 LED oraz że wartość średnia prądu nie przekroczy dopuszczalnej wartości. Powiem więcej trzeba zrobić tak jak sugerujesz.
SimOut jest dosyć popularnym kontrolerem na naszym i nie tylko forum i faktycznie nikt na to nie zwrócił uwagi, chociaż były sygnały, że LED słabo świeci. Mnie się wydaje, że jest w tym pewna logika tzn. punkt pracy diod przesuwał się i świecenie malało kosztem mniejszego prądu oraz spadku napięcia na diodzie. Dzięki za wyjaśnienia. Twoja koncepcja bardzo mnie się podoba może powstanie z tego projekt dla wyświetlania alarmów.
Na obronę SimOut powiem, że za pomocą prostych rozwiązań można wyświetlać LED, 7segLED, LCD tekstowe a nawet serwo czy silniki krokowe. Można także podłączyć do niego SimIN i kontrolować przyciski, przełączniki oraz enkodery. Oczywiście HSC jest sam w sobie dziełem sztuki, ale świat poszedł do przodu i aż się prosi zrobienie projektu podobnego do Twojej koncepcji.
-
Mam jeszcze pytanie do użytkowników HSC+simOUT.
Standardowe podłączenie segmentów wyświetlacza, zgodne zresztą ze schematami vito_zm jest takie:
bit0 = A
bit1 = B
bit2 = C
bit3 = D
bit4 = E
bit5 = F
bit6 = G
bit7 = punkt.
Tymczasem, używając testowania modułów w HSC 1.1.1.1, nadaje on dane w zupełnie innym formacie. Wygląda na to, że przekodowanie cyfry na sygnały dla 7 segmentów nie działa poprawnie.
Testowanie LEDów działa ok, poza drobnym szczegółem: jeśli dodam moduł 40xLED, to wygenerowane indeksy są odwrócone. Testowanie LED#0 wysyła sygnały załączania LEDa#40.
Skoro program jest używany z sukcesem, podejrzewam, że te błędy dotyczą jedynie modułu testowania komend? Jestem pewien, że to nie wina mojego programu, bo na bieżąco mam podgląd bajtów wysyłanych z HSC1.1.1.1.
Myślałem, że odłożę ten temat na później, ale jakoś tak nie wyszło. Zmykam na urlop i zostawiam Wam coś do potestowania:
https://github.com/hexeguitar/simOUT_LED_arduino
Działa na maluchu Pro-Micro i wymaga jedynie biblioteki TimerOne.
(https://github.com/hexeguitar/simOUT_LED_arduino/raw/master/pics/ProMicro_simOUTleds.png)
Nie zdążę już tego przetestować, ale w celu roszerzenia układu o dodatkowe adresy można:
1. Użyć jakiegoś innego arduino, np. Nano. Tylko Master potrzebuje USB.
2. Zakomentować linię #define MASTER_MODULE co przestawi moduł w tryb SLAVE
3. Wpisać nowy adres urządzenia w zmienną const uint8_t devAddress, np 22. Dla Mastera przyjąłem pierwszy moduł z LEDami, czyli 21.
4. Wgrać program w Nano
5. Podłączyć tak
ProMicro -> Nano
VCC---------VCC
GND---------GND
TX----------RX
Nano powinien odbierać dane z HSC pod adresem 22. ProMicro na adresie 21 działa jako pierwszy blok LEDów i adapter USB-Serial dla całej reszty.
-
Bardzo mnie zaskoczyłeś tak szybką reakcją bardzo dziękuję. Życzę udanych wakacji chociaż pogoda trochę się pogorszyła. Sprawdzę jak działa. To co napisałeś o indeksowaniu LED to sprawdzę, może codeking zrobił odwrotnie co nie jest problemem.
Może jeszcze zdążysz odpowiedzieć. Mam dostępny Leonardo oraz zaprogramowany ProMicro programem MMJoy2. Czy mogę zastosować Leonardo zmieniając piny w
int c_anodeDrivers[numOfDigits] = {2,3,4,5,6};
int ledDrivers[8] = {8,7,14,15,18,9,10,16};
czy muszę wgrać do ProMicro program pod IDE kasując MMJoy2.
Widzę, że mogę na początek testować z HSC zarówno LED jak i 7segLED w układzie master a później tak jak napisałeś master- slave.
Jeśli to wypali to będzie sukces, dzięki.
Ja mam wersję HSC 1.1.1.2 ale to nie powinno mieć znaczenie.
-
Piny można sobie dowolnie ustawiać dokładnie tymi tablicami, nie widzę powodu, żeby nie działało na Leonardo. Trzeba tylko uważać, żeby nie zająć pinu od Serial1/UART3.
-
Bardzo dziękuję. Zrobiłeś mam wielką niespodziankę. Będę testował ten projekt. Cieszę się, że zawitałeś na nasze forum, bardzo mało jest programistów, którzy są także dobrzy w tzw. hardware oraz chcą pomóc amatorom takim jak ja.
-
Wiem, że kolega Piotr jest na urlopie ale mam nadzieję, że po powrocie przeczyta te wpisy. Dzięki jego uprzejmości miałem możliwość testowania płytki enkodera. Polutowałem do płytki tani enkoder (około 4 zł za sztukę). Sprawdzałem w dwóch konfiguracjach jedna z LED- ami druga w docelowej konfiguracji z MegaJoystic oraz rejestrami MPC 23017.
Muszę stwierdzić, że enkoder w tym projekcie działa rewelacyjnie. Nie ma przekłamań oraz gubienia impulsów. Jeśli bardzo szybko obracamy gałką enkodera to impulsy są przesyłane nadal pomimo zakończenia obracania gałki. W praktyce w symulatorach nie ma takiej sytuacji mam na myśli bardzo szybki obrót gałki, ale jeśli nawet to zawsze obserwujemy na ekranie efekty takiego działania i wiemy, kiedy jest koniec działania obrotu enkodera. Mam nadzieję, że wyjaśniłem o co mnie chodziło.
Połączenie do rejestru jest trywialne. Łączymy 2 styki łączówki oznaczone INC oraz DEC do dowolnych wejść rejestrów MCP 23017, pozostałe 2 styki oznaczone VDD do 5V oraz GND do 0V (masy). Po drugiej stronie pcb mamy 5 styków, gdzie zwieramy F lub H z środkowym stykiem. Mój enkoder jest typu H. Łatwo stwierdzić jaki posiadamy typ enkodera. Jeśli dla enkodera typu H zewrę środek z F to enkoder generuje impuls co drugi przeskok. Jest też wyprowadzony styk enkodera na styki BTN (wciśnięcie gałki). Jeśli nie wciskamy gałki to mamy na stykach ozn. BTN 1 kom (filtr), po wciśnięciu zwarcie. Zdjęcie płytki jest pod # 212 w tym wątku. Dołączyłem także swój układ do testów za pomocą LED.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_enkoder_1.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_enkoder_1.jpg.html)
-
Rozpocząłem testy programu SimOut-Arduino, ale na Leonardo. Przyczyna jest trywialna. Zamówiłem ProMicro a otrzymałem Micro, dlatego zgłosiłem reklamację i czekam na właściwe Arduino. Przygotowałem model na płycie uniwersalnej pod ProMicro, ale z braku właściwego Arduino połączyłem ten model z Leonardo tak jak na załączonym zdjęciu. Oznaczenia D7, D8, D9, D10, D14, D15, D16 oraz D18 z ProMicro przeniosłem na Leonardo według schematu, jest to pokazane na moim szkicu. Nic nie zmieniałem w programie SimOUT_LEDs zakładając, że jest kompatybilność oznaczeń D7 -D18.
Zanim przedstawię wyniki testów chciałbym wyjaśnić Piotrowi pewne opcje w SimOUT, ponieważ może to mieć odzwierciedlenie w komunikatach. Codeking zauważył, że jest wolny pin 2 w ATTiNy 2313, który można wykorzystać do zwiększenia liczby LED o dodatkowe 8 (1-48) oraz dodatkowy 6 7segLED. W związku z czym są wsady z opcją v2 stare rozwiązanie oraz v3 poszerzone. Jeśli chodzi o numerację grup ośmiu LED to nie jest to aż tak istotne, ponieważ dla nowej wersji SimOUT-Arduino musimy zrobić płytkę z złączami 10 pin dla 40 LED podobnie dla 7segLED z złączami 16 pin. Zanim przedstawię wyniki testów chcę zaznaczyć, że są inne od oczekiwanych, ale to może wynikać z zastosowania Leonardo (problem może wynikać z konfliktem fizycznego połączenia na płycie oraz programu SimOUT_LEDs ). Nic nie zmieniam czekam na Piotra. Gdy otrzymam ProMicro zrobię testy i może dla tego Arduino będzie dobrze działać.
HSC widzi SimOUT-Leonardo bez problemu. Wystarczy wgrać do HSC COM z Leonardo. Konfigurowałem HSC pod adresem 21 dla LED następnie dla testów 7segLED także pod tym samym adresem.
Test 7segLED
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Leonardo-7segLED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Leonardo-7segLED.jpg.html)
Test LED.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Leonardo-LED_1.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Leonardo-LED_1.jpg.html)
Testy wykonałem w dwóch wariantach. W pierwszym wykorzystałem diodę LED, którą podłączałem pod odpowiednie piny i testowałem programem HSC .
W drugiej opcji korzystałem z mojego testera do testowania SimOUT. Jest on pokazany na zdjęciach. Przy pomocy testera mogę sprawdzać 7segLED oraz LED.
Na załączonym zdjęciu są pokazane wyniki testu. Z wyników widać, że niektóre LED-y nie są wyświetlane a niektóre są dublowane oraz jest inna numeracja. Podobnie jest z 7segLED. Myślę, że po wykonaniu testów z ProMicro sytuacja się wyjaśni.
Wyniki testów.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_test%20SimOut%20Arduino.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_test%20SimOut%20Arduino.jpg.html)
-
Otrzymałem w końcu właściwe Arduino ProMicro z strony http://allegro.pl/show_item.php?item=6063645427 Moduł jest widziany w menadżer jako Arduino Leonardo COM6. Założyłem, że powinno być ProMicro i rozpcząłem eksperymenty w wyniku czego otrzymałem komunikat, że nie ma takiego sterownika. Moduł po eksperymencie nie jest już widziany w menadżer. Jest widziany po zwarciu RST z GND jako Arduino Leonardo bootloader COM5. Z kolejnym modułem także eksperymentowałem bez powodzenia. W końcu wgrałem do niego program MMJoy2. Moduł z tym programem jest widziany jako joystick i działa właściwie. Pozostał trzeci moduł ProMicro z którym nic nie robiłem. Jest on widziany w menadżer jako Arduino Leonardo COM6.
Nie wiem co dalej z tym robić. Wszedłem na Allegro do innego sprzedawcy http://allegro.pl/arduino-pro-micro-atmega-32u4-leonardo-micro-hit-i5014242447.html
Tutaj jest informacja Moduł Pro Micro, podobnie jak Arduino PRO Micro oparte jest na module Leonardo
i odnośnik do linku https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/hardware-overview-pro-micro
Pod tym linkiem jest strona Installing Windows, gdzie można znaleźć driver dla ProMicro. Próbowałem zainstalować, ale ja u siebie w menadżer nie mam ścieżki Other devices oraz USB IO Board, mam pod Portami tak jak wspomniałem Arduino Leonardo COM6.
Mam u siebie wersję IDE 1.6.7 oraz dostępne płytki tak jak na obrazku. Na pozostałych obrazkach jest menedżer dla modułu Leonardo ( ProMicro) oraz dla próby szukania w sieci sterownika.
Nie znam się na sterownikach, ale z informacji w menadżer wynika, że jakiś program jest wgrywany do uP. Czy z moich obrazków można wnioskować, że klon kupiony na Allegro jest widziany jako Leonardo i nic nie muszę z tym robić. Jeśli ktoś już się z tym problemem spotkał to proszę o pomoc.
(http://i700.photobucket.com/albums/ww5/vito_zm/ster%203.jpg) (http://s700.photobucket.com/user/vito_zm/media/ster%203.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/micro.jpg) (http://s700.photobucket.com/user/vito_zm/media/micro.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/IDE%20moduy.jpg) (http://s700.photobucket.com/user/vito_zm/media/IDE%20moduy.jpg.html)
-
Vito czy testowałeś płytkę z enkoderami z OpenCockpits ? Jestem ciekaw czy to dobrze współpracuje.
-
Płytka do enkodera jest zaprojektowana na ATTINY25 i współpracuje z rejestrami np. z MC 23017, gdzie można zrobić konfigurację na wejściu pullup. Wyjścia z płytki oznaczone INC oraz DEC dają impulsy, ale nie jest to czysty styk do masy tak jak w enkoderze, dlatego nie można stosować tych płytek w matrycach diodowych. U mnie w Master (OpenCockpits) matryca diodowa jest w grupach po 9 i sterowana z 74HC541. Płytka została zaprojektowana pod rejestry i pracuje bardzo dobrze.
-
Nie wiem co dalej z tym robić. Wszedłem na Allegro do innego sprzedawcy http://allegro.pl/arduino-pro-micro-atmega-32u4-leonardo-micro-hit-i5014242447.html i odnośnik do linku https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/hardware-overview-pro-micro
Pod tym linkiem jest strona Installing Windows, gdzie można znaleźć driver dla ProMicro. Próbowałem zainstalować, ale ja u siebie w menadżer nie mam ścieżki Other devices oraz USB IO Board, mam pod Portami tak jak wspomniałem Arduino Leonardo COM6.
Vito, drivery do których wskazałem Ci linka działają z moim Arduino NANO 3.0 Atmega328. Po ich zainstalowaniu są widziane jako USB-SERIAL CH340 (COM...) pod Windą '10. Widocznie do Leonardo trzeba innych.
-
Zapytałem na Allegro innego sprzedawcę u którego chcę kupić jeszcze raz ProMicro i otrzymałem odpowiedź
Sterowniki i instrukcję do modułu można pobrać ze strony http://www.mobilerobots.pl/index.php?p=1_80 lub sparkfun.com
Po dodaniu bibliotek Sparkfun, moduł jest widziany w Arduino IDE jako "SparkFun Pro Micro 5V/16 MHz"
Zrobiłem kolejną próbę instalacji sterownika dla ProMicro z podanego linku i wynik negatywny. Widać to na zdjęciu. Najdziwniejsze jest to, że na ścieżce driver ja nie widzę plików tylko informacje instalatora. Może nie potrafię pobrać tych driverów.
(http://i700.photobucket.com/albums/ww5/vito_zm/sterownik.jpg) (http://s700.photobucket.com/user/vito_zm/media/sterownik.jpg.html)
Mam problem co dalej z tym zrobić. Mogę kupić u innego sprzedawcy na Allegro ProMicro, ale to także będzie klon z Chin lub próbować kupić oryginał. Może ktoś na forum już instalował klona ProMicro. Mogę też poczekać na powrót 3.14ter z wakacji, może ma w tym temacie doświadczenie.
-
To co zakupiłeś Vito to klon klona tego https://www.arduino.cc/en/Main/ArduinoBoardMicro :)
Mi też nie wykrywa mmjoy2 w IDE, bo bootloader inny wgrany jest i wsio, musisz wgrać bootloader od nowa czysty, żeby ide widziało podpięty uC.
Jeżeli koniecznie chcesz, żeby ide widziało to jako sparkfanowy model płytki - https://github.com/sparkfun/Arduino_Boards
-
Dzięki sugestiom Golasa udało się wgrać do ProMicro program 3.14ter SimOut_LEDs. Zanim omówię testy chciałbym wrócić do moich problemów, które wynikają z braku wiedzy związanej z uP. Zacznę od znanego kontrolera Damosa DMKeys8 opartego na Atm32U4. W tym przypadku nie ma problemów. Po wprowadzeniu DMKeys8 przyciskiem programowym DFU w programie Damosa kontroler był widziany jako ATm32U4 i można było w programie Flip wgrać program użytkowy czyli DMKeys8. Zakładam, że programowa lub hardwarowa ingerencja DFU uaktywnia tzw. bootloader uP.
W naszym przypadku zwarcie RST z GND także uaktywnia bootloader o nazwie Arduino Leonardo na 8 sec. Ponieważ płytka Leonardo oraz ProMicro ma ten sam uP to wydaje się logiczne, że maja taki sam bootloader. Teraz pojawia się problem, który nie rozumiem. Producent płyty nazwanej ProMicro wgrywa jakiś program o nazwia Arduino Leonardo, który jest widziany w IDE oraz w menadżer urządzeń także pod tą nazwą. Pytanie co się kryje w tym programie. Byłem przekonany, że zakupiona płyta ProMicro powinna być widziana w IDE jako ProMicro. Próbowałem intuicyjnie wgrać do jednej z płyt różne drivery od ProMicro, ale bez powodzenia. Może ten bootloader Leonardo jest w konflikcie z driverami ProMicro. Nie znam się na tym. Jedna zakupiona płyta ProMicro z którą nie robiłem eksperymentów jest widziana w IDE i bez problemów wgrałem program 3.14ter. Ciekawe czy drivery definiują wyprowadzenia pinów uP na wyjścia płyty ProMicro. Leonardo ma na płycie więcej wyprowadzeń od ProMicro. Druga sprawa to opcja w IDE wypalania bootloadera. Tak jak wspomniałem na początku wydawało się, że bootloader jest wypalany u producenta uP i określa rodzaj uP. Może ktoś obeznany z tą tematyką wyjaśni te problemy.
Czas na opis testów programu 3.14ter SimOut_LEDs zrealizowanego na ProMicro (Leonardo). Test wykonałem konfigurując w HSC pod adresem 21 LED a następnie pod tym samym adresem 7segLED. Dla LED jest wyświetlane 40 LED w grupach po 8 LED. Numeracja LED jest tak jak na załączonym szkicu. Nie ma to większego znaczenia ponieważ trzeba zrobić pcb z złączami 10 pin i można zachować kolejność tak jak w starym SimOUT. Co do 7segLED to jest tutaj przekłamanie, widać to na tym samym szkicu. Tak jak wspomniałem ma wstępie może 3.14ter ma u siebie ProMicro widziane w IDE z innymi driverami. To wyjaśnimy po jego powrocie z wakacji.
Układ do testów.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Test%20ProMicro.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Test%20ProMicro.jpg.html)
Wyniki testów.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_ProMicro-test.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_ProMicro-test.jpg.html)
-
Mogę być w błędzie, ale wydaje mi się, że ProMicro to sama nazwa płytki już gotowej - natomiast bootloader uzależniony jest tylko i wyłącznie od uC na płycie. Wszak możesz mieć 15 klonów Leonardo pod różnymi nazwami z różnie poprowadzonymi ścieżkami i wejściami - a i tak IDE będzie widziało to jako Leonardo ze względu właśnie na wsad do uC. Jak się mylę poprawcie ;)
-
Coś w tym jest, każdy bootloader jest odpowiednio skonfigurowany pod dane uC. Ostatnio miałem okazję robić Arduino ze zwykłej Atmegi8.
-
No ja poczyniłem tak kiedyś z jakiegoś attiny do jakiejś pierdoły gdzie ni w żab nie chciało mi się gotowca przepisywać na c++, kwestia właśnie bootloadera - kilka ósemek mam do odzysku ale brak czasu i chęci żeby poskładać HVP (programator 12V)
-
W takim razie pytanie praktyczne. Jeśli wgrałem program MMJoy2 do mojego ProMicro (Leonardo) czy jest możliwość powrotu do takiej wersji aby był widziany w IDE. Po wgraniu MMJoy2 jest nadal widziany w menadżer urządzeń po zwarciu RST z GND jako Arduino Leonardo przez 8 sec. Jak to zrobić, czy jest potrzebny programator czy można to zrobić z poziomu IDE czy może Flipa oraz tylko USB.
-
Musisz prawidłowo sflashować w ciągu tych 8 sekund. Jeśli klon Pro Micro jest widoczny jako Leonardo, użyj sterowników od Leonardo. Wystarczy IDE.
-
Drugi ProMicro (Leonardo) na którym robiłem eksperymenty jest już widziany w IDE. Reaktywizację zrobiłem w następujący sposób. W Menedeżr urządzeń był widziany jako inne urządzenie. Prawym klawiszem myszy wybrałem aktualizuj sterowniki i wybrałem wskazanie ręczne ścieżki gdzie jest driver. Driver jest na ścieżce Arduino (IDE) -> drivers. Po chwilowym zwarciu RST z GND w czasie 8 sec wskazałem wspomnianą ścieżkę z driverami i aktualizuj. W IDE jest teraz widziany jako Leonardo i mogę wgrać program 3.14ter. Mam już 2 ProMicro (Leonardo) widziane w IDE i mogę robić kolejne testy z programem 3.14ter w połączeniu "sieciowym" RS232.
Mam pytanie do Golasa związane z ProMicro oraz MMJoy2. Czy możesz zrobić eksperyment jeśli to jest możliwe polegający na wgraniu do ProMicro drivera od Leonardo tak aby był widziany w IDE. Ja nie wiem jak to zrobić. W menadżer urządzeń MMJoy2 nie jest widziany, prawdopodobnie jest jako HID. Jeśli zewrę RST z GND to pojawi się na 8 sec jako Arduino Leonardo bootloader COM...Czy można to zrobić bez zewnętrznego programatora.
Musisz prawidłowo sflashować w ciągu tych 8 sekund. Jeśli klon Pro Micro jest widoczny jako Leonardo, użyj sterowników od Leonardo. Wystarczy IDE.
Czy możesz podać szczegóły jak to zrobić, nie jestem fachowcem w tej dziedzinie.
-
Kolejny krok do przodu. Połączyłem z sobą 2 ProMicro. Jeden jest master o adresie 21 a drugi slave z adresem 22. Zgodnie z sugestią zablokokowałem // #define MASTER_MODULE oraz zmieniłem adres na 22. Niestety transmisja do slave nie dochodzi (nie zapala się dioda RX w slave) nie zapalają się także LED w testerze. Myślę, że trzeba zrobić małą korektę w programie.
Nie zamawiam jeszcze NANO, zrobię to później po powrocie Piotra. Jestem pewny, że projekt SimOut oparty na Arduiono będzie działać. Ponieważ HSC jest przygotowane na sterowanie 48 LED w ramach jednego uP (adresu IP) oraz 6 7segLED to możemy także to zrobić w nowym SimOUT (powinien być wolny 1 pin). Można pod ten projekt wykonać płytki pcb. Master może być na ProMicro (płytka 23 zł) a slave na NANO (14-15 zł). Dla opcji 48 LED dochodzi 6 złączy 10 pin, dla 7segLED 1 złącze 16 pin. Projekt bardzo tani z możliwością tzw. dekompozycji modułów co jest korzystne przy budowie kokpitów.
Układ do testów.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Ms-Sl.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Ms-Sl.jpg.html)
-
Na schemacie jest pokazana pierwsza wersja SimOut zrealizowana na Arduino ProMicro z prototypowym programem 3.14ter. Program realizuje sterowanie 40 LED, dorysowałem jeszcze jedną grupę 8 LED, ponieważ HSC to umożliwia oraz nie ma problemów z wolnym pin na ProMicro. Zasilanie LED jest z zewnętrznego zasilacza 5 V. Projekt jest bardzo tani (ProMicro 23.50 zł) i łatwy do zrobienia. Zamówiłem także Arduino Nano do dalszych testów.
Schemat SimOut -ProMicro-LED.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_SimOut-ProMicro-LED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_SimOut-ProMicro-LED.jpg.html)
-
Czy możesz podać szczegóły jak to zrobić, nie jestem fachowcem w tej dziedzinie.
Nie wiem, czy dobrze zrozumiałem, z czym masz problem. Nie wgrywałem MMJoy2, nie śledziłem aż tak tego tematu, natomiast u mnie Pro Micro w trybie HID jest widoczne jako urządzenie HID z nazwą Arduino Leonardo i jest normalnie dostępne w Arduino IDE pod którymś z portów COM. Miałem taką sytuację, że płytka nie była wykrywana, a wręcz dostawałem komunikat, że nie można rozpoznać urządzenia podłączonego pod USB. Przyczyną było użycie złych sterowników (Sparkfun Pro Micro zamiast Arduino Leonardo), a rozwiązanie problemu polegało na wgraniu dowolnego programu (jednego z przykładowych, które się szybko kompilują) w ciągu tych ośmiu sekund po resecie. Trzeba wybrać prawidłowy sterownik, mikroprocesor, podłączyć pod USB, wybrać port i wgrać program.
W sprzedaży są dostępne klony Sparkfun Pro Micro z jego bootloaderem - wtedy są widoczne jako Pro Micro i wymagają sterowników ze strony Sparkfuna, ale są też klony, które są widoczne jako Arduino Leonardo i one nie potrzebują dodatkowych sterowników, wystarczy wybrać Leonardo.
-
Przyczyną było użycie złych sterowników (Sparkfun Pro Micro zamiast Arduino Leonardo), a rozwiązanie problemu polegało na wgraniu dowolnego programu (jednego z przykładowych, które się szybko kompilują) w ciągu tych ośmiu sekund po resecie.
Dzięki za wyjaśnienia. Też do tego doszedłem, ale nie opanowałem sztuki manipulacji w tych 8 sec. Dzisiaj się udało. Po ustaleniu COM trzeba zrobić kompilację prostego przykładu, zewrzeć RST z GND, w narzędziach zaznaczyć port i przejść do wgrywania. Jeśli nie zdążymy to będzie komunikat. Doszedłem doświadczalnie, że można jeszcze raz na krótko zewrzeć RST z GND w momencie przechodzenia z zaznacz port do wgrywania. U mnie to zadziałało.
Dla mnie IDE oraz Arduino jest nową sytuacją. Miałem do tej pory do czynienia z Flip albo PonyPro, gdzie nie było ograniczenia 8 sec, ale mam nadzieję, że już to opanowałem.
-
Chciałbym nawiązać do moich ostatnich problemów. Jeśli dobrze rozumuję to mamy dwa problemy związane z identyfikacją uP Atm32U4. Gdy zewrzemy RST z GND to jest widziany Arduino Leonardo bootloader na 8 sec. Pytanie pierwsze: czy może być widziany pod inna nazwą np. jeśli jest kilku producentów Atm32U4. Mam na myśli goły uP bez płytki (Leonardo, ProMicro itp.). Czy zapis tego bootloardera jest jednorazowy u producenta uP czy można go zmieniać. Jeśli tak to w jakim celu.
Drugie pytanie dotyczy tzw. sterowników czyli wspomnianych np. Sparkfun Pro oraz Arduino Leonardo. Zarówno jeden jak i drugi jest widziany w IDE. Jakie korzyści dają wspomniane sterowniki, czy chodzi o dodatkowe biblioteki w IDE oraz dostępne przykłady.
Jeśli dobrze zrozumiałem to sterowniki są zapisywane w pamięci uP i mogą być wymieniane dowolną ilość razy na inne.
-
Tak jak pisałem kilka postów wcześniej, wgrywałem ostatnio bootloadera Arduino na Atmege8 za pomocą drugiego Arduino. Więcej w linku:
https://www.youtube.com/watch?v=dpgcBsl9D4k (https://www.youtube.com/watch?v=dpgcBsl9D4k)
-
Widzę, że aby dobrze zrozumieć temat trzeba trochę poczytać. Poszukam w Internecie. Z podanego linku wynika, że bootloader można samemu wgrywać.
-
Otrzymałem zamówione Arduino NANO. Instalacja sterownika przebiegła bez problemów. Można go pobrać z podanego przez Marcina_B linka ( CH 340). Płytka jest widziana po instalacji sterownika w menadżer urządzeń oraz panelu sterowania jako USB-SERIAL-CH 340 (u mnie COM 17). W IDE jest widziana jako Arduino NANO COM 17.
Jeśli chodzi o zrozumienie pojęć bootloader czy sterownik związanych z określonym uP to mogę tylko intuicyjnie zgadywać (brak wykształcenia informatycznego). Tak jak wspomniałem w DMKeys8 jest taki sam uP jak w Leonardo czy ProMicro, ale są inne bootloadery (tak przypuszczam). Bootloader Arduino jest powiązany z platformą IDE. Sterowniki są powiązane z danym systemem operacyjnym oraz bootloaderem i umożliwiają wgrywanie firmware. Tutaj przykład firmware MMJoy2, DMKeys2 czy przykłady z Arduino dla tego samego uP. Dla ignoranta w dziedzinie informatyki takiego jak ja może to stanowić pewien problem, dla informatyka jest to oczywiste.
-
What's a bootloader?
Microcontrollers are usually programmed through a programmer unless you have a piece of firmware in your microcontroller that allows installing new firmware using an external programmer. This is called a bootloader.
https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader (https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader)
-
Dzięki za link, bardzo ładnie jest to wytłumaczone.
-
Wróciłem!
Klony ProMicro
Najczęsciej przychodzą z wgranym bootloaderem Leonardo i tak też ich używam, w Arduino zazanaczając płytkę jako Leonardo.
Problemy z wyświetlaniem cyfr
Wspominałem o tym w tym poście:
http://il2forum.pl/index.php/topic,17749.msg342566.html#msg342566
Monitorowałem bajty, które wysyła program testujący w simOUT i okazuje się, że poszczególłne segmenty wyświetlacza a...kropka wcale nie odpowiadają bitom 0-7.
Moją prośbą było tylko sprawdzenie czy cyfry wyświtlają się prawidłowo we współpracy z konkretnym symulatorem i nie jest to tylko błąd w testerze simOUT.
Tak wyglądają dane nadawane przez tester simOUT podczas testowania wyświtlacza 7 segmentowego, cyfry 0-9:
(http://i.imgur.com/yO3dmyX.png)
Kolejność bitów w bajcie załączającym LEDy jest odwrócona.
Remedium w programie dla Arduino jest bardzo proste. Wystarczy podmienić linię 66 na
int ledDrivers[8] = {16,10,9,18,15,14,7,8};
lub ściągnąć program od nowa:
https://github.com/hexeguitar/simOUT_LED_arduino
i cyfry powinny wyświetlać się prawidłowo,
Postaram się dodać obsługę 6 cyfry lub 8 dodatkowych LEDów i zobaczę co tam jeszcze nie działa w komunikacji Master/Slave. Nie zdążyłem tego zrobić przed wyjazdem.
-
Bardzo się cieszę z Twojego powrotu. Jak zauważyłeś próbowałem trochę powalczyć i mam zrobiony model z ProMicro oraz UNO dla dalszych testów.
Sprawdziłem wyświetlanie 7segLED po korekcji linii int ledDrivers[8] = {16,10,9,18,15,14,7,8};
Teraz mam wyświetlane następujące znaki:
1->1 ale z lewej strony (f, e) , powinno być z prawej (b, c),
2->2
3-> odwrócone 3 czyli (a, f, e, d oraz g)
4-> odwrócone 4 czyli (f, e, g oraz c)
5->5
6->9
7-> też odwrócone (f, e, oraz d)
8->8
9->6
0->0
Korelacja między pinami ProMicro a segmentami jest u mnie na modelu tak jak na #241, podobnie wyprowadzenia na złącze 16 pin tak jak na #226 (oznaczenia segmentu oraz pin na złączu).
-
Wygląda na to, że u Ciebie f i e zamienione są z b i c.
U mnie działa w porządku. Sprawdziłem połączenia miernikiem (pin Arduino->segment wyświetlacza). Błędu raczej nie ma, zgadza się z tym co wpisane jest na początku programu.
Wygląda na to, że wersja 1.1.1.1 HSC nie potrafi przetestować modułu z 6 cyframi/48Led? Wpisanie wartości większej niż 5 w pole "Ilość wyświetlaczy" cofa ją do 5.
Niestety, ale nie udało mi się namierzyć nowszej wersji programu.
-
Czy segmenty są u Ciebie na tych samych pinach co u mnie #241 w ProMicro. Mogę oczywiście zamienić segmenty tak jak sugerujesz. Jutro jeszcze sprawdzę omomierzem od pin ProMicro do 7segLED. Ja mam wersję 1.1.1.2 i jest ok mogę Tobie przesłać mailem. Jest jeszcze nowsza wersja, gdzieś ją mam muszę poszukać, gdzie są jeszcze inne moduły np. serwo.
-
Sprawa się wyjaśniła, jest ok. Złe odczyty cyfr z wyświetlaczy 7segLED były spowodowane moim roztargnieniem. Postawiłem mój tester do góry nogami i dlatego cyfry wyglądały jak lustrzane odbicie. Tester to ta skrzynka na #241, przepraszam za zamieszanie.
Jeśli chodzi o nowszą wersję to mogę przesłać na maila, podaj adres.
-
Diabeł siedzi w szczególikach ;).
Odezwę sie przez email w sprawie nowego HSC.
-
Nowa wersja programu simOUT LED na Arduino (https://github.com/hexeguitar/simOUT_LED_arduino)
Co nowego:
- rozwiązany problem z poprawnym wyświetlaniem cyfr,
- dodana obsługa 6 wyświeltaczy lub 48 LEDów,
- komunikacja master/slave naprawiona, chociaż jeszcze gruntownie nie przetestowana,
- można tworzyć łańcuchy modułów, slave nadaje dane dalej na pin TX, który podłączamy do kolejnego slave RX itd.
- jako slave można użyć tańszego Nano, uwaga na róźnice w numeracji pinów (np. D18 w ProMicro=A0, ale D18 w Nano=A4),
- dodatkowy program skonfigurowany jako slave na M328 (Nano) z adresem 22.
Widzę, że wersja HSC 1.1.1.2 ma opcję ustawiania jasności LEDów. Zrobi się w wolnej chwili.
-
Dzięki, jutro sprawdzę i dam znać jak wypadły testy.
-
Wgrałem nowy program do ProMicro. Jako master o adresach 21 oraz 22 działają prawidłowo.
Jeden ProMicro o adresie 22 ustawiam jako slave blokując // #define MASTER_MODULE .
Łączę master adres 21 pin 1 TX z slave o adresie 22 pin 2 RX. Nie ma komunikacji, brak reakcji dioda odb. w slave oraz brak reakcji w testerze LED. Master działa prawidłowo - tester 7segLED.
Wgrałem program do NANO, muszę na płycie z NANO dolutować interfejs dla połączenia z moim testerem.
Problem na teraz to brak komunikacji po "łańcuchu" ProMicro TX->RX.
-
Teraz powinno działać. Serial1 nie był inicjowany w przypadku slave na 32U4.
-
Gratulacje, działa komunikacja po "łańcuchu" ProMicro. Muszę dorobić w moim modelu interfejs dla NANO dla mojego testera. Pytanie czy program dla NANO też zmieniłeś czy ten wczorajszy jest dobry. Drugie pytanie dotyczy pinów w NANO czy A0 to D14, A1 D15, A2 D16 , A4 D18 oraz A5 D19.
-
Program dla Nano działał w porządku, ale warto go też uaktualnić. Problem był jedynie ze slave na 32U4.
Numeracja pinów w modelach Arduino - w sieci pełno jest gotywych diagramów do każdej wersji.
(https://s-media-cache-ak0.pinimg.com/originals/96/34/69/96346944b39d00c36b6300c605c8fecd.jpg)
-
Dzięki za diagram, w sieci faktycznie jest ich dużo, ale ten ma potrzebne oznaczenia ( fioletowe). Mój plan to zrobienie kolejnego modelu na dwóch NANO z kolejnymi adresami. Następie utworzę łańcuch z 2 płytek, na jednej jest master oraz slave z ProMicro na drugiej wspomniane slave z dwóch NANO. Jeśli będzie działać to podłączę do symulatora i zobaczymy jak to zadziała. Na koniec zrobię schemat z NANO pod 7segLED oraz 48 LED.
Chciałbym już teraz podziękować Piotrowi za wspaniały prezent dla pitbuilderów. Można za pomocą tego projektu zrealizować dowolną liczbę LED oraz 7segLED korzystając tylko z jednego USB bez konwertera. Realizacja jest bardzo tania. Dodatkowa korzyść to rozproszony hardware (dekompozycja), mniej potrzeba kabli. Oczywiście bez HSC byłoby to niemożliwe, dzięki codeking za platformę .
Oczywiście nic nie stoi na przeszkodzie aby zaprojektować pcb pod te warianty.
-
Zrobiłem testy w układzie pokazanym na zdjęciu. Na pierwszej płytce są 2 moduły ProMicro o adresach 21 master oraz 22 slave. Na drugiej płytce są 2 układy NANO slave o adresach 23 oraz 24. Układy są połączone równolegle do szyny danych TX z master. Do ProMicro o adresie 21 mogę podłączyć LED lub 7segLED (konfiguracja w HSC) do 22 tylko LED do 23 LED oraz do 24 7segLED.
Testy wykonałem dla konfiguracji 40 oraz 48 oraz dla 5 lub 6 cyfr 7segLED.
Wyniki są prawidłowe oprócz przypadku 6 cyfr dla NANO.
Wyniki testów.
ProMicro
Opcja 48 LED opcja 40 LED
D19 1-8 D6 1-8
D6 9-16 D5 9-16
D5 17-24 D4 17-24
D4 25-32 D3 25-32
D3 33-40 D2 33-40
D2 41-48
Opcja 6 cyfr opcja 5 cyfr
uP HSC uP HSC
D19 006 D19 no
D6 005 D6 005
D5 004 D5 004
D4 003 D4 003
D3 002 D3 002
D2 001 D2 001
UNO
Dla 48 LED oraz 40 LED wyniki takie same jak dla ProMicro.
Dla opcji 5 cyfr (7segLED) wyniki takie same jak dla ProMicro.
Dla opcji 6 cyfr są różne.
Opcja 6 cyfr
uP HSC
D19 006
D6 001
D5 004
D4 003
D3 002
D2 001
Po wyjaśnieniu tych rozbieżności zrobię schematy na podstawie których można zrobić pcb. Wyjaśnię także gdzie zmieniać adresy oraz master/slave w programie Piotra.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_test%20SimOut.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_test%20SimOut.jpg.html)
-
Na czym polegają te różnice w wyświetlaniu szóstej cyfry w Nano? W ogóle nie działa? Pojawiają się krzaki?
Trochę dziwne, że 48 pojedynczych LEDów działa w porządku, a wyświetlacz nie. Gdyby był jakiś błąd w programie, LEDy również nie działałyby prawidłowo.
-
Dla NANO dla 5 cyfr jest tak jak dla ProMicro czyli ok :
uP HSC
D19 brak
D6 005
D5 004
D4 003
D3 002
D2 001
Dla 6 cyfr też zapalają się cyfry tylko D2 i D6 zapala tę sama pozycję czyli 001 (pierwsza cyfra). Na moim testerze mam tylko 5 cyfr 7segLED, jedną przełączam
NANO dla 6 cyfr
uP HSC
D19 006
D6 001 powinno być 005
D5 004
D4 003
D3 002
D2 001
-
Takie mam pytanko. Chcę podłączyć do Arduino takie wyświetlacze numeryczne. Dokładnie 1 zestaw 5-cio cyfrowy i 1- zestaw 4 cyfrowy. Marcin B mówił, że po podłączeniu 2-ch takich zestawów do jednego UNO czy NANO, wyświetlacze mrużyły (migotały). Czy to sprawa za słabego zasilania, nie wiem czy dopinał dodatkowe. Czy może MEGA da radę tym dwóm zestawom ?
-
Wyświetlacze są multipleksowane. Znaczy to, że Arduino wyświetla tylko jedną cyfrę naraz i przemiata przez wszystkie na tyle szybko, że oko tego nie zauważa. Dodanie każdej cyfry zmniejsza tą szybkość aż do momentu, gdy przemiatanie stanie się widoczne dla oka. Można temu zaradzić zwiększając częstotliwość multipleksera. Dużo zależy od programu i tego, co procesor musi robić opócz obsługi wyświetlaczy. Może się okazać, że przyspieszenie wyświetlacza nie będzie możliwe, bo timer robi coś tam jeszcze innego i wymagany jest taki, a nie inny interwał. Cieżko powiedzieć bez rzucenia okiem na kod.
-
Ooooo ale to by wiele wyjaśniało, wszystko jest oparte na DCS Bios więc tu lepiej nie mieszać he he he. Lepiej wstawić dwa i mieć spokój, jedyny problem to następny kabel USB. Chyba, że jest metoda łączenia płytek między sobą... Do tych wyświetlaczy dojdą jeszcze 3 potencjometry, 3 przełączniki dźwigniowe on-off, 1 obrotowy 5 polowy oraz 4 enkodery. Miałem zamiar to opędzić na Arduino Mega, zobaczę , może migotanie nie będzie dla mnie takie upierdliwe.
-
U mnie pod Arduino są tylko wyświetlacze, reszta śmiga pod DMK8. Dzięki temu mogę ich używać pod innymi modułami a nie tylko A-10C.
-
Tak wiem, wiem Marcinie, u mnie wszystko idzie na Arduino. No prawie, bo UFC będzie na DMK8. Miałem - mam tylko nadzieję, że mój panel TACAN-ILS-LIGHT EXT zrobię na jednym układzie, by nie mnożyć kabli USB.
-
Ja bez HUBów bym nie dał rady :)
-
No ja też mam, tylko miałem nadzieję na układ 1 panel = 1 kabel .
-
Jutro sprawdzę na pinach NANO D2, D3, D4, D5, D6 oraz D19 woltomierzem wybierając kolejno w HSC 001 - 006. Dziwne jest to, że 6 grup dla LED jest ok, podobnie 5 cyfr dla opcji 5 7segLED.
Marcin szkoda, że HSC nie obsługuje DCS. W HSC wystarczy 1 USB, moduły Arduino łączy się równolegle do TX z master. LED oraz 7segLED zasilane są z zewnętrznego zasilacza a nie z USB, dodatkowo jest multipleksowanie co zmniejsza pobór prądu.
-
Sprawa się wyjaśniła jest ok. Jak zwykle problem był trywialny. Mam w testerze 5 cyfr, dlatego muszę dla opcji 6 cyfr wyświetlać na jednym wyświetlaczu 2 cyfry z UNO. Robię to przełączając na modelu te dwie cyfry.
Projekt simOUT zrealizowany na ProMicro oraz UNO można uważać za zakończony. Zrobię schematy dla tych modułów. Możliwa jest realizacja 4 płyt : ProMicro z interfejsem LED lub 7segLED oraz UNO z tymi samymi interfejsami. Opcje wyboru 40 lub 48 LED ustawiamy w konfiguracji HSC podobnie 5 lub 6 cyfr.
Adres modułu oraz wybór master/slave w programie Piotra. Napiszę o tym później. Proszę pytać jeśli są wątpliwości.
-
Tak jak obiecałem, jest to schemat slave zrobiony na bazie NANO realizujący sterowanie wyświetlaczy 7segLED.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Uno-7segLED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Uno-7segLED.jpg.html)
Z schematu wszystko wynika. Łączymy go 3 przewodami podobnie jak w starym SimOUT z pozostałymi płytkami. Schemat bardzo prosty i jego realizacja bardzo tania. Jutro postaram się zrobić pozostałe schematy.
-
Kolejny schemat tym razem master realizujący sterowanie wyświetlaczy 7segLED i zrealizowany na ProMicro.
Master
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Master-7segLED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Master-7segLED.jpg.html)
Płytki slave zrobione z NANO oraz 7segLED podobnie jak LED są zasilane z zewnętrznego zasilacza 5V.
-
Schemat master realizujący sterowanie 48 LED. Pozostał jeszcze jeden schemat do zrobienia i będzie komplet.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_master-LED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_master-LED.jpg.html)
-
Ostatni schemat płytki realizującej sterowanie 48 LED zrobiony na NANO.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_nano-LED.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_nano-LED.jpg.html)
Mamy do dyspozycji 4 różne płytki realizujące sterowanie 48 LED lub 6 cyfr 7segLED oparte na ProMico oraz NANO. Możemy je łączyć w łańcuch w zależności od naszych potrzeb. Tylko jedna płytka pracuje jako master i jest połączona z pc przez USB, pozostałe są slave podobnie jak w starej wersji simOUT. Wszystkie płytki mają swoje adresy, które wpisujemy do programu Piotra simOUT_LEDs_slave328 oraz simOUT_LEDs w IDE.
Wpisujemy w lini 54 adres modułu np. 23
const uint8_t devAddress = 23
Reasumując master jest zrobiony na bazie ProMico a slave na NANO.
Celowo nie napisałem o innych możliwościach aby nie komplikować. Wspomnę tylko jako ciekawostkę, że można ProMicro także zaprogramować jako slave. Jeśli stosujemy w projekcie tylko jedną płytkę master to można zamiast zewnętrznego zasilania LED lub 7segLED użyć napięcia 5V z USB, powinno wystarczyć przy multipleksowaniu LED. Na tym kończę testowanie projektu. Może przy okazji sprawdzę w symulatorze, ale nie powinno być problemów. Na koniec chcę podziękować Piotrowi za wspaniały prezent. Jest to duży postęp w porównaniu do starej wersji simOUT. Moduły ProMicro oraz NANO są dostępne i tanie.
-
Mam pyatnie odnośnie włączania samego Arduino. Zaobserwowałem drobną różnicę między Arduino Uno a Mega (w zasadzie działania).
Mianowicie na początku oczywiście trzeba podłączyć Arduino za pomocą USB i właczyć plik " connect-serial-port.cmd", potem DCS-a i misję. Jeśli z jakiegoś powodu, w czasie gry, odłączymy Arduino UNO od USB lub zamkniemy plik "connect-serial-port.cmd", możemy go ponownie włączyć w czasie gry i wszystko zacznie działać. W Arduino MEGA już tak nie jest, trzeba koniecznie wyłączyć misję i załadować ją ponownie, w innym przypadku Arduino MEGA nie zadziała tak jak to robi Aduino UNO.
Czy jest jakiś sposób by działała tak jak UNO, jakiś wpis do Arduino, czy ten typ już tak ma i już ?
-
Czy z Arduino zadziała enkoder magnetyczny COPAL, taki jak ten: http://allegro.pl/promocja-enkoder-encoder-impulsator-copal-250-a-b-i6694614957.html#thumb/2 ?
Ma to być do ustawiania kursu na HSI, ze zwykłym enkoderem bym chyba oszalał, ten ma 250 inp.
-
No i jak koledzy, nikt nie wie ? Szkoda mi 70zł na test wydać...
-
Z fizycznym podłączeniem nie powinno być problemu. Pytanie tylko czy te wbudowane w biblioteki (zakładam, że chcesz to użyć w DCSbios?) procedury obsługi enkoderów nie będą gubić kroków. Przy 250 krokach na obrót podejrzewam, że tak.
-
Mam HSI na zwykłym tanim enkoderze i nie ma problemu działa pod HSC codeking. Możesz kupić od 3.14ter niezawodne rozwiązanie dla enkodera, ale to też jest wydatek. Za niezawodność trzeba niestety zapłacić.
-
Zwykły enkoder jak będzie miał 20-30 kroków to już chyba max, jak będę chciał ustawić z 0 stopni na 180 to go chyba urwę albo ukręcę... Są jeszcze optyczne, 60 kroków to już coś, ale czy te będą działać?
-
Od strony programowej robi się to zazwyczaj tak, że jest dodatkowa opcja typu "acceleration". Im szybciej kręci się enkoderem tym większe są skoki wartości. Zajrzałem do kodu DCBbios, niestety używają prościutkiej obsługi enkodera, który "odpytywany" jest co jakiś czas, bardzo prawdopodobne, że będzie gubił kroki.
Jest jeszcze biblioteka "ClickEnkoder" pod Arduino, która ma tą funkcję przyspieszania zaimplementowaną. Pewnie można jakoś obie pożenić, w sensie DCSbios i ClickEnkoder...
Obiawiam się, że nawet moja płytka do enkodera (którą można sobie również zbudować samemu, pojekt jest dostępny tutaj (https://github.com/hexeguitar/Enc2Btn)) tu nie pomoże, a wręcz zwolni obsługę, bo zlicza kroki enkodera i potem je "wyklikuje" ze stałą mniejszą prędkością.
-
Ile najwięcej kroków może mieć taki zwykły enkoder?
-
Od strony programowej robi się to zazwyczaj tak, że jest dodatkowa opcja typu "acceleration". Im szybciej kręci się enkoderem tym większe są skoki wartości
Tak było w MJoy16. Z drugiej strony jaki problem obrotu gałką jeśli obserwuję efekty tego obrotu na ekranie LCD, nawet jeśli gubi impulsy to można to korygować.
-
Ile najwięcej kroków może mieć taki zwykły enkoder?
To zależy od piszącego obsługę tego enkodera, w jaki sposób odczytuje stany wyjść. Jeśli przy tych, które masz obecnie zdarza się, że gubi kroki przy szybkim kręceniu, to lepiej niestety nie będzie.
A jeszcze wracając do mojej bilbioteki Joysticka na Arduino. Podczas testów, żeby program w ogóle ruszył, wymagane będą rezystory pull-up ok. 4k7 na liniach I2C, nawet jeśli się nie używa kości MCP23017. Bez tego program zatrzyma się gdzieś w pętli w bibliotece Wire i będzie czekał.
Z ciekawości sprawdziłem czy DSC wykryje więcej przycisków niż 32. Owszem, widzi pełne 128 sztuk:
(http://i.imgur.com/UTovcNB.png)
Windowsowy tester joysticków bez problemu pokazuje również 4 HATy - innymi kolorami.
-
Podobnie chyba z osiami jest ;)
-
Czyli chyba z mechanicznych zostaje mi taki 30 imp na obrót.... ?
-
Cześć,
czy wiecie może jak wydłużyć okres minimalnego kliknięcia przycisku? Aktualnie wynosi on 3-4ms, a pewnie wiecie, że dla Il2 BoS to za mało by przechwycić akcję. 25ms to rozsądne minimum. Pytanie jest ogólnie o Arduino, ale gdyby ktoś wskazał fragment w bibliotece/kodzie 3.14tera to byłbym mocno dźwięczny ;)
-
Mam zamiar zrealizować nowy projekt związany z moim kokpitem. Do tego celu potrzebuję kontroler gier. Pomyślałem o MegaJoy kolegi Piotra. Tak powstał kontroler przedstawiony w tym wątku. Kontroler ma sterować 2 haty, joystick, potencjometry oraz przyciski.
Poprosiłem kolegę Piotra 3.14ter aby zrobił dla mnie na bazie MegaJoy uproszczony skrypt na ProMicro. Skrypt pod nazwą Joy2 jest tak pomyślany, że nie wymaga od użytkownika ingerencji w programie (plug and play). Po tym wstępie chciałbym opisać działanie Joy2 na przykładzie mojego kontrolera. Na schemacie ideowym są pokazane elementy oraz ich połączenia. Schemat jest bardzo prosty i łatwy do zrealizowania. ProMicro steruje dwa rejestry MCP 23017 sygnałami SDA, zegarem SCL i przerwaniem INT. Wyjścia rejestrów są wyprowadzone na łączówki ozn. Ł0-Ł4 10 pin.
Sygnały Joy2 są widziane w Windows w kontrolerach gier.
Wyprowadzenia sygnałów:
Łączówka Ł0:
A0 - oś X, A1 - oś Y, A2 - oś Z, A3 - obr. Z, A6 - obr. X, A7 - obr. Y
Łączówka Ł1:
A0 - 1, A1 - 2, A2 - 3, A3 - 4, A4 - 5, A5 - 6, A6 - 7, A7 - 8
Łączówka Ł2:
B0 - 9, B1 - 10 , B2 - 11, B3 - 12 ,B4 - 13, B5 - 14, B6 - 15, B7 - 16
Łączówka Ł3:
B0 - 17, B1 - 18, B2 - 19, B3 - 20 ,B4 - 21, B5 - 22, B6 - 23, B7 - 24
Łączówka Ł4:
A0 - Up1, A1 - R1, A2 - Dn1, A3 - L1, A4 - Up2, A5 - R2, A6 - Dn2, A7 - L2
Sygnały cyfrowe 1-24 możemy łączyć z przyciskami, przełącznikami lub enkoderami. Nie potrzeba stosować diod tak jak w matrycach.
Sygnały analogowe są filtrowane. Osie X oraz Y mają włączone deadzone pozostałe nie mają. Można je włączać lub wyłączać, jest to opisane w języku polskim w skrypcie.
Sprawdziłem działanie skryptu Joy2 z przyciskami, potencjometrami oraz joystickiem. Jest to pokazane na zdjęciu. Realizując mój docelowy projekt sprawdzę kontroler z układami wykonawczymi już w symulatorze. Na tym etapie działa poprawnie tak jak to opisałem. Można zrealizować kontroler w inny sposób umieszczając ProMicro w od dzielnej obudowie a rejestry połączyć z uP za pomocą złącza 5 stykowego PS/2.
Na załączonych zdjęciach jest schemat ideowy, kontroler w obudowie oraz układ do testowania. Pod tym linkiem jest skrypt
http://www.prdevices.pl/rozne/forum/joy2.ino
Schemat ideowy.
(http://www.prdevices.pl/rozne/forum/schemat_kontr.jpg)
Kontroler na druku uniwersalnym.
(http://www.prdevices.pl/rozne/forum/montaz_kontr.jpg)
Gotowy prototyp.
(http://www.prdevices.pl/rozne/forum/obud_kontr.jpg)
Układ do testowania.
(http://www.prdevices.pl/rozne/forum/uklad_testowy.jpg)
-
A jak z obsługą hallotronów? Będzie opcja? Pozdrawiam 3.14tera ;-)
-
Małe uzupełnienie do schematu ideowego. Warto podwiesić rezystory 470R-1K do linii sygnałowej SDA oraz zegara SCL jeśli rejestry będą w większej odległości od ProMicro. Jeśli będą w pobliżu to 4K7 - 1K.
-
A jak przebiega wstępna kalibracja joya? W systemowym kalibratorze?
-
Sprawdzałem analogi w WB_JoyTester, wygląda to dobrze. Będę sprawdzał możliwości ustawiania strefy martwej w skrypcie. Piotr zastosował filtry programowe dlatego przebiegi wyglądają obiecująco. Mam nadzieję, że autor skryptu powie coś więcej na ten temat.
-
Zrobiłem model dla testowania programu Joy2. Model jest w trakcie rozbudowy, ale można już testować niektóre elementy. Po sprawdzeniu analogów oraz przycisków przyszedł czas na haty. W tym momencie chciałbym podziękować koledze shopik z forum. Dostałem od niego 2 elementy o nazwie RKJXT1F. Realizują 4 kierunkowy hat, enkoder praz przycisk. Zaletą tego "joysticka" jest długa metalowa ośka. Jest to bardzo istotne gdy chcemy osadzić gałki. W tym momencie znowu pomoc kolegi shopik, który dla mnie zrobił takie gałki pod ten joystick. Na zdjęciu są pokazane 2 RKJXT1F umieszczone na modelu. Sprawdziłem haty oraz przycisk i działają. Przyszła kolej na enkoder. Byłem ciekawy jak to zadziała z Joy2. Przed sprawdzeniem enkodera w RKJXT1F sprawdziłem mój enkoder, który używam dla testów podłączając go do Joy2. Tak jak było do przewidzenia Joy2 nie może pracować z enkoderami. Powód jest prosty. Enkoder generuje na wyjściach kod Graya czyli dla 2 bitów: 00, 01, 11 oraz 10 dla jednego kierunku obrotu oraz 00, 10, 11, 01 dla drugiego kierunku. Sprawdzałem w Win7 oraz w WB_BtnTester wyniki są takie same. Joy2 powtarza to co ma na wejściu rejestrów MCP 2317.
W innym kontrolerze DMKeys8 Damosa konfigurując wybieramy z dostępnych elementów enkoder i jego typ. Dodatkowo Damos przewidział możliwość zmiany 2 parametrów Encoder filter (0-10) oraz Encoder idle time (0-255). Generalnie chodzi o to, że enkodery te tanie są kiepskiej jakości i trudno dekodować zbocze impulsów oraz stwierdzić które zbocze jest dla obrotu w lewo a które dla obrotu w prawo, zbocza czasem na siebie nachodzą. Nawet te dwa parametry nie niwelują całkowicie przekłamań, ale znacznie je ograniczają. W praktyce pojedyncze przekłamania kierunku nie są zauważalne w symulatorze.
W innym znamy kontrolerze MJoy16 były tylko 4 dedykowane wejścia dla enkoderów.
Na koniec sprawdziłem enkoder zaprojektowany przez Piotra 3.14ter. Ten generuje na jednym z wyjść ciąg impulsów przy obrocie w jednym kierunku (na drugim brak impulsów) i podobnie dla drugiego kierunku obrotu. Na wyjściach nie ma kodu Graya czyli można go stosować z Joy2.
Działa on wolniej i przy szybkim obrocie generuje impulsy po zakończeniu obrotu gałką.
W moim przypadku rezygnuję z enkoderów w RKJXT1F, ale mogę zastosować enkoder Piotra.
Gdy zakończę montaż mojego modelu oraz wykonam testy w symulatorze opiszę w tym wątku swoje wioski.
Na załączonym zdjęciu jest Joy2 oraz mój model.
(http://www.prdevices.pl/rozne/forum/m_model2.jpg)
-
Mam już sprawdzony mój panel w Win7 oraz VKB_BtnTester i VKB_JoyTester jest ok. Panel ma analogowy joystick oś X oraz oś Y, 4 potencjometry obrót X, Y, Z oraz oś Z enkoder Piotra oraz 3 przełączniki. Jest jeszcze wolnych 16 wejść cyfrowych w Joy2. Moim celem jest latanie w symulatorze BMS4 w uproszczonej konfiguracji sprzętowej tzn. bez kokpitu korzystając z biurka. Panel ma wspomagać joystick Logitech 3D. Takie są założenia.Przy pierwszych testach pojawiły się problemy o których mogłem się domyślać.
W moich założeniach dwa haty w panelu miały realizować funkcje hatów w sticku Cougara DMS oraz TMS. Analogowy joystick miał przejąć sterowanie kursorami w MFD, które realizował joystick w przepustnicy Cougara. Pozostałe elementy w panelu miały tylko wspomagać np. trymowanie itp.
W setup BMS4 muszę wybrać jako kontroler Logitech Extreme 3D i tutaj mogę przypisać wszystkie klawisze, potencjometr oraz hat z Logitech. Niestety z panelu nie mogę mapować moich dwóch hatów, pozostałe elementy są dostępne w setup. Haty z panelu są widziane w setup BMS 4 tylko jeśli wybiorę w kontrolerze setup Arduino Leonardo zamiast Logitech.
Reasumując musiałbym mieć jeden program pod Logitecha oraz panel sterowany przez program Joy2 (Arduino Leonardo) co jest nie możliwe. Jest oczywiście możliwość zastąpienia kontrolera z Logitech 3D kontrolerem Joy2, ale tutaj też jest ograniczenie z liczbą dostępnych Hatów potrzeba trzech. Czyli albo program MegaJoystick albo np. MMJoy2.
Jest możliwe dla Joy2 rozwiązanie problemu z Hat 1 oraz Hat 2 dla mojej konfiguracji z Logitech 3D. Haty połączyłem do innej łączówki gdzie są traktowane jako przyciski. Łączówka z Hat 1 oraz Hat 2 zostanie nie połączona. Jest to rozwiązanie zastępcze ale działa. Teraz muszę optymalnie mapować Logitech 3D oraz mój wspomagający go panel.
Na zdjęciu jest pokazany mój zestaw oraz w tle kokpit.
(http://www.prdevices.pl/rozne/forum/panel_Logitech.jpg)
-
Niedługo trzeba ci będzie jakiś ładny panel wygrawerować :-)
-
Dzięki za propozycję. Teraz testy z BMS4 co jest związane z mapowaniem czyli plikiem .key. Sam jestem ciekawy jak to będzie działać. Może powstanie na podstawie wniosków z testów coś jeszcze.
-
Mam pytanie dotyczące programowania uP Atmega32u4 . Fabrycznie nowy uP ma wgrany do pamięci Flash bootloader ~ 4 KB ATM32U4DFU. Jeśli połączymy "płytkę" z fabrycznie nowym Atmega32u4 z pc przez USB to możemy np. za pomocą programu Flip wgrać nasz program .hex oraz .eep. Przez "płytkę" rozumiem płytkę z uP, kwarcem, USB i innymi potrzebnymi elementami.
Pytanie jest następujące. Co zrobić jeśli mamy płytkę komercyjną np. ProMicro, która ma już inny bootloader i jest widziana jako Leonardo. Chcemy wgrać przez Flip nasz program .hex oraz .eep, ale Flip nie widzi ATmega32U4. Czy jest jakiś sposób aby odzyskać oryginał bootloadera ATM32U4DFU.
Wspomnę tylko, że MMJoy2 poradził sobie z tym problemem. Wystarczy zrobić zwarcie RST z GND, odczytać nr COM i go wpisać w konfiguracji MMJoy2, wybrać ATmega32U4 i to w zasadzie wszystko. Program konfiguracyjny wgra do uP firmware. Od tego momentu płytka jest widziana jako MMJoy2.
Na koniec pytanie czy bootloadery fabryczne uP są kasowane przy wgraniu nowych przez producentów płytek np. Leonardo czy ProMicro.
-
Małe wyjaśnienie, dlaczego pytałem o wgrywaniu firmware do Atmega32u4 . Praktycznie jest nie do zdobycia kontroler Damosa DMKeys8 pomyślałem o zrobieniu z ProMicro mniejszej wersji DMKeys8. Zrobiłem analizę schematów płytki Damosa oraz ProMicro i doszedłem do wniosku, że można zrobić matrycę dla 66 punktów. Nie jest to dużo, ale jest to jakieś rozwiązanie. Największą zaletą projektu Damosa jest jego program konfiguracyjny i dlatego próbuję znaleźć gotową płytkę np. ProMicro do której można wgrać pliki .hex oraz .eep programu Damosa.
Po kilku próbach Flip z ProMicro oraz DMKeys8 doszedłem do wniosku, że nie jestem w stanie nic zrobić. Flip komunikuje się z pc na innej zasadzie w porównaniu z np. programem MMJoy2. Jeśli nie mam oryginału bootloadera ATM32U4DFU w uP Atmega32u4 to mogę zapomnieć o Flip. Pozostaje napisać program podobny do MMJoy2, który umożliwia wgrywanie do Atmega32u4 firmware Damosa.
Pomysł wydaje się dobry, ale realizacja jest dla mnie za trudna.
-
Mam dobre wieści dotyczące płytek DMKeys8. Będzie można za jakiś czas zamawiać u Damosa te kontrolery. W związku z czym nie ma potrzeby szukać rozwiązań zastępczych polegających na zastępowaniu DMKeys8 płytkami np. ProMicro. Ponieważ ten temat poruszyłem to chcę wyjaśnić do czego doszedłem. Damos stosuje u siebie uP Atmega32U4, ale z wgranym fabrycznie DFU. To umożliwia wgrywanie firmware .hex oraz .eep z programu Flip. W ProMicro uP Atmega32U4 nie posiadają DFU, dlatego wymyśliłem prosty sposób wgrywania pliku .hex za pomocą programu MMJoy2, który to umożliwia. Pozostał problem z plikiem .eep. Kupiłem w Internecie programator
https://allegro.pl/oferta/programator-isp-usbasp-atmel-avr-tasma-win7-x64-5191261063?utm_source=notification&utm_medium=buyerCart&utm_campaign=transaction-notifications-buyercart&snapshot=MjAyMC0wMi0wM1QxODowNzo1MS41MjdaO2J1eWVyO2Q1ZWQzZDJlN2VjMDgzNWNjYTg4YTBhMDUwOGY4ZjQzMmEyMDMxMTIzNzNlNzc1MWZmZmZiZjBiODY0OTRhY2U%3D
który to umożliwia. Jestem na etapie szukania do niego sterowników mam nadzieję, że coś znajdę.
Pomysł z zastępczym DMKeys8 zrealizowanym na ProMicro umożliwiał wersję ubogą matrycy 12x6, ale tak jak wspomniałem jest szansa na zamówienie oryginału DMKeys8, który realizuje matrycę 16x10. Mam nadzieję, że wyjaśniłem poruszony temat.
-
Może się komuś przydać. Zrobiłem prosty interfejs dla programowania ProMicro oraz NANO. Wkładamy do podstawek albo ProMicro albo NANO. Połączenie z programatorem USBasp jest standardowe ISP KANDA. Można wypalać bootloader korzystając z IDE lub wgrywając firmware przy pomocy Avrdudess. Dziękuję koledze Piotrowi (3.14ter) za konsultacje.
(https://i.ibb.co/db3FxQ0/interfejs-programator-USBasp.jpg)
Schemat
(https://i.ibb.co/thkbrx9/m-Interfejs-USBasp.jpg)
-
Vito_zm dzięki za pomysł. Ja z niego skorzystam. Jak to fajnie, że "korona..." tych pomysłów nie zeżarła!
Pozdrawiam i życzę nowych pomysłów.
zbyszek
-
Witam, czy można prosić o konkretne porady w budowie panela z przyciskami typu "on-off", przełącznikami obrotowymi np. do wyboru uzbrojenia w migu 21, oraz potencjometrami do np. regulacji oświetlenia kokpitu? Chodzi mi o wykaz cześci potrzebnych do budowy tego (dostępnych w Polsce), oraz samą konfigurację od podstaw? Domyślam się że zapewne musi być to oparte na chociażby Arduino i Dcs - bios, ale jestem "zielony" w tych tematach dlatego potrzebuje instrukcji od podstaw.