Forum Miłośników Symulatorów Lotniczych
Zaplecze => Software & Hardware => Sprzęt wykonany samodzielnie => Wątek zaczęty przez: 3.14ter w Listopada 16, 2016, 11:55:53
-
Zakładam nowy wątek odnośnie projektu joysticka, który wykluł się z rozważań w wątku "Kontrolery Arduino (http://il2forum.pl/index.php/topic,17749.0.html)".
Nie będzie on oparty na Arduino, ale na nieco poważniejszym procesorze PSoC 5LP (Arm Cortex M3).
Początkowo planowałem użyć Bluetooth do bezprzewodowej transmisji, ale okazało się, że to rozwiązanie stwarza problemy, na których rozwiązanie nie wiem, czy chcę poświęcać czas, a do tego wprowadza pewne ograniczenia prędkości trasmisji i ilości danych, które można przepchnąć do PC w odpowiednio krótkim czasie.
Tak więc, po krótkiej i burzliwej przygodzie z Blue-Tooth, który często generował Blue-Screen wróciłem jednak do poczciwego USB. Płytka modelu BLE była na szczęście tak zaprojektowana, że mogę ją spokojnie użyć do prototypu na USB.
Pierwszy sukces:
wygląda na to, że udało mi się obejść problem z ograniczeniem liczby osi i przycisków w DirectX. Kluczem było stworzenie tzw. kompozytowego urządzenia USB-HID, czyli niejako kilku urządzeń w jednym (np. klawiatury z wbudowanym touch-padem są dokładnie czymś takim).
Do testów powstał podwójny joystick, każdy zawierający:
- 8 16 bitowych osi analogowych
- 32 przyciski
- 4 x HAT
Jak widać na fotce, DCS rozpoznaje go jako dwa osobne urządzenia. Przypisałem różne osie dla obydwu joysticków i byłem w stanie przejąć pełną kontrolę nad Żabą, a więc działa :)
Szkoda, że DCS nie bierze pod uwagę różnych nazw dla podjoysticków nadanych w programie, ale to chyba raczej wina Windowsa. Przynajmniej można je rozróżnić po numerze.
(http://i.imgur.com/l1Ll2Lr.png)
A tu prototyp, Bluetooth zastąpiony prockiem PSoC5LP z USB.
(http://i.imgur.com/psr2rGK.jpg)
Stosując kable ekranowane, wbudowane w płytkę przedwzmacniacze i analogową kalibrację zakresów, na każdej z osi dostaję pełne 16bitów z minimalnymi szumami. W takim układzie wahania były na poziomie kilku jednostek, co przy maksymalnej wartości 65535 praktycznie jest pomijalne. Nie bez znaczenia jest też parę tricków zastosowanych na płytce, jak np. oddzielne niskoszumne zasilanie dla części analogowej oraz nie używanie zasilania USB, płytka na uniwersane wejście 7-12V DC z zabezpieczeniami przed odwrotną polaryzacją itd.
Cdn...
-
Witaj
Długo oczekiwałem tego wątku, będę z niecierpliwością czekał na następne części. Kupiłem Psoc5 z nadzieją na naprawdę precyzyjny sprzęt. To czego w arduino trudno uzyskać tu powinno (przynajmniej na papierze ) udać się. W miarę możliwości mogę służyć za testera.
-
Wygląda obiecująco, powodzenia.
-
Czekamy czekamy! Preampy działają i spełniają swoją funkcję nawet w arduino. A już zupełna rewelacja to płytki do enkoderów. Żadnych problemów.
-
Tymczasem modelujemy krzywe dla osi centrowanych.
Lokalne zmniejszenie czułości wokół zera bardzo poprawia precyzję i pomaga zachować centrowanie osi. W bibliotece dla Arduino użyłem funkcji kwadratowej, która jednak dość mocno zmienia charaktetystykę. Idealnie byłoby mieć niewielki "kwadratowy" obszar w okolicach zera, który potem wraca do pierwotnej ch-ki liniowej. Chyba mi się udało ;)
Ciemny niebieski = liniowa,
jasny niebieski = kwadratowa (jak w Arduino),
czerwony = nowa wersja.
(http://i.imgur.com/88VuDkJ.png)
-
A już zupełna rewelacja to płytki do enkoderów. Żadnych problemów
Potwierdzam.
-
Piter. A te krzywe to planujesz już w firmwarze zakodować? Bo nowe symulatory już to mają i np. w dcs wolałbym mieć charakterystykę liniową, a krzywe ustawiałbym sobie w dcs. No chyba, że piszesz o zewnętrznym oprogramowaniu do twojej elektroniki.
-
Planuję w firmware, ale w razie czego będzie opcja ich wyłączenia, albo nawet domyślnie ustawiona będzie ch-ka liniowa. Jestem jak najbardziej otwarty na sugestie.
Zastanawiałem się sporo na koncepcją całości systemu i doszedłem do wniosku, że pakowanie n joysticków w jeden w praktyce nie ma sensu.
Głównym atutem obecnego projektu elektroniki jest procesor z porządnym przetwornikiem A/C. Jego wersje i tak mają wbudowane USB. Rozbijanie systemu na kilka modułów gadających do siebie przez I2C, podczas gdy w każdym i tak byłby natywny USB traci sens. USB jest szybsze i odporniejsze na zakłócenia nawet przy dłuższych kablach.
Dlatego myślę, że końcowa wersja systemu będzie wyglądać tak:
- jeden moduł baza, zawierający 6 wejść analogowych 16bit z przedwzmacniaczami, 16 przycisków i 2x HAT. Wejścia dla enkoderów - jeszcze nie wiem. I tak muszą symulować naciskanie przycisków, więc może bardziej uniwersalnie będzie przewidzieć wejścia tylko dla przycisków. Jak ktoś będzie chciał podłączyć enkodery, to można użyć tych małych adapterów, które jak czytałem, sprawują się w porządku.
- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit. Komunikacja przez I2C z bazą. Ten moduł przeznaczony byłby do umieszczenia w uchwycie, podobnie jak to ma miejsce w Warthogu.
Całość przedstawia się Windowsie jako jeden joystick. Jakąś zworką będzie można przestawić nazwę, tak, żeby identyfikacja kilku zestawów baza+zewnętrzny moduł była bezproblemowa.
Takie zestawy można podłączyć do jakiegoś małego Huba i jednym kablem puścić do PC.
Czego nie chciałbym robić, to tworzyć jakiegoś osobnego softu do ustawiania tryliona opcji. Ma to być w podstawowej wersji urządzenie plug&play. Jeśli trzeba będzie wprowadzić jakieś dodatkowe niewielkie zmiany w firmware, jak np. zmiana krzywej, czy rodzaj przycisku, to będzie można to zrobić przy pomocy małego programu, który, mam nadzieję, uda mi się napisać.
Kalibracja i dopasowanie osi wykonywane będzie ręcznie, śrubokrętem. Windows raczej nie zgubi tych ustawień ;)
-
- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit. Komunikacja przez I2C z bazą. Ten moduł przeznaczony byłby do umieszczenia w uchwycie, podobnie jak to ma miejsce w Warthogu.
Trochę to przypomina koncepcję, którą chcieliśmy zrobić w modzie dla Cougara. W rozwiązaniu elektroniki w drążku Cougara są rejestry równoległo-szeregowe i proste sterowanie zegar oraz sygnał zapis i szeregowy odczyt. I2C to już jest postęp. Enkodery w drążku raczej nie wystąpią, ale HAT-y jak najbardziej.
Chwyt Warthoga na pewno się różni od Cougara mam na myśli tensometry tutaj nie mam wiedzy, może inni się wypowiedzą.
-
Chwyt Warthoga na pewno się różni od Cougara mam na myśli tensometry tutaj nie mam wiedzy, może inni się wypowiedzą.
Chwyty Warthoga i Cougara są identyczne pod względem elektronicznym, dzięki czemu są w pełni kompatybilne pomiędzy obydwoma kontrolerami. Jedyne różnice to bardziej realistyczne wykonanie w Warthogu, inne materiały (HAT-y i reszta nakładek na switche jest wykonana z tworzywa). Dlatego ludzie z viperpits.org wymieniali drążki na te z Warthoga bo są po prostu bardziej wierne oryginałowi (z wyglądu).
(http://www.simhq.com/_technology3/images/technology_174a_006.jpg)
Vito TM Warthog nie jest wyposażony w tensometry tylko w sensor Hall'a, to jest ruchomy drążek.
-
Dzięki za sprostowanie Freeman 13. Chciałbym nawiązać do Twojej wypowiedzi #97 http://il2forum.pl/index.php/topic,15612.90.html
Faktycznie jest problem z kontrolerami do Cougarów. Różnie sobie ludzie z tym radzą nawet u nas na forum mam na myśli przykład macieja. To co proponuje 3.14ter pomoże rozwiązać problem kontrolera, ale nie do końca, ponieważ joysticki się różnią a kontroler ma być uniwersalny. Przykład to Cougar gdzie połączenie kontroler drążek oraz kontroler przepustnica to już rozwiązanie archaiczne. Interfejs I2C rozwiązuje problem, ale wymaga zmian w elektronice drążka oraz przepustnicy. Mając do dyspozycji kontroler Piotra można zaprojektować układy wykonawcze w drążku oraz przepustnicy. Kiedyś Damos próbował zrobić odwrotnie tzn. zaprojektować kontroler do Cougara, ale projekt nie doczekał się realizacji.
Policzyłem ile jest elementów wykonawczych w moim Cougarze. Drążek : 4 hat, 4 przełączniki i 2 trigger (przyciski). Przepustnica 10 przycisków oraz całość ma 7 analogowych osi bez ruddera.
Zaletą projektu Piotra jest jego prostota w porównaniu do projektu MMJoy2, który jest bardzo rozbudowany i za bardzo uniwersalny. Ceną prostoty jest to, że ma ograniczenia np. liczba przycisków. Jeśli wprowadzimy dodatkowe interfejs I2C do podłączenia modułu z rejestrami (przyciski lub enkodery) to mamy problem z konfiguracją.
Reasumując, podoba mnie się koncepcja Piotra, ponieważ jest plug&play i nie potrzeba konfigurować, ale musimy pogodzić się z pewnymi ograniczeniami (liczba przycisków).
-
Dlatego myślę, że końcowa wersja systemu będzie wyglądać tak:
- jeden moduł baza, zawierający 6 wejść analogowych 16bit z przedwzmacniaczami, 16 przycisków i 2x HAT. Wejścia dla enkoderów - jeszcze nie wiem....
- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit....
Czego nie chciałbym robić, to tworzyć jakiegoś osobnego softu do ustawiania tryliona opcji...
Odnośnie ogólnego zarysu systemu: ten przedstawiony bardzo mi odpowiada.
Trochę głupio mi, gdyż marudziłem by w module rozszerzeń znalazły się te dwie osie analogowe. Ponieważ równolegle testuję te pomysły na swoim projekcie to teraz przyznaję że te dodatkowe osie analogowe chyba nie są konieczne, za to ważna jest miniaturyzacja płytki.
Dalej: w modułach absolutnie nie trzeba wejść do enkoderów. Mamy już płytki wielkości enkodera więc to w zupełności wystarczy.
Oprogramowanie: podstawowe się przydaje. I tak sobie pomyślałem że dobrze by było gdyby możliwa była opcja mapowania. Sam muszę u siebie zrobić. Wiadomo że w symulatorze sobie można. Ale po moich testach wiem, że bardziej intuicyjnie jest to zrobić już wcześniej. Bo np mam taką sytuację, że w module głównym podpinam fizycznie np. 11 przycisków drążka, kolejne podpinam do modułu rozszerzeń i w windowsie mam w efekcie: przyciski od 1-11 potem od 17-ileśtam. Czyli taka dziura, bo pozostały niepodpięte wejścia. Tak to jest u mnie - więc ja powinienem zrobić mapowanie programowe. Jak u Pitera?
-
Domyślam się shopik, że masz już u siebie prototyp do testowania modelu to bardzo dobrze. Masz idealną sytuację, ponieważ nie masz ograniczeń związanych z elektroniką w joysticku Ty ją tworzysz projektując od podstaw całość. W trudniejszej sytuacji będą posiadacze starego sprzętu, ale to można rozwiązać.
Jeśli dobrze zrozumiałem to jest płyta główna oraz moduł rozszerzeń komunikujący się po I2C. W rozpatrywanej kiedyś koncepcji modu lub zastąpienia starego kontrolera do Cougara zakładaliśmy, że powstanie płyta główna oraz 2 moduły komunikujące się po I2C. Jeden moduł w drążku (3 rejestry równoległo-szeregowe) oraz moduł w przepustnicy, która w praktyce (F16) jest w odległości 1.5 do 2 m (długość kabla) od drążka (w praktyce od kontrolera). Można także założyć, że mamy 2 niezależne joysticki jeden do obsługi drążka drugi przepustnicy.
Przepraszam, że trochę mieszam, ale patrzę na ten projekt pod kątem jego praktycznego zastosowania. Może Freeman 13 wyrazi swoją opinię, ma dużą wiedzę na ten temat.
-
Cóż, osobiście nie chcę narzucać swojej koncepcji tego typu rozwiązania. Tym bardziej że @3.14ter nie projektuje kontrolera pod konkretny sprzęt, tylko do budowy całego urządzenia od podstaw, choć jedno tak naprawdę nie wyklucza drugiego. Było by idealnie gdyby główny moduł mógł komunikować się po I2C z drążkami Cougara/Warthoga. To dawało by świetną bazę wyjściową do modyfikowania czy budowania od podstaw całej mechaniki drążka z możliwością współpracy z chwytami od w/w kontrolerów. Jeszcze lepiej było by gdyby udało się zostawić oryginalne płytki z rejestrami w tych rękojeściach. Domyślam się że dla wielu ludzi było by problematyczne montowanie nowej płytki wewnątrz chwytu drążka. Więc gdyby kontroler projektowany przez @3.4ter mógł się bez problemu komunikować z rękojeścią Cougara/Warthoga, to wielu z nas tutaj miało by banana na twarzy :) Na razie to tylko marzenia ale wyobrażam sobie taką sytuację że posiadając dla przykładu cały joy Warthoga, używam go w konfiguracji fabrycznej z większością symulatorów. Ale gdy chce polatać tylko F-16 w BMS, odkręcam rękojeść, montuję ją na modzie z tensometrami podłączonym do kontrolera który od razu widzi chwyt drążka i można zacząć zabawę.
Przepustnica to już inna bajka, chociaż też był bym za rozwiązaniem aby była w pełni niezależnym urządzeniem, z własnym kontrolerem.
-
Jeśli dobrze zrozumiałem to jest płyta główna oraz moduł rozszerzeń komunikujący się po I2C.
Przepraszam, że trochę mieszam, ale patrzę na ten projekt pod kątem jego praktycznego zastosowania.
@vito
Co do pierwszego, to tak mam płytkę arduino i ekspandery pinów cyfrowych komunikujących się po I2C.
Co do drugiego: to nie ty mieszasz, tylko ja za dużo napisałem i może nieczytelnie - zgadzam się zupełnie z zaproponowaną przez 3.14ter'a koncepcją systemu.
-
Przejrzałem dokładnie zdjęcie płytki. Płytka jest bardzo czytelna w sensie funkcjonalnym. Testowałem także projekt Piotra zrobiony na Arduino i jestem zadowolony. Ten projekt jest bardziej ambitny dotyczy to analogów. Ponieważ ma być uniwersalny to nie znajdzie zastosowania do wymiany uszkodzonych kontrolerów w istniejących joystickach ale może być bazą do modyfikacji elektroniki w joysticach. Jest idealny gdy projektujemy joystick od podstaw tak jak w przypadku shopiKa.
Zgadzam się z Piotrem, że zbyt dużo możliwości funkcyjnych może doprowadzić do komplikacji tak jak w przypadku MMJoy2, gdzie kontroler mógłby sterować nie tylko joystickiem ale także panelami.
To o czym wspomniał Freeman 13 jest oczywiście do zrobienia. Jest to prosty interfejs sterowania rejestrami równoległo-szeregowymi, ale to już nie jest standard I2C.
To takie moje uzupełnienie tego co napisałem poprzednio.
-
Projekt joysticka ma być również dość uniwersalny. Nie widzię problemu w zastosowaniu go jako zamiennika elektroniki dla Cougara. Zewnętrzny moduł będzie na tyle mały, że da się go zastosować zamiast oryginalnej płytki na CD4021. Ilość kabli do podłączenia będzie ta sama.
Sprawy typu obsługa oryginalnej płytki z rejestrami, czy mapowanie przycisków, o którym wspomniał shopiK zostawiam na później. Jeszcze nie jestem na tym etapie. Zresztą są to sprawy czysto programowe, które można rozwiązać później. Dużą zaletą procesorów serii PSoC, jest to, że są bardzo uniwersalne. Zamiast stałych klocków w przypisanymi na stałe funkcjami, jak interfejsy itd. mają taką kulkę cyfrowej plasteliny, z której ulepić można dowolne peryferia. Piny również można dowolnie podłączać i rekonfigurować z poziomu programu. Na bazie jednej płytki można będzie budować wiele wariantów pod bardziej konkretne zastosowania. Chociaż uważam, że wersja podstawowa załatwi większość z nich.
Moduł zewnętrzny:
w zasadzie już zdecydowałem, że nie bedzie to tylko dodatkowa płytka z rejestrami, czy MCP23017, a funkcję przejmie drugi procesor. Niższej klasy niż ten w płytce bazie, ale również dość swobodnie rekonfigurowalny. Stąd też, nie widzę żadnego problemu z dodaniem np dwóch osi analogowych. Nie będzie może przedwzmacniaczy (się zobaczy jeszcze, wielkość płytki jest decydującym ograniczeniem) i 16 bitów, tylko 11, ale do jakichś pobocznych zadań wystarczy.
Zastanawiam się teraz, czy nie lepiej będzie użyć jednak dwóch "podjoystików", jeden jako baza, drugi jako moduł zewnętrzny. Tym sposobem mogę zwiększyć ilość przycisków w module do np. 32. Załatwi to problem z podmianą oryginalnej elektroniki na CD4021 (22 wejścia, jeśli dobrze pamiętam). Problem mapowania numerów przycisków chyba również sam się rozwiąże, bo obie części będą widziane w systemie jako dwa urządzenia.
Oczywiście przepustnica musiałaby być osobnym urządzniem ze swoją własną płytką bazą. Takie rozwiązanie otwiera dalsze możliwośći robudowy, bo omija ograniczenia DirectX odnosnie ilości przycisków i osi.
-
Zastanawiam się teraz, czy nie lepiej będzie użyć jednak dwóch "podjoystików", jeden jako baza, drugi jako moduł zewnętrzny. Tym sposobem mogę zwiększyć ilość przycisków w module do np. 32. Załatwi to problem z podmianą oryginalnej elektroniki na CD4021 (22 wejścia, jeśli dobrze pamiętam). Problem mapowania numerów przycisków chyba również sam się rozwiąże, bo obie części będą widziane w systemie jako dwa urządzenia.
Ten drugi joystick załatwia sprawę zamiany uszkodzonej płyty kontrolera Cougara. W chwycie joysticka jest płytka z 3 rejestrami CD 4021, która jest połączona z kontrolerem przez connector PS/2 5 stykowy (dane, zegar, sterowanie, GND oraz 5V). Potrzebne są jeszcze 2 analogi dla osi X oraz Y i to wszystko. W chwycie są 4 hat, 4 przełączniki oraz 2 przyciski.
Przepustnica to już inna bajka.
-
Upolowałem Cougara, co prawda jest w pełni sprawny (mam nadzieję), ale i tak dostanie nową elektronikę.
Skoro w module zewnętrznym będzie drugi procesor, to może do komunikacji z bazą zastosuję SPI zamiast I2C. Układ może automatycznie wykrywać podłączony moduł, a jeśli on się nie zgłosi - przyjmować, że jest tam oryginalna płytka z rejestrami 4021 i przestawiać się w odpowiedni, kompatybilny tryb.
Przy okazji, w innym wątku wpadłem na pomysł na sprzętowy konwerter przełączników na impulsy, które można użyć z typowymi wejściami dla przycisków. Jest to dość uniwersalny układ, dzięki izolacji optycznej działający również w matrycach. Może generować osobne "kliknięcia" dla przełączenia hebla w każdą stronę lub, po zwarciu wyjść, jedno dla obu kierunków.
(http://i.imgur.com/10tnAne.png)
-
Jutro lub pojutrze przedstawię dokładnie jak zachowuje się drążek Cougara. Wymontowałem drążek, zrobiłem wtyki do PS/2 zakończone przewodami i podłączę do mojego testera. Nie można zdobyć na rynku gniazd 5 stykowych PS/2 dla Cougara, dlatego domowym sposobem zrobiłem z "jakiegoś" złącza końcówki dla wtyków PS/2. W rozwiązaniu Cougara nie ma standardu I2C, są tylko 3 sygnały : zegar, sygnał zapis/odczyt oraz dane z ostatniego rejestru. Rejestry są połączone szeregowo. Po testach opiszę to dokładniej. Maciej z forum zmienił u siebie ten "stary interfejs" na I2C zmieniając typ rejestrów.
Co do pomysłu z transoptorami to ćwiczyliśmy to zagadnienie w 2009 roku chcąc zwiększyć liczbę enkoderów w MJoy16. Damos zaprojektował oddzielną płytę do której można było podłączyć enkodery. Rozpatrywaliśmy także zastosowanie kluczy analogowych CD4066 w MJoy16, ale ich oporność (mała ale istotna) wykluczała ich zastosowanie w matrycy.
Twój pomysł ciekawy, ale rozwiązanie z płytką z enkoderami nic nie jest w stanie konkurować. Gratuluję zdobycia Cougara, ja mam ale w kokpicie i to ogranicza moje testy.
-
Zrobiłem testy mojego drążka za pomocą testera wykonanego na bazie UNO. Opisałem to tutaj #99 http://il2forum.pl/index.php/topic,15612.new.html#new
Zrobię szkic połączeń hatów oraz przycisków do rejestrów CD4021 na podstawie wykonanych testów. Ponieważ linia danych SDA w I2C jest dwukierunkowa a w starym rozwiązaniu na CD 4021 jest jednokierunkowa to może analizując tę linię można określić czy mamy w drążku starą płytkę z CD 4021 czy nową z MCP 23017. To rozwiązałoby problem kompatybilności z starymi płytkami tak myślę.
-
Jest to schemat połączeń w drążku Cougara. Nie umieściłem rezystorów na wejściach rejestrów (pull-up) aby nie zaciemniać obrazu.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Cougar-sch.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Cougar-sch.jpg.html)
J1-J6 to złącza na płycie do których są doprowadzone sygnały z hatów oraz przełączników. Ozn. L, D, R oraz U to skróty od left, down, right oraz up. Złącze (wtyk) jest połączone z złączem ozn. na diagramach J7. Diagramy połączeń są pod linkiem http://cougar.flyfoxy.com/circuits.php
Sprawdzę jeszcze u siebie na płycie uszkodzony rejestr, może dam radę go wymienić. Okablowanie w drążku Cougara jest trochę dziwnie rozprowadzane, ale może jest to optymalne ze względu na ciasnotę.
-
Super! Dzięki za schemat, na pewno się przyda.
-
Jeszcze jeden przydatny szkic pokazujący jak rozprowadzana jest masa w drążku.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_Cougar-gnd.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_Cougar-gnd.jpg.html)
Jak widać każde złącze 5 stykowe ma wyprowadzoną masę. Dodatkowo stosują przedłużenie masy wykorzystując niektóre przyciski co daje krótsze kable oraz pewną optymalizację okablowania. Diagramy są przydatne, ale mogą być inne kolory lepiej sprawdzać.
U mnie jest uszkodzone wejście pin4 U3 (zwarcie do masy). Ponieważ funkcja S3 dla mnie jest nieistotna (modyfikator) to nie wymieniłem rejestru. Mam nadzieję, że szkic pomoże Piotrowi.
-
Muszę jeszcze wyjaśnić jak powstał schemat ideowy płytki drążka. Nie sprawdzałem omomierzem połączeń z złącz ozn. J1-J6 do hat1-hat4, S1-S4 oraz TG1-TG2 tzn., że schemat ideowy nie powstał na podstawie schematu montażowego. Schemat powstał na podstawie testów wykonanych na hatach oraz przełącznikach oraz obserwacji diod LED w matrycy 8x8 w moim testerze. Położenie w matrycy diod odpowiada dokładnie odpowiedniemu wejściu w 3 rejestrach CD 4021 jest to określone w programie testera. Po wykonaniu schematu sprawdziłem na diagramach czy jest zgodność mojego schematu z diagramami. Jest zgodność złącz J1-J6 oraz rejestrów U1-U3, nie wchodziłem w oznaczenia "solder pin" oraz kolory w diagramach.
-
Jest to schemat funkcjonalny testera. Jak widać pozycja diody w matrycy 8x8 jest funkcjonalnie związana z określonym hat lub przyciskiem oraz określonym wejściem na jednym z rejestrów.
Dla opcji kontrolera kompatybilnego z starą płytą w drążku (3 CD 4021) ten szkic wystarczy do zaprogramowania uP. Dla opcji z ekspanderami trzeba jeszcze określić nr pinów na złączach J1-J6. Ja zapomniałem to zrobić a mam już drążek złożony. Myślę, że nie będzie z tym problemu gdy będzie projekt na tym etapie.
(http://i700.photobucket.com/albums/ww5/vito_zm/m_tester-logika.jpg) (http://s700.photobucket.com/user/vito_zm/media/m_tester-logika.jpg.html)
-
Przyjechały właśnie procesory do modułów zewnętrznych joysticka. Lutowanie ich będzie chyba wyzwaniem (raster 0.4mm) ;)
Dla porównania obok leży MCP23017 w obudowie TSSOP:
(http://i.imgur.com/AXIBEup.jpg)
Wykorzystując maksymalnie wszystkie piny udało mi się upchać:
- 32 przyciski
- 4 osie 11bit
- 2 x HAT
Raczej trzeba będzie sięgnąć po gęściej upakowane złącza, pewnie 2mm zamiast 2.54mm.
vito_zm
Dzięki za schematy, niedługo będę pisał obsługę trybu kompatybilnego z drążkiem Cougara. Przydadzą się na pewno.
-
Obudowa QFN, najlepiej chyba lutować to gorącym powietrzem. Chociaż dużo zależy od tego jak przygotowanym PCB dysponujesz. Jeżeli ścieżki biegnące do układu są dobrze przygotowane i dosyć długie oraz jest do nich dostęp po stronie zewnętrznej układu, to dobry topnik + precyzyjny grot i da się to bez problemu polutować. Grunt to wstępne po-cynowanie pól lutowniczych i nałożenie dobrego topnika, co zapobiegnie zwieraniu ścieżek.
-
Najprawdopodobniej pasta i płytka do pieca, a potem, jeśli potrzeba poprawki z dużą ilością topnika. Do takich rzeczy używam Amtecha NC-559, drogi, ale lutowanie z nim to bajka. Taki kumotr do zadań swoistych ;)
Tymczasem:
- uruchomiłem komunikację między bazą, a płytką zewnętrzną. SPI na 1MHz przy prawie 2 metrowym kablu działa bez zająknięcia. Podejrzewam, że żeby uruchomić szybsze I2C 400kHz na takiej odległości musiałbym zastosować jakieś specjalne drivery. A tak - taniej, szybciej i od razu kompatybnie z drążkiem Cougara.
- Im więcej spędzam czasu z procesorami Cypressa, tym bardziej je lubię. W module zewnętrznym są tylko 4 osie. Popędziłem ADC szybciej i użyłem wbudowanego w niego tricku na nadpróbkowanie. Mamy stabilne 14bit zamiast 11.
A przy okazji ze starego Raspberry Pi B+ i rupieci z szuflady zbudowałem sobie sprzętowy terminal UART, takie PuTTy w kostce:
(http://i.imgur.com/MKV2XEi.jpg)
-
Gratulacje jest szansa na dobry kontroler, powodzenia.
-
Zacząłem od zaprojektowania płytki modułu zewnętrznego, dostał nazwę "Copilot" :)
Wymiarami będzie kompatybilna z płytką w drążku Cougara:
(http://i.imgur.com/9ou9Knt.png)
(http://i.imgur.com/jCUryW9.png)
Procesor posiada wbudowane dwa wzmacniacze operacyjne, wykorzystałem je i dwie z czterech osi dostały uproszczone wzmacniacze - tylko wzmocnienie i regulacja zera.
Pełne SPI + zasilanie to 6 linii, ale na ten czas nie wykorzystuję linii MOSI do komunikacji, więc zadziała również z oryginalnymi wtykami/gniazdami Cougara (5 linii).
STATUS LED informował będzie o prawidłowym połączeniu z bazą i pomoże zdiagnozować ewentualne problemy.
Prototypy już jadą z OSHPark.
Zastanawiam się czy w płytce bazowej nie dodać jakiejś uruchamianej zworką opcji diagnostycznej typu wysyłanie raportu o stanie wszystkich wejść np. przez UART. Chodzi mi głównie o sytuacje, gdy podłączając cały system kokpitu nie bardzo chce nam się latać co chwilę do komputera (albo go nawet nie mamy pod ręką, bo sprzęt jest budowany na warsztacie) i patrzeć, czy podłączony akurat przycisk, przełącznik, czy oś działa, czy numer wejścia jest właściwy itd.
Do UARTa można podpiąć tani moduł bluetooth i podglądać sobie cały system np. na telefonie z aplikacją terminala.
-
Hehe... Już miałem pisać: Proszę o wymiary płytki, ale na szczęście przewinąłem na drugi obrazek :-) To teraz mogę dokończyć projektowanie gripa :-)
-
Z opisu wynika, że moduł Copilot będzie połączony z baza przez 6 pin SPI oraz realizuje 2 HAT, 4 analogi oraz 32 przyciski. Czy do SWD będzie połączony moduł bluetooth do kontroli działania Copilota. Po lewej stronie są 4 piny w ramce czy to jest masa.
-
SWD to wejście programatora, układ oparty jest na mikrokontolerze, który trzeba również zaprogramować. To jedyne wejście o rastrze 2.54mm, bo takie akurat jest wyjście prgramatora. Reszta złącz to raster 2mm.
Moduł UART/Bluetooth do diagnostyki podłączany będzie do złącza UART w płytce bazowej (VCC,GND,TX,RX). Baza odczytuje dane z Copilota i wysyła raport całego systemu, od razu pokazując czy komunikacja działa prawidłowo.
Rząd 5 pinów po lewej to wszystko masa.
-
Dzięki za wyjaśnienia, faktycznie zapomniałem o programowaniu.
-
Lutowanie poszło nawet całkiem nieźle (pasta+topnik w żelu+gorące powietrze):
(http://i.imgur.com/RdzhpxQ.jpg)
(http://i.imgur.com/DH6E83o.jpg)
-
Gratulacje.
-
Pierwsza wersja płytki bazy właśnie przyjechała. Mam nadzieję, że nie strzeliłem jakiegoś błędu. Ma rozmiar 80x100mm i wygląda tak:
(http://i.imgur.com/ZEdt7Br.jpg)
(http://i.imgur.com/7RqwqVO.png)
Gwoli wyjaśnienia, jedna baza może współpracować tylko z jednym modułem zewnętrznym. System modularny typu baza + ileś tam modułów zewnętrznych skomplikowałby sprawę na tyle, że nie wiem ile czasu zajęłoby mi jego zaprojektownie i napisanie całego softu.
Z nowości od odstatniego postu, wpadłem na pomysł, żeby dodać obsługę matrycy przycisków w przepustnicy Cougara (zworka Cougar Throttle). Tym samym możliwe będzie zastąpienie całej elektroniki Cougara jednym zestawem baza+moduł. Z jednym "ale": elektronika nie będzie kompatybilna z programem Target.
Płytkę starałem się zaprojektować w dość uniwersalny sposób. Gniazdo USB jest typu B, to duże i chyba najbardziej trwałe. Z drugiej strony, opcja montażu PCB przy ściance obudowy nie zawsze może być dostępna, dlatego USB dostępne jest też na dodatkowych pinach do których można podłączyć kabel z gniazdem montowanym już w docelowym miejscu.
Opcje zasilania są dwie:
- USB - znajdzie zastosowanie przy budowie joysticków, albo podmianie orygnalnej elektroniki, jak w przypadku Cougara.
- Zewnętrzny zasilacz 7-12VDC - które generalnie i tak bym polecał jeśli jeden dodatkowy kabel nie będzie wielkim problemem. Zasilacz dostarczy o wiele czystsze napięcie niż to podane przez USB z komputera.
Wyboru dokonuje się zworką.
Kolejna drobnostka to małe białe pola obok wejść dla osi i HATów. Można sobie tam mazaczkiem wpisać własne oznaczenia, które ułatwią identyfikację.
I2C wyprowadzone jest na dodatkowym złączu jako furtka dla ewentualnych rozszerzeń.
System ID to zworka, która ustawia nazwę wykrytego urządzenia USB HID - ułatwi identyfikację gdy w systemie będzie kilka urządzeń tego typu.
CoPILOT mode ustawia tryb obsługi modułu zewnętrznego: domyślny, czyli dodatkowy joystick lub oryginalna płytka Cougara z rejestrami 4021.
UART Report to wspomniana wcześniej opcja monitorowania stanu wejść przez UART.
STATUS to LED, który będzie informował o stanie urządzenia. Miał być SMD, ale w końcu zmieniłem go na klasyczny przewlekany - czasem zajdzie potrzeba zamontowania LEDa gdzieś w obudowie w dobrze widocznym miejscu.
BTN to dodatkowy przycisk, który narazie nie pełni żadnej funkcji. Może się przydać w przyszłości.
-
Płyta wygląda imponująco. Na tym etapie nie chcę wchodzić w szczegóły, ponieważ wyjdzie to w praktycznych testach. Chciałbym się odnieść do tego fragmentu:
Tym samym możliwe będzie zastąpienie całej elektroniki Cougara jednym zestawem baza+moduł.
Wiem, że masz Cougara i będzie możliwość jego testu z Twoim projektem. Z tego co pamiętam to faktycznie powinno wystarczyć Hatów oraz osi analogowych. Targetem oraz Foxy nie ma co się przejmować, ponieważ takie było założenie projektu. Musimy zrezygnować z modów, ale nie każdy z tego korzysta.
Na koniec pytanie związane z ID. Z opisu na płytce wynika , że można podłączyć 4 płyty główne A-C zwierając odpowiednie punkty 6 pin (SYSTEM ID).
-
SystemID zmienia tylko nazwę pod jaką urządzenie pojawi się w windows po podłączeniu do USB, np. JoystickA, JoystickB, ...C itd.
Ma to być lekarstwem na jedną z wad joysticków na Arduino - wszystkie pojawiają się pod taką samą nazwą w systemie, co wprowadza zamieszanie przy przypisywaniu osi i przycisków.
-
O matko, jak powiedział Vito - wygląda to imponująco. Po cichu śledzę ten wątek i trzymam kciuki za realizację.
Jedno pytanie: będzie możliwość zamówienia, odpłatnie oczywiście, gotowego polutowanego zestawu, takiego plug&play?
-
Dzięki za wyjaśnienie, faktycznie jeśli jest kilka sterowników to musi być możliwość ich identyfikacji. Tak jest np. w DMKeys8, gdzie można zmieniać ID oraz nazwę.
-
Dla mnie to co robicie to i tak czarna magia :) , ale widzę że robota świetna, pełna profeska.
-
Cały czas czekam na każdą informację o progresie :-) I każdy post mnie cieszy :-)
-
Udało mi się polutować jedną płytkę, jeszcze nie uruchamiałem.
(http://i.imgur.com/QKMAYoi.jpg)
(http://i.imgur.com/Duhw2cW.jpg)
Jeśli wszystko będzie działać w porządku, pozostanie mi "tylko" dopisać resztę softu i dopracować masę szczególików, na które zawsze można liczyć ;)
Przy okazji, gdyby ktoś chciał sobie zbudować wzmacniacze do osi analogowych, to projekt dostępny jest tutaj (https://github.com/hexeguitar/HALLpreamp).
-
Witaj,
Czy udało Ci się rozwiązać jakoś ostatecznie kwestię tego, że wiele kontrolerów na jednym porcie fizycznym USB ma takie same nazwy?
-
Wspominałem o tym kilka postów wcześniej:
http://il2forum.pl/index.php/topic,17912.msg347983.html#msg347983
Czyli maksymalnie podłączyć można 4 (ABCD) zestawy baza+moduł, co w sumie daje 48 wejść analogowych, 256 przycisków i 24 HATy.
-
Tak, widziałem tę wiadomość.
Jednak chodzi mi o to jak to rozwiązujesz programowo.
W konfiguracji urządzenia USB (ja pracuję akurat na STM32) jest tylko jedno pole DEVICE_NAME_STRING czy podobny identyfikator.
Bo wiele urządzeń to bez problemu, zaś moje pytanie dotyczy tego, czy rozwiązałeś problem tego, ze mamy jeden uC i on pokazuje się jako różne pod względem nazwy Joysticki.
-
Mam jeden deskryptor HID dla wszystkich urządzeń. Definiuję 4 osobne urządzenia pod różnymi nazwami (PRODUCT_STRING). Wejścia "System ID" określają, które z 4 urządzeń nawiąże połączenie przez USB po starcie programu. Przełączenie jednej nazwy na drugą wymagać będzie ponownej inicjalizacji USB.
-
Ok, czyli masz sytuację inną niż ja - ja mam deskryptor USB, który definiuje 2 urządzenia jednocześnie.
Myślałem, że w takiej sytuacji znalazłeś rozwiązanie.
https://gitlab.com/piotrva/STM-JOY/blob/master/Firmware/STM-JOY/Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c#L219
To inne pytanie jeszcze mi się nasuwa - piszesz o 48 osiach, czyli po 12 na jedno urządzenie USB. Z tego co jednak bawiłem się na domyślnym windowsowym driverze do joysticków obsługuje on tylko 7 osi (X, Y, Z, xRot, yRot, Rudder, Throttle) + 32 przyciski + 2 x hat switch.
Jak rozwiązujesz tę sytuację? Czy masz gdzieś firmware, który można by podejrzeć?
-
Próbowałem również tej metody, zdefiniowania dwóch urządzeń bezpośrednio w deskryptorze. Ale coś mi to do końca nie działało. Jeśli dobrze pamiętam, to ze względu na sposób działania całego bloku USB i jego API w PSoC.
W PSoC Creator całą konfigurację bloku USB robi sie graficznie, jest to bardzo wygodne. Struktura u mnie wygląda tak:
(http://i.imgur.com/0E6ERyt.png)
Device Descriptor to 4 urządzenia typu joystick HID, przy czym, każde z nich składa się z dwóch interfejsów/endpointów ("Interface descriptor"). Jeden z nich to płytka baza (EndPoint1), drugi to moduł zewnętrzny (EndPoint2). To od razu załatwia ograniczenie liczby osi i przycisków. Są one rodzielone na dwa "podurządzenia".
Deskryptor HID mam jeden dla wszystkich "interfejsów", nawet jeśli moduł zewnętrzny (ten drugi InterfaceDescriptor) w całości go nie wykorzystuje, bo ma mniej osi i HATów. Może się przydać w przyszłości, gdybym budował jakieś bardziej wyspecjalizowane rozwiązania.
W kwestii maksymalnej ilości HATów, zauważyłem, że niektóre symylatory, jak np. DCS rozpoznają ich więcej niż 2, dlatego przewidziałem ich większą ilość.
Ale tak się zastanawiam, że może rozmawiamy o dwóch różnych sprawach.
Mając urządzenie kompozytowe, składające się z dwóch pod-joysticków, widziane ono będzie w systemie jako jeden GameController. Po kliknięciu lub wejściu w ustawienia będzie widać, że składa się z dwóch takich samych podzespołów. Tutaj niestety nie udało mi się uzyskać dwóch różnych nazw, chociaż teoretycznie powinno się udać używając zmiennej "Interface String" (może być typowa tylko dla Cypressa). A może po prostu windows ją ignoruje. DCS obok nazwy wyświetla również cały ten długi numer ID, więc można je rozróżnić. W tej kwestii będę jeszcze coś kombinował.
Natomiast w całej tej sprawie ze zmianą nazwy chodziło mi raczej o sytuację, gdzie mamy kilka taki zestawów baza+moduł i chcemy je jakoś między sobą rozróżnić. Była to bolączka Arduino, mając ich kilka szt. wszystkie widziane były w systemie jako ArduinoLeonardo. Chciałem dodać wygodną opcję zmiany tej nazwy bez potrzeby rekompilacji i wgrywania programu od nowa.
-
Próbowałem również tej metody, zdefiniowania dwóch urządzeń bezpośrednio w deskryptorze. Ale coś mi to do końca nie działało. Jeśli dobrze pamiętam, to ze względu na sposób działania całego bloku USB i jego API w PSoC.
Możesz zobaczyć jak to u mnie wygląda - cała trudność polega na tym, ze trzeba dodać REPORT_ID ( https://gitlab.com/piotrva/STM-JOY/blob/master/Firmware/STM-JOY/Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c#L222 ) i potem wysyłając dane także go używać (wysyła się go wtedy jako pierwszy bajt w HID Report - https://gitlab.com/piotrva/STM-JOY/blob/master/Firmware/STM-JOY/Inc/Joystick.h )
Nie wiem jak to wygląda w PSoC od CY - na razie nie było czasu, aby się nimi pobawić (choć mam kupionego eval boarda).
Ale tak się zastanawiam, że może rozmawiamy o dwóch różnych sprawach.
Mając urządzenie kompozytowe, składające się z dwóch pod-joysticków, widziane ono będzie w systemie jako jeden GameController. Po kliknięciu lub wejściu w ustawienia będzie widać, że składa się z dwóch takich samych podzespołów. Tutaj niestety nie udało mi się uzyskać dwóch różnych nazw, chociaż teoretycznie powinno się udać używając zmiennej "Interface String" (może być typowa tylko dla Cypressa). A może po prostu windows ją ignoruje.
No właśnie o tę kwestię mi chodziło, czy z tym udało Ci się poradzić.
A u mnie z tą zmianą nazwy można poradzić sobie nawet prościej, niż tworząc nowe deskryptory: https://gitlab.com/piotrva/STM-JOY/blob/master/Firmware/STM-JOY/Src/usbd_desc.c#L210
-
Metodę z REPORT_ID przetestowałem z powodzeniem na Arduino. Działało w porządku, oprócz tej kwestii z nazwą.
W przypadku PSoC, końcowo wychodzi na to samo, tylko metoda jest trochę inna. Deskryptor HID mam jeden dla wszystkich opcji. Po prostu definiuję kilka obiektów pod różnymi nazwami, opisanych jednym i tym samym deskryptorem.
Oprócz tego każda z 4 opcji nazw pojawia się pod innym PID.
Tak nawiasem mówiąc, to całkowite usunięcie joysticka z systemu wcale nie jest taką prostą sprawą. Pisząc soft zauważyłem, że joystick pojawiał mi się pod starą nazwą, nawet pomimo zmiany vid&pid.
Okazało się, że windows po wykryciu sprzętu wrzuca pełno różnych wpisów po całym rejestrze. Odinstalowanie urządzenia np. USBDeview to tylko pierwszy krok. Potem trzeba przeszukać cały rejestr pod kątem VID_#### i PID_#### i je pousuwać. W dodatku trzeba to zrobić z użyciem programu PsExec do odpalenia regedit, bo niektórych kluczy nie da się usunąć nawet jako administrator.
Tu jest instrukcja krok po kroku jak to zrobić:
https://forum.pjrc.com/threads/27120-Joystick-calibration-in-windows-7-issues
Może to być źródłem różnych dziwnych zachowań, zwłaszcza jak sukcesywnie testuje się kilka wersji urządzenia.
-
Hmm, ja nie miałem takich problemów u siebie - w sensie jak zmienię nazwę po stronie uC to zmienia się też w systemie po wypięciu urządzenia i ponownym podpięciu.
-
Powoli, ale z uporem maniaka do przodu.
Testowałem dzis połączenie baza<->moduł na docelowych płytkach. SPI@1MHz po 2 metrowym ekranowanym kablu działa stabilnie. Uruchomiłem też raportowanie przez port szeregowy:
(http://i.imgur.com/r1ErE69.jpg)
Pokazuje:
- aktualną wersję firmware,
- stany 32 wejść przycisków i podaje numer ostatnio wciśniętego,
- stany wszystkich 4 HATów,
- 16 bitowe wartości 8 osi analogowych,
- wykrycie modułu zewnętrznego (CoPilota),
- jeśli został wykryty - zestaw jego parametrów w drugiej kolumnie,
- ilość błędów w komunikacji między urządzeniami, jeśli będą się pojawiać, to znaczy, że coś nie do końca hula jak należy.
(http://i.imgur.com/awKb8kw.jpg)
Do złączki UART można podpiąć jeden z tanich modułów Bluetooth/Serial i podglądać status np. na telefonie. Prawdopodonie uprzyjemni kalibrowanie osi i sprawdzanie systemu, gdy płytka będzie zamontowana w jakimś trudno dostępnym miejscu.
(http://i.imgur.com/KXfX4VS.jpg)
-
Niby retro, a to neo :-) Super. Czekam na maila z tematem: gotowe do testów - szykuj kasę :-)
-
Mały update z placu budowy.
Tak wyglądają przebiegi osi analogowych w zmodyfikowanym Cougarze, zasilanie zewnętrzne +9V:
https://www.youtube.com/watch?v=jri23lf5bYM
Uruchomiłem również wykrywanie i współpracę z oryginalną elektroniką drążka w Cougarze. Czasami przy przełączaniu pojawiają się śmieci na wejściach, to tylko wina wiszącego w powietrzu wejścia danych SPI.
https://www.youtube.com/watch?v=qY3kvxx4Ypg
Następny krok to dogadanie się z przepustnicą Cougara, a właściwie wykorzystanie części wejść dla przycisków do skanowania oryginalnej matrycy przycisków w przepustnicy.
-
Po namyśle zdecydowałem jednak, że przepustnica Cougara dostanie swoją zoptymalizowaną elektronikę, dzięki czemu można ją będzie wykorzystać jako osobne urządzenie, a nie tylko w zestawie z joystickiem. Na bazie HEX Controllera wymyśliłem coś takiego:
(http://i.imgur.com/p8I2BD1.png)
To dość sporo uproszczona wersja, za to można dokonać wręcz bezinwazyjnej przeróbki przepustnicy, po prostu z jednej strony podłaczyć oryginalny kabel, a z drugiej USB do płytki CY8CKIT-059.
Z drugiej strony znajduje się złącze goldpin do podpięcia oryginalnej elektroniki, w przypadku, gdy moduł będzie zamontowany wewnątrz przepustnicy.
Naturalnie oprócz obsługi wszytkich osi i przycisków można będzie podłączyć co nieco więcej. Matrycę przycisków rozszerzyłem do 6x6, co daje 36 przycisków (łącznie z oryginalnymi), do tego dochodzą 4 wejścia dla enkoderów (sprzętowe odkłócanie itd.), dwie dodatkowe osie 16bit i kilka furtek na przyszłość w postaci wyprowadzonych magistral I2C, UART i CAN. To ostanie może stać się pomostem do projektu kol. piotrva.
Płytki już jadą.
Równolegle pracuję nad interfejstem użytkownika dla głównego projektu. Powieje trochę czasami DOS lub terminalem Linuxa. Obawiam się, że gdybym zaczął pisać jakiś program na PC do ustawień, projekt jeszcze długo nie uzyskałby statusu gotowego do użycia. Dlatego też w duchu "set & forget" wszelakie ustawienia i konfiguracja dokonywana będzie przy pomocy portu szeregowego, konsoli i poleceń wpisywanych z klawiatury. Krótki film demonstracyjny jak to działa w tej chwili:
https://youtu.be/gAaHJnZVBZk
Do obsługi używam programu Putty. Polecenia są krótkie i intuicyjne oraz w razie czego służą podpowiedzią o składni. Przykładowo do odwrócenia osi numer 1 w joysticku-bazie należy wpisać:
invaxis 0 1 1
gdzie invaxis to polecenie, pierwszy parametr to numer joysticka (0=baza, 1=moduł zewnętrzny), drugi to numer osi (1-8), a trzeci to włączenie (=1) lub wyłączenie (=0) odwrócenia osi.
Jeśli polecenie zostanie wykonane prawidłowo, konsola poinformuje o zmianie parametru. Zmiana zapisana jest w pamięci EEPROM, więc nie zostanie utracona po wyłączeniu zasilania.
Oczywiście poleceń będzie nieco więcej. Np. mapowanie fizycznych numerów przycisków pod inne, opcjonalne włączanie martwej strefy na osiach, reset do ustawień fabrycznych.
-
Serial jest zapewniany przez debugger, czy przez USB mikrokontrolera?
-
Serial w tej chwili mam wyprowadzony na osobnych pinach i podłączony do debuggera (ma UART i I2C -> USB). Docelowo może uruchomię go bezpośrednio przez CDC.
-
Swoją drogą - masz może jakiś dobry, darmowy soft do analizy USB (3.0) pod Windows 7?
-
3.0, dobry i do tego darmowy? Obawiam się, że nie mam...
A tak wygląda sprawdzanie i mapowanie przycisków przy pomocy konsoli:
https://youtu.be/O8aM9ubBwYE
W sumie są jakby dwa ekrany, jeden pokauje wszystkie parametry zbiorczo, a drugi, czyli konsola pozwala na dokonywanie zmian w ustawieniach. Przy czym, żeby ciągle nie skakać pomiędzy obydwoma trybami, konsola jest w stanie wyświetlić np. listę przycisków, do których numerów są przypisane i wskazać na czerwono wielokrotne przypisania, które mogą, ale nie muszą być źródłem konfliktów. Jak się za bardzo namiesza, zawsze można zrobić reset i ustawienia wrócą do fabrycznych.
-
Pytań kilka:
1. Co to za aplikacja testowa po prawej stronie?
2. Jaki tryb terminala emulujesz?
-
1. VKB button tester, jest w paczce z MMJOY2 w katalogu tools.
2. Używam VT100.
-
Niedługo finisz:
(http://i.imgur.com/DmrogJL.jpg)
Uruchomiłem też prostszą wersję od strzała obsługującą przepustnicę Cougara:
(http://i.imgur.com/bTy2pna.jpg)
(http://i.imgur.com/PT3rJ9s.jpg)
To na dole to taki pomocnik okablowania matrycy przycisków, zawiera złącza dla kolumn, rzędów i odpowiednie diody. Każdy taki modulik obsługuje 6 przycisków.
Ponieważ okazało się, że sporo obecnych symulatorów widzi jednak więcej przycisków niż 32, w tej wersji rozszeszyłem maksymalną ilość do 64. 36 to matryca 6x6 (w tym przyciski przepustnicy, jeśli jest używana), 8 to 4 enkodery, a dodatkowe 16 szt. można podłączyć poprzez ekspander IO MCP23017 - będzie wykrywany automatycznie.
-
Czekamy, czekamy!:) :evil: