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

[vito_zm]

To jest dobra wiadomość. Rozwinę ten temat w swoim wątku, ponieważ jest on związany z BMS4 oraz hardware i softem z nim związanym w powiązaniu z fizycznym kokpitem. Myślę, że temat może być interesujący dla macieja oraz drejku oraz innych zainteresowanych budową kokpitów.

[damos]

W związku z ostatnimi pracami mam do was kilka pytań.
Na prośbę Marcina_B zająłem się w ten weekend problemem z Windows 10 i sprawa okazuje się nieco bardziej złożona:
1) ludzie od LibUSB mają problem z Win10 i zupełnie odradzają korzystania z "Filtered Mode", jak to było dotychczas
2) brak filtered mode uniemożliwia pod Windows bezpośredni kontakt z urządzeniem, ponieważ takie device'y jak mysz lub klawiatura są otwierane przez System Operacyjny w trybie wyłączności

Z tych powodów niemożliwe jest skomunikowanie się z hardwarem tak, jak to było dotychczas robione - pozostają mi dwie drogi:
a) utrzymać widoczność urządzenia jako klawiatury i dodać do niego drugie "virtualne" urządzenie do komunikacji i programowania (powinno zadziałać pod Windows, ale spożytkuje więcej zasobów więc możliwa, maksymalna konfiguracja urządzenia będzie mniejsza (krótsze sekwencje klawiszy, mniej urządzeń itp))
b) porzucić "udawanie" klawiatury przez urządzenie i stworzyć dedykowany software, który będzie się komunikował z płytką i sam generował sekwencje klawiszy w odpowiedzi na użycia fizycznych urządzeń. Wtedy będzie można definiować długie sekwencje, opóźnienia między przyciskami itp
c) przejść na inny microchip, który łatwiej udźwignie dwa urządzenia w jednym - ale wtedy posiadany aktualnie hardware będzie mniej rozwojowy

opcja A):
za:
- utrzymanie uniwersalnego interface'u klawiatury
- utrzymanie tego samego wyglądu aplikacji do konfiguracji
- brak konieczności uruchamiania dedykowanego oprogramowania na PC
przeciw:
- zmniejszy się maksymalna wielkość danych konfigurujących urządzenie (jak bardzo - nie wiadomo)
- każda płytka będzie widziana jako dwa osobne urządzenia: jedno to klawiatura a drugie to urządzenie do jej konfiguracji
- nadal nie można będzie wstawiać opóźnień między klawiszami ani tworzyć sekwencji z jednym klawiszem wciśniętym i kilkoma zwalnianymi i wciskanymi
- bardziej skomplikowany firmware

opcja b)
za:
- można będzie wstawiać opóźnienia między klawiszami, tworzyć sekwencji z jednym klawiszem wciśniętym i kilkoma zwalnianymi i wciskanymi
- ilość zaprogramowanych sekwencji będzie niemal nieograniczona
- uproszczenie firmware
- możliwość software'owego wstępnego ustawiania stanu przycisków/przełączników
przeciw:
- dodatkowy software po stronie PC, który będzie musiał być uruchomiony aby połączyć się z płytką i aby sekwencje klawiszy były generowane
- ryzyko konieczności tworzenia w/w software wraz z kolejnymi wersjami Windows
- zapewne nieco zmieniony software do konfiguracji

opcja c)
za:
- większe możliwości w nowym hardware
- lepsze (?) ADC w nowym hardware (12 bit)
przeciw:
- stary hardware pozostanie z aktualnym software
- stack firmware robiony "na nowo"
- software po stronie PC też pewnie ulegnie zmianie



Rozsądek podpowiada wariant A,  ambicja wariant B, ciekawość wariant C.

Nie wiem, jak bardzo istotne są dla Was długie i skomplikowane sekwencje klawiszy?

[vito_zm]

Nie wiem, jak bardzo istotne są dla Was długie i skomplikowane sekwencje klawiszy?

