Wątek: Następca Mjoy (Założenia konstrukcyjne)

[vito_zm]

Bardzo dziękuję za testy.Wynik jest obiecujący tzn.nie ma ograniczeń na jeden kontroler 32 tylko 128.Pozostaje do wyjaśnienia tylko jedna sprawa jak zachowuje się SVMapper gdy mamy podłączone więcej niż 4 kontrolery w tym joysticki.
Tutaj może wystąpić kilka przypadków:
1.Jest ograniczenie do 4 lub do innej liczby kontrolerów.
2.Jeśli jest ograniczenie do 4 kontrolerów w tym joysticki to czy:
a)ograniczenie występuje niezależnie czy mapujemy dany kontroler w SVMapper
b)ograniczenie dotyczy tylko 4 kontrolerów,które są mapowane w SVMapper
Jeśli SVMapper zachowuje się tak jak w punkcie a) to jest to poważne ograniczenia.W moim przypadku będę miał Cougar hotas oraz cougar mfds (2 sztuki) co daje możliwość użycia tylko jednego DMJoya.
Jeśli wystąpi przypadek b) to jestem wygrany ponieważ mogę zastosować do 4 DMJoy.
Uwaga końcowa.
Zawsze można stosować DK i tutaj nie powinno być problemów.

[vito_zm]

Przepraszam,że jeden za drugim post,ale znalazłem na forum viperpits rozwiązanie ewentualnych problemów z większą liczbą kontrolerów.
http://www.viperpits.org/smf/index.php?topic=5501.165
Rebbot przetestował u siebie kilka kontrolerów z programem Xpadder i to mu pracuje.Czyli mamy ewentualnie alternatywę jeśli pojawią się problemy.

[damos]

Widząc takie problemy wydaje się zasadnym oprogramowanie naszej płytki kolejnym wsadem:
układ powinien wysyłać kody klawiatury w odpowiedzi na wciskanie klawiszy. Odpadnie problem z maksymalną liczbą przycisków i konieczność stosowania SVMappera.
Układ powinien być prostszy do zrobienia niż Joy - brak wejść analogowych i konieczności kalibracji. PCB będzie to samo. Co wy na to? IMHO ma sens.

[vito_zm]

układ powinien wysyłać kody klawiatury w odpowiedzi na wciskanie klawiszy

Czy to znaczy,że mamy coś podobnego do programu OC ConfigIOCard.Tutaj małe wyjaśnienie.W OC można opisać działanie układów wykonawczych takich jak przycisk,przełącznik,enkoder,LED.7segLED,serwery itd.albo pisząć skrypt w SIOC albo w wspomnianym programie ConfigIOCard.W tym programie wypełnia się odpowiednie rubryki w tabeli takie jak:nazwa,numer wejścia,zmienna,wartość dla key ON/OFF,typ itp.Ja tego nie stosuję wolę skrypt,ale jest to łatwiejszy sposób opisu.
Wracając do SVMappera to obawiam się,że jest ograniczenie związane z liczbą kontrolerów (max 4).Jak będę miał możliwość to ten problem sprawdzę.Jeśli okaże się,że jest to prawda to w moim przypadku nie będę mógł go stosować ponieważ planuję 5 kontrolerów:Cougar hotas,cougar mfds (2 szt) conajmniej 2 DMJoy.Z kartami OC nie będzie problemu.

[damos]

Czy to znaczy,że mamy coś podobnego do programu OC ConfigIOCard.Tutaj małe wyjaśnienie.W OC można opisać działanie układów wykonawczych takich jak przycisk,przełącznik,enkoder,LED.7segLED,serwery itd.albo pisząć skrypt

Bez  skryptu. Po stronie PC nie było by żadnego specjalizowanego oprogramowania, które uruchamiało by jakieś skrypty. Należało by użyć specjalnego programu do konfiguracji powiedzmy "DMKeys" Gdzie pod każdy przycisk mógłbyś przypisać sekwencję klawiszy, jaka była by wysyłana do PC. Po konfiguracji całość była by zapisywana w pamięci uC. Ten zajął by się resztą  i w odpowiedzi na wciśnięcie/zwolnienie buttona wysyłał by wcześniej ustaloną sekwencję klawiszy.

[vito_zm]

Jest to duże ułatwienie.W zasadzie funkcje SVMappera byłyby wykonywane przez program konfiguracyjny.Myślę,że Twój projekt może stać się hitem.

[vito_zm]

Wracając do SVMappera to obawiam się,że jest ograniczenie związane z liczbą kontrolerów (max 4).Jak będę miał możliwość to ten problem sprawdzę.Jeśli okaże się,że jest to prawda to w moim przypadku nie będę mógł go stosować ponieważ planuję 5 kontrolerów:Cougar hotas,cougar mfds (2 szt) co najmniej 2 DMJoy.Z kartami OC nie będzie problemu.

Już to sprawdziłem.Niestety jest ograniczenie SVMapper do 4 kontrolerów.W moim przypadku mogę tylko liczyć na Damosa,że jego pomysł jest możliwy do realizacji.

[damos]

mogę tylko liczyć na Damosa,że jego pomysł jest możliwy do realizacji.

Jest możliwy. Powinien być nawet prostszy (pod pewnymi względami) do zrobienia od Joysticka. Na razie jednak pracuje nad stroną PC (aplikacja do konfiguracji) gdzie Windows skutecznie utrudnia działanie. na przykład poprzez normalne API nie ma dostępu do raportów kontrolnych HID typu VENDOR, czego używałem. Alternatywą jest stosowanie zewnętrznego sterownika instalowanego w systemie (libusb w trybie filter driver) czego wolał bym uniknąć a i sami twórcy nie zalecają, ponieważ na niektórych maszynach (Windows) może spowodować utratę dostępu do wszystkich urządzeń USB. Na linuxie wszystko działa. Pod windows muszę kombinować z wchodzeniem do garażu przez komin i wyjeżdżaniem przez okno

Drugi problem to chwilowy brak dostępności uC ATMega32U4. Nikt ich nie ma, dostawy planowane na październik Z drugiej strony - do tego czasu może skończę soft i będzie OK

[vito_zm]

Na razie jednak pracuje nad stroną PC (aplikacja do konfiguracji) gdzie Windows skutecznie utrudnia działanie

Nie znam się na tym.Tak z ciekawości,czy to jest związane z sterownikiem?Mam na myśli rozwiązania OC,gdzie są pliki konfiguracyjne,które trzeba uzupełniać.Pliki te są związane z poszczególnymi kartami (sterownikami).Jest też możliwość uzupełnienia pliku konfiguracyjnego obejmującego wszystkie karty.

Jest możliwy. Powinien być nawet prostszy (pod pewnymi względami) do zrobienia od Joysticka.

To mnie cieszy.Okazało się,że na viperpits mieli rację z SVMapper.Generalnie unikają tzw.Direct-x.Już o to pytałem (częściowo),ale czy jest możliwość wyboru albo Direct-x albo inna opcja?

[damos]

Nie znam się na tym.Tak z ciekawości,czy to jest związane z sterownikiem?Mam na myśli rozwiązania OC,gdzie są pliki konfiguracyjne,które trzeba uzupełniać.

I tak i nie. W przypadku Joysticka nie mogę stosować własnego, uniwersalnego sterownika - musi być to wbudowany w Windows sterownik do urządzeń HID. Sterowniki kojarzy się z urządzeniem za pomocą pliku inf. W nim opisuje się do jakiej pary VID-PID system ma załadować jaki sterownik. W przypadku braku takiego pliku system sam "odgaduje" jaki sterownik załadować. Odgaduje to po krótkiej "rozmowie" z urządzeniem. Dla Joysticka jest to sterownik do urządzeń HID. Tak więc mamy opcje:

• wbudowany w system uniwersalny sterownik
• własny, prosty sterownik (nie widziany dla systemu jako HID)
• własny sterownik VxD rejestrujący urządzenie HID w systemie i realizujacy wszystko to, co wbudowany sterownik HID
• uniwersalny driver LibUSB w trybie "filter driver" (wymaga osobnej instalacji)

Opcja trzecia odpada ze względu na złożoność (napisanie VxD to kupa roboty, cały zespół Saiteka walczył ze sterownikami 64 bit do X52 około roku) i konieczność instalacji sterownika po każdej zmianie VID lub PID

Opcja druga odpada ze względu na to, iż urządzenie nie będzie widoczne dla gry jako Joystick

Opcja czwarta jest kusząca i z niej dotąd korzystałem: sprzęt jest widoczny jako HID, a ja mam do niego pełen dostęp poprzez USB. Wszystko chodziło mi bez problemu. Jednak niedawno dowiedziałem się, że ludzie, którzy stworzyli LibUSB gorąco odradzają używanie trybu "filter driver" u użytkownika końcowego. Podobno potrafi on czasem odciąć dostęp do magistrali USB (w wyniku wewnętrznego błędu) i ktoś, kto ma klawiaturę USB straci możliwość kontroli PC-ta (a raczej swojego "Windowsa"). Po restarcie nadal nie będzie mieć klawiatury, a nie każdy potrafi uruchomić system w trybie awaryjnym i wyładować wskazany sterownik.

