Wątek: Joystick USB - wersja profi

[piotrva]

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?

[3.14ter]

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.

[piotrva]

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.

[3.14ter]

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.

[piotrva]

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ć?

[3.14ter]

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:



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.

[piotrva]

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

[3.14ter]

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.

[piotrva]

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.

[3.14ter]

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:



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.

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.

[shopiK]

Niby retro, a to neo Super. Czekam na maila z tematem: gotowe do testów - szykuj kasę

[3.14ter]

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.

[3.14ter]

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:



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ć:

Kod: [Zaznacz]

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.

[piotrva]

Serial jest zapewniany przez debugger, czy przez USB mikrokontrolera?

[3.14ter]

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.