Nie są istotne.
Z mojego punktu widzenia istotne jest czy DMKeys8 pracuje poprawnie pod Win8.2. Na forum BMS4 panuje przekonanie, że Win10 ale za jakiś czas, są z nim w tym symulatorze sterowanym fizycznym kokpitem pewne problemy.
Ci którzy mieli do czynienia z innymi sterownikami oraz softem np. SIOC OpenCockpit czy SimOut wiedzą jaką zaletą jest obecne rozwiązanie Damosa. Jest to nawet prostsze od MJoy z SVMapper.
Zdaję sobie sprawę ile czasu potrzeba na zrobienie wariantu A, B lub C. Jeśli DMKeys8 pracuje pod Win8.2 to można założyć, że obecna wersja DMKeys8  może być jeszcze atrakcyjna przez co najmniej 1 rok lub dłużej.
Jeśli masz czas i możliwości to wybierz takę wersję, która jest dla Ciebie do zrobienia w  jakimś realnym terminie. To jest moje zdanie, ale koledzy mogą mieć inne.

[damos]

Z mojego punktu widzenia istotne jest czy DMKeys8 pracuje poprawnie pod Win8.2.

DMKyes8 po skonfigurowaniu pracuje poprawnie pod każdym systemem operacyjnym: od Windows 98 przez MacOS, Unix, Linux po OS/2.
Jedynie zmiana konfiguracji wymaga podłączenia maszyny w WinXP <-> Win7 z zainstalowanym LibUSB

[vito_zm]

W sumie to nie jest to aż taki duży problem, zawsze ktoś z znajomych może mieć jeszcze Win7 (ja mam WinXP). Można tak jak wspomniałem pomyśleć o wersji A, B lub C, ale w jakimś realnym terminie. Tutaj Ty znasz najlepiej swoje możliwości. Faktycznie za 1-2 lata będzie tylko Win8 lub Win10, czyli trzeba coś zrobić.

[vito_zm]

Jeszcze raz przeczytałem to co napisałeś. Jeśli dobrze rozumiem to możemy konfigurować w obecnej chwili w WinXP oraz Win7. Jeśli powstanie opcja A lub B to stare zaprogramowane DMKeys8 można będzie ponownie przeprogramować w nowym soft konfiguracyjnym w Win 8.2 lub Win 10. W opcji C stare DMKeys8 można przeprogramować tylko w WinXP lub Win 7. Z tego wynika, że wygodniejszy jest wariant A lub B dla tych, którzy już mają DMKeys8. Jeśli chodzi o opcje A lub B to wybór zależy od Twoich możliwości czasowych. Z tego co wiem to Maciej z forum chce zakupić DMKeys8 a pracuje na Win 8.2, czyli musiałby konfigurować na innym pc z WinXP lub Win 7. Dobrze, że ta sprawa została zauważona. Pojawiły się także problemy u Macieja z platformą HSC Codeking w Win 8.2.

[sznink]

A jak w kwestii wyboru jednej z tych trzech oopcji ma się sprawa DMJoy (w sensie terminu jego wydania)? Bo pewnie oprócz mnie znalazłoby się pewnie kilka osób zainteresowanych tym rozwiązaniem (tutaj 12-bitowa rozdzielczość osi jest szczególnie interesująca).

A tak mi jeszcze przyszło do głowy - czy jest szansa, że oprogramowanie konfiguracyjne ruszy na wine po Linuxem. Bo jeżeli tak, to kilka rozwiązań włącznie z mini dystrybucją na maszynie wirtualnej mogłoby załatwić problem systemu operacyjnego.

[Marcin_B]

W sumie to nie jest to aż taki duży problem, zawsze ktoś z znajomych może mieć jeszcze Win7 (ja mam WinXP). Można tak jak wspomniałem pomyśleć o wersji A, B lub C, ale w jakimś realnym terminie. Tutaj Ty znasz najlepiej swoje możliwości. Faktycznie za 1-2 lata będzie tylko Win8 lub Win10, czyli trzeba coś zrobić.

Też się pod tym podpisuję. Płytki DMK8 programuję za pomocą lapka z XP-kiem. Oczywiście byłoby wygodniej móc robic to z poziomu W10 ale tragedii nie ma. Damos - wybierz rozwiązanie najbardziej optymalne wg Swojej wiedzy.