jak widać - opcja pierwsza jest jedyną akceptowalną:
- sprzęt jest widoczny jako Joystick
  - brak konieczności instalowanie dodatkowych sterowników
- można niemal dowolnie zmieniać VID/PID (byle nie trafić na kombinację przypisaną już do jakiegoś urządzenia)

Jednak zastosowanie wariantu 1 zmusza do porozumiewania się z urządzeniem przez mocno obcięte API, które akurat nie ma zaimplementowanej obsługi komend przewidzianych standardem (USB VENDOR specific control transfer), których używam do konfiguracji urządzenia (konfigurowanie gdzie są przyciski, osie analogowe, jaki VID, PID). Teraz kombunuję, jak przerobić swój firmware aby "wcisnąć" go w windowsa. Na Linuxie - jak pisałem, nie ma tego problemu. Może to jest jeden z powodów - dlaczego nie ma jeszcze takiego (konfigurowalnego) zastępnika dla MJoy'a ?

Okazało się,że na viperpits mieli rację z SVMapper.Generalnie unikają tzw.Direct-x.Już o to pytałem (częściowo),ale czy jest możliwość wyboru albo Direct-x albo inna opcja?

To wybiera już sama gra. Dla urządzeń, które nie muszą być widoczne w systemie jako standardowe (zwykłe I/O a nie joy) nie korzysta się z Direct-X.

[vito_zm]

Dzięki za tak obszerne wyjaśnienia.Mam takie skojarzenia,że Cougar Hotas jest widziany w menedżer urządzeń jako USB interfejsu HID.Natomiast sterowniki OC być może są z opcji 2 tzn.własny, prosty sterownik (nie widziany dla systemu jako HID)
Życzę powodzenia i mam nadzieję,że dasz radę rozwiązać problemy.

[damos]

Mam takie skojarzenia,że Cougar Hotas jest widziany w menedżer urządzeń jako USB interfejsu HID.

Tak. Najprawdopodobniej ma sterownik VxD, który umożliwia mu stworzenie dowolnej ilości wirtualnych urządzeń będących wewnątrz Cougara. W ten sam sposób może meldować się jako HID. To jest już skomplikowany model interakcji wymagający wielu testów. Sterownik pracuje na Ring0 i jest najczęstszą przyczyną blue-screenów.

Natomiast sterowniki OC być może są z opcji 2 tzn.własny, prosty sterownik (nie widziany dla systemu jako HID)

Dokładnie tak. Tak też działa moja wersja I/O - korzystając równiez z lib-usb ale "device mode" a nie " filter mode". Niedawno sterowniki lib-usb device mode uzyskały certyfikat z Micro$oftu więc można je bezpiecznie instalować i użytkować.

Życzę powodzenia i mam nadzieję,że dasz radę rozwiązać problemy.

Oczywiście - jak tylko znajdę trochę czasu Wyjściem awaryjnym jest "filter mode" (który u mnie i u Ciebie działa bez problemów) właczany tylko na czas rekonfiguracji urządzenia.

[vito_zm]

Potwierdzenie słuszności naszych założeń.
http://www.viperpits.org/smf/index.php?topic=5998.0;topicseen
Dobrze,że jest możliwość zmiany nazwy oraz ID.Dziwię się,BU0836x nie ma takiej możliwości,chociaż jest w wątku uwaga,że można indywidualnie zamówić kartę z inna nazwą (nie jestem pewien czy dobrze zrozumiałem).

[vito_zm]

Powalczyłem dzisiaj trochę z zmianą vendor oraz ID produktu w MJoy.Chciałem osiągnąć w liście kontrolerów gier następującą kolejność:Cougar hotas,MJoy 16,MJoy 17,MFD 1,MFD 2.To się nie udało.Jeśli nr vendora jest poniżej 00 05 to MJoy jest przed Cougar,jeśli jest 00 05 to poniżej hotas.Chciałem rozdzielić Cougar od MFD,ale się nie udało.Próbowałem jeszcze z ID produktu,ale bez powodzenia.
Po co to robiłem?Gdybym ułożył kolejność tak jak założyłem to mógłbym stosować nadal SVMapper dla 2 MJoy.W moim przypadku mogę tylko zastosować jeden MJoy.
Dobrze,że w projekcie Damosa nie będzie tego problemu.

[vito_zm]

Projektując założenia do elektroniki pod full kokpit przewiduję zastosowanie projektu Damosa DSMjoy.Po pozytywnych testach SimOUT zastanawiam się czy Zajac nie powinien pomyśleć o zrobieniu matrycy dla DSMjoy podobnie jak zrobił pcb dla SimOUT.Co o tym myślicie?Czy jest za wcześnie na taki projekt.