[damos]

A jak w kwestii wyboru jednej z tych trzech oopcji ma się sprawa DMJoy (w sensie terminu jego wydania)?

Tu DMKeys8 powinno być swego rodzaju "rozgrzewką". Po długim czasie, kiedy nie miałem szans na zajęcie się Joyem - chcę wrócić i dokończyć.  Dlatego zapewne wybiorę wariant A. Taki sam model rekonfiguracji otrzyma DMJoy. Joy już działa - trzeba tylko dorobić mu oprogramowanie konfigurujące. Chyba, że zdecydujemy, iż nie jest konieczne rekonfigurowanie Joy'a - wtedy temat jest niemal zakończony.
Jeśli chodzi o konfiguracje - były plany dotyczące wbudowanego zerowania, trymerów, mapowania pinów na konkretne przyciski Joy'a itp.

A tak mi jeszcze przyszło do głowy - czy jest szansa, że oprogramowanie konfiguracyjne ruszy na wine po Linuxem.

Planowane jest natywne uruchamianie softu konfiguracyjnego pod Linuxem (Debian/Ubuntu), bez konieczności stosowania Wine'a. Soft korzysta z bibliotek QT a komunikacja posiada warstwę abstrakcji względem USB, więc - żadnych emulatorów.

[damos]

Wariant A przeszedł właśnie fazę "Proof Of Concept" i potwierdził wykonalność tej idei  
W ciągu około tygodnia powinienem mieć nową wersję Firmware i Software, które będą działać na wszystkich systemach Windows (od XP do 10) bez konieczności instalowania dodatkowych bibliotek. Tu liczę na pomoc kogoś w testowaniu na nowych OS'ach

Przejście tej ścieżki otworzyło pewne nowe możliwości przed DMJoy8. Mianowicie:
1) Układ ma 12 osi analogowych a Windows jest w stanie obsłużyć jedynie 8. Pozostałe 4 są "marnotrawione". Początkowo planowałem:
 1a: z tamtych 4 osi zrobić wewnętrzne trymery obsługiwane hardware'owo - za pomocą dodatkowych, fizycznych potencjometrów.
 Jednak teraz można zrobić coś innego:
 1b: Urządzenie będzie pracować (będzie widoczne dla systemu operacyjnego) jak dwa Joysticki: Jeden z 8-ma osiami analogowymi a drugi z 4-ma. Dodatkowo, do tych 4-ch osi analogowych Joysticka2 można dodać emulowane osie analogowe, sterowane np. hatem lub osobnymi przyciskami: wciśnięcie będzie powodowało przesunięcie osi w jedną lub w druga stronę a jeszcze inny przycisk będzie powodował wyzerowanie. Może być to pomocne w sterowaniu kierunkiem omiatania wiązką radarową lub wskazywaniem celu (sterowana klawiszami oś idealnie utrzymuje zadaną wartość bez konieczności trzymania dodatkowego drążka) Który wariant jest bardziej interesujący 1a czy 1b? A może oba?

2) Do DMJoy8 można dodać emulację myszy - wtedy za pomocą HAT'a będzie się dało poruszać wskaźnikiem myszki. Feature wart uwagi?

[vito_zm]

Dla mnie wariant 1b jest interesujący podobnie jak emulacja myszy, chociaż 1a jest też przydatny. Wszystko zależy od Twoich możliwości czasowych realizacji tych pomysłów.

[sznink]

Dla mnie również 1b jest bardzo przydatne (u mnie będzie dużo osi). Jeśli chodzi o myszkę, to ja chyba wolę używać tradycyjnej myszy lub trackballa.

[Yossarian]

Mi też opcja 1b bardziej się podoba. 

[BOCZEK]

Czołem,

Jeśli można się dosiąść ja bym się pisał na ver 1b. I to w kilku egzemplarzach .

[damos]

Ok, w takim razie wersja 1b.
Obecnie pracuję nad wersją A dla DMkeys8.
Zaraz po niej będzie pierwsza wersja DMJoy8 bez myszy.