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

[vito_zm]

Dzięki za wyjaśnienia.Wspomniałem o kompresji dla przetwarzania A/C,ponieważ jest to normalna praktyka przy transmisji mowy lub muzyki.Po odbiorze jest proces odwrotny czyli dekompresja w dekoderach C/A.Wszystko po to aby zmniejszyć przesyłane pasmo oraz polepszyć stosunek sygnał szum kwantyzacji.U nas jest tylko proces kodowania A/C nie ma C/A.Normalnie robi się kompresję aproksymując krzywą logarytmiczną (13 segmentów).Pytałem z ciekawości,ponieważ wydaje się,że stick byłby bardziej czuły na małe siły.Pytanie czy jest to normale.
Co do kodeków to są to przetworniki symetryczne wzg.GND zasilane +V oraz -V. Pytanie czy można przesunąć środek (GND) tak aby był niesymetryczny jedno napięcie zasilania a jednocześnie poprawnie kodował.

[vito_zm]

Po konsultacjach z Damosem na temat nowego MJoya postanowiłem napisać swoje "życzenia" związane z następcą starego.Ponieważ Damos włączył się do projektu to mam pewność,że zostanie zrealizowany na wysokim poziomie technologicznym.Tyle wstępu a teraz moje uwagi.
1.Jeśli sterownik będzie widziany jako kontroler gier to powinien mieć możliwość ustawiania ID w konfiguracji,jeśli nie to nie ma takiej potrzeby.Ja musiałem zmieniać w MJoyu ID ze względu na konflikt z Cougarem.Pisałem o tym na forum.
2.Problem kłopotów z USB myślę,że już został rozwiązany przez Damosa.
3.Dobrze byłoby mieć możliwość elastycznego definiowania wejść jako pushbuttons,toggle switches lub enkoder.O innych definicjach wejść nie piszę ponieważ nie było o tym jeszcze mowy w tym wątku.Tak jest zrobione w rozwiązaniu Master OC.
4.Dobrze byłoby zwiększyć liczbę wejść.
5.Na temat wejść analogowych nie wypowiadam się,ponieważ wykorzystuję u siebie tylko jedno jako ster kierunku.
6.Dobrze byłoby mieć możliwość sterowania zewnętrznego kodeka np.12-16 bit porzez standardowy interfejs.Jest to związane z innym projektem sticka na tensometrach.
7.Dobrze byłoby zrobić sterownik w ten sposób aby matryca była na innej płycie.Ja tak zrobiłem wszystkie moje MJoye tzn.wyprowadzałem kolumny oraz wiersze a matrycę rozproszoną realizowałem na zewnętrznych kartach w zależności od potrzeb.Nawet kartę Master z OC też w ten sposób zaprojektowałem.
8.Uzupełnienie do punktu 7.W MJoyu matryca jest zrobiona z 8 kolumn oraz 14 wierszy co daje 112 pozycji.W Master zrobiono podobnie tzn.9 kolumn oraz 8 wierszy co daje 72 pozycje.U nas przydaloby się trochę więcej wejść np.256.
Jeszcze jedna sprawa związana z MJoyem.To wystąpiło u mnie.Robiłem testy z kontrolerami.Podłączałem Cougara,Logitech oraz 3 MJoye i mój pc w pewnych sytuacjach przekłamywał.Jeśli zmniejszyłem liczę MJoy do 2 to jest o.k.Nie wiem na czym to polega,ale mam tylko u siebie na jednym pc 2 MJoye,Cougar oraz inne sterowniki z OC,które nie są kontrolerami gier.
W nowym projekcie przewiduję jako wejścia nowe MJoye co najmniej 2.Ma to pewne zalety tzn.dekompozycja (mniejsza liczba przewodów itp.)
Na koniec pytanie o soft.MJoy ma obecnie SVMapper,dla Master pisze się skrypty w SIOC (nie tyko).Dobrze byłoby stworzyć przyjazny sposób konfigurowania wejść.Wspomniałem o OC,ponieważ oprócz SIOC mają prosty sposób konfiguracji można to sprawdzić na ich stronie (ja tego nie stosuję).
To są moje uwagi na gorąco,jeśli coś pominąłem to napiszę później.

[damos]

1.Jeśli sterownik będzie widziany jako kontroler gier to powinien mieć możliwość ustawiania ID w konfiguracji,jeśli nie to nie ma takiej potrzeby.Ja musiałem zmieniać w MJoyu ID ze względu na konflikt z Cougarem.Pisałem o tym na forum.

Jakaś customizacja i tak będzie potrzebna - żeby można było wprowadzić własną nazwę typu "panel1" albo "panel2" - i ona była by widoczna dla użytkownika.

4.Dobrze byłoby zwiększyć liczbę wejść. [...] W MJoyu matryca jest zrobiona z 8 kolumn oraz 14 wierszy co daje 112 pozycji.W Master zrobiono podobnie tzn.9 kolumn oraz 8 wierszy co daje 72 pozycje.U nas przydaloby się trochę więcej wejść np.256.

Zrobiłem na 180 przycisków, ale SVmapper widzi tylko 128. Nie wiem, czy to nie jest ograniczenie sterownika (Direct Input) Joysticka HID dla Windows? We wcześniejszych wersjach DInput było ograniczenie na 32 przyciski.

6.Dobrze byłoby mieć możliwość sterowania zewnętrznego kodeka np.12-16 bit porzez standardowy interfejs.Jest to związane z innym projektem sticka na tensometrach.

Sundowner planuje użycie zewnętrznego ADC, prawdopodobnie po I2C. Liczę na to, że Yano i Sundowner "rozpracują" tensometry, czujniki Halla i zewnętrzne ADC :banan
BTW - kodek to układ pary koder-dekoder (CODEC = COderDECoder). Może lepiej będzie używać pojęcia "przetwornik AC"? Pozwoli to uniknąć później nieporozumień z kodekami Audio-Video tak dziś popularnymi

Jeszcze jedna sprawa związana z MJoyem.To wystąpiło u mnie.Robiłem testy z kontrolerami.Podłączałem Cougara,Logitech oraz 3 MJoye i mój pc w pewnych sytuacjach przekłamywał.

Na czym polegały "przekłamywania" ? Nie widział urządzeń, pokazywał złe przyciski czy złe wartości osi? To brzmi niepokojąco.

Dobrze byłoby zrobić sterownik w ten sposób aby matryca była na innej płycie.Ja tak zrobiłem wszystkie moje MJoye

Sundowner mówił o tym samym. Ja też chcę zrobić bazową płytkę jak najbardziej uniwersalną i nie dedykowaną jednemu rozwiązaniu.

Na koniec pytanie o soft.MJoy ma obecnie SVMapper

SVMapper jest nie tylko dla MJoya, ale dla każdego Joysticka USB HID. Z "moim" rozwiązaniem też pracuje. Obecnie używam SVMappera jako... testowego wyświetlacza pokazującego za pomocą stanu przycisków informacje, "co się dzieje" w środku uC

dla Master pisze się skrypty w SIOC (nie tyko).

Niezłą platformę skryptową zrobił Codeking - nie można by jej wykorzystać?

Dobrze byłoby stworzyć przyjazny sposób konfigurowania wejść.

Planuję prostą aplikację, która umożliwi konfigurację za pomocą "wyklikania" myszką.

[vito_zm]

Na czym polegały "przekłamywania" ? Nie widział urządzeń, pokazywał złe przyciski czy złe wartości osi? To brzmi niepokojąco

O ile sobie przypominam (było to bardzo dawno temu) to miałem problemy z hatem Cougara z widokami.Było to związane z dużą liczbą kontrolerów w tym 3 MJoy-e.Nie badałem tego problemu,ponieważ doszedłem do wniosku,że 2 MJoye wystarczą.
Co do ID to Cougar musiał być na pierwszej pozycji kontrolerów gier,jeśli nie to też były problemy z niektórymi jego funkcjami.Ponieważ jestem praktykiem to znalazłem rozwiązanie problemu nie wchodząc dlaczego tak się dzieje.Po za tym nie znam się na tych problemach.

BTW - kodek to układ pary koder-dekoder (CODEC = COderDECoder). Może lepiej będzie używać pojęcia "przetwornik AC"? Pozwoli to uniknąć później nieporozumień z kodekami Audio-Video tak dziś popularnym

Jest dokładnie tak jak piszesz,będzie przetwornik AC.

Niezłą platformę skryptową zrobił Codeking - nie można by jej wykorzystać?

To byłoby idealne rozwiązanie.

[yano]

Właśnie sobie uświadomiłem oczywistą oczywistość. O ile mnie umysł nie myli to potencjometr w joyu, gdy ten jest bez wychyleń, jest w pozycji środkowej. Wychylenie w którąś stronę zmienia napięcia na "+" lub "-" od tej wartości. Analogicznie, nie mogę zastosować zrównoważonego mostka pomiarowego w pozycji neutralnej. Musi być gdzieś w połowie. Jednym słowem element pomiarowy musi już być odkształcony (ja wiem że to dla wszystkich może być oczywiste, ale jak sobie to napiszę, to oczywistym stanie się również dla mnie).
Jeżeli ma to być projekt "samoróbka" dla każdego, to problemem może być powtarzalność elementów. Ja sobie zrobię "tak", z taką dokładnością, ale obywatel X zastosuje inną stal na czujnik i wartości odkształceń, a co za tym idzie zmiany napięcia będą inne. Czy standardowa kalibracja sobie z tym poradzi? Chciałbym uzyskać efekt Plug and Pray, coby po podłączeniu i chwili na modlitwę wszystko działało.
Coś mnie wątpliwości dopadają. Wsparcia mi trzeba 

[Sundowner]

Poradzi sobie spokojnie, jeżeli oczywiście wszyscy czujniki będą wykorzystywać o podobnej specyfikacji.

[vito_zm]

Przejrzałem wątek jeszcze raz i widzę,że wszystko na temat założeń zostało już powiedziane.Włączenie się Damosa do tematu gwarantuje sukces.Nie muszę tego uzasadniać wystarczy przejrzeć linki,które podał na temat HID.Chcę tylko przypomnieć o możliwości edycji nie tylko nazwy ale ID producenta kontrolerów.Możliwość programowania 180 wejść jest o.k.Wspomniałem,że Master OC ma tylko 72 wejścia a cały zestaw 4xMaster 288.
Z ciekawości mam pytanie na temat różnicy pomiędzy sterownikami a kontrolerami gier sterowanymi przez USB.MJoy jest widziany jako kontroler gier.OpenCockpits oferuje proste sterowniki na picach z wbudowanym USB np.do sterowania serw lub silników różnego typu.Czy w przypadku tych sterowników też występują znormalizowane protokoły (HID) czy jest to uproszczony interfejs programowy.
Jeszcze jedna sprawa mnie interesuje.Jeśli stosuję kilka sterowników z różnymi interfejsami lub z tym samym np.USB to co z obciążeniem CPU.Damos wspomniał o odpytywaniu stanu wejść.Jest to tylko jeden z procesów związanych z symulatorem. SIOC z OC reaguje na zmianę stanu wejść co daje pewną oszczędność obciążenia CPU.Z drugiej strony odpytywanie w karcie Master nie jest aż tak częste.Damos kiedyś to analizował i o ile pamiętam to nie były to krytyczne czasy. 

[damos]

wystarczy przejrzeć linki,które podał na temat HID.

To, że podałem linki, nie znaczy, że wszystko przeczytałem i zrozumiałem  Każda pomoc będzie mile widziana :023:

Chcę tylko przypomnieć o możliwości edycji nie tylko nazwy ale ID producenta kontrolerów.

Będzie. Słyszałem o problemie sortowania po VendorID - dlatego będzie to można zmienić. Jednak działanie takie nie jest do końca legalne - każdy ID jest przydzielany producentowi przez organizację nadzorującą USB. Oficjalnie nie wolno używać "cudzych" ID-ków  Jednak jeśli każdy sam sobie to zrobi - nie dojdzie do sytuacji dystrybuowania hardware'u z cudzym ID.

Możliwość programowania 180 wejść jest o.k.Wspomniałem,że Master OC ma tylko 72 wejścia a cały zestaw 4xMaster 288.

Ile ich dokładnie będzie - to się okaże. Teoretycznie max dla tego scalaka (przy matrycy 13x13 i braku osi analogowych) to 169 przycisków fizycznie podłączonych. Softwareowo mogę "udawać" więcej - np. inny przycisk wysyłany przy wciśnięciu naszego "mechanicznego" przycisku a inny przy jego zwolnieniu. Byle tylko SVMapper dał radę je obsłużyć.

Z ciekawości mam pytanie na temat różnicy pomiędzy sterownikami a kontrolerami gier sterowanymi przez USB.MJoy jest widziany jako kontroler gier.OpenCockpits oferuje proste sterowniki na picach z wbudowanym USB np.do sterowania serw lub silników różnego typu.Czy w przypadku tych sterowników też występują znormalizowane protokoły (HID) czy jest to uproszczony interfejs programowy.

W przypadku tamtych układów protokół jest wielką niewiadomą Mogą używać HID do transferu niezidentyfikowanej binarki lub używać emulacji COM'a.

Jeszcze jedna sprawa mnie interesuje.Jeśli stosuję kilka sterowników z różnymi interfejsami lub z tym samym np.USB to co z obciążeniem CPU.

Praktycznie brak wpływu. Zależy od konkretnego interface'u. Jak stosujesz wiele interface'ów zjadajacych czas CPU - to wtedy będzie większe obciążenie. Zależy też od ilości wysyłanych danych.

Damos wspomniał o odpytywaniu stanu wejść.

Tym zajmuje się uC. Zbiera dane "do kupy" i szykuje do wysłąnia do PC. Kiedy PC stwierdzi, ze chce dostać update - wysyła takie życzenie do uC. To odpytywanie jest dość sprawne - SVMapper zużywa 0% procka.

Jest to tylko jeden z procesów związanych z symulatorem. SIOC z OC reaguje na zmianę stanu wejść co daje pewną oszczędność obciążenia CPU.Z drugiej strony odpytywanie w karcie Master nie jest aż tak częste.Damos kiedyś to analizował i o ile pamiętam to nie były to krytyczne czasy.

W jaki sposób "reaguje" na zmiany stanu? Wysyła tyko to, co się zmieniło? Wydaje mi się, że tam było odpytywane wszystko po kolei?

[vito_zm]

W jaki sposób "reaguje" na zmiany stanu? Wysyła tyko to, co się zmieniło? Wydaje mi się, że tam było odpytywane wszystko po kolei?

Wyraziłem się nieprecyzyjnie.Odpytuje po kolei i porównuje nową wartość z starą.Jeśli nie było zmiany stanu nie reaguje,jeśli była wykonuje odpowiednią procedurę.

Teoretycznie max dla tego scalaka (przy matrycy 13x13 i braku osi analogowych) to 169 przycisków fizycznie podłączonych. Softwareowo mogę "udawać" więcej - np. inny przycisk wysyłany przy wciśnięciu naszego "mechanicznego" przycisku a inny przy jego zwolnieniu. Byle tylko SVMapper

Nie będzie to problemem,zawsze można zastosować 2 nowe MJoye.Ja tak robię.

[vito_zm]

Sprawdziłem w opisie SIOC jak ten program działa.W dowolnym tłumaczeniu jest napisane,że system jest oparty na zdarzeniach (events).Dalej jest definicja "zdarzenia"

..an event can be defined as a group of operations that are executed when something happens...

W SIOC te "events" są wykonywane jeśli stan lub wartość zmiennych wewnętrznych (internal) ulegnie zmianie lub jeśli wystąpią zmiany na wejściach.
Ja to rozumiem w ten sposób,że jeśli w symulatorze nastąpiła zmiana wartości jakiegoś parametru to informacja o tym zostanie wysłana na wyjście jakiejś karty np Master.I podobnie na wejściu karty,jeśli będzie zmiana stanu to system zareaguje wykonując odpowiednie procedury.Nie wiem czy dobrze to wyjaśniłem.Manuel Velez twórca SIOC oraz całego systemu podkreśla,że to wyróżnia ten system.Nie znam się na tym,powtarzam co napisano.Mam nadzieję,że wyjaśniłem to co miałem na myśli pisząc o reakcji na zmiany stanu zmiennych wewnętrznych.

[damos]

..an event can be defined as a group of operations that are executed when something happens...

Aha. Czyli standardowo - skrypcik lub execution list. Codeking ma to samo. jest do dobre, sprawdzone podejście. SVMapper działa podobnie - dla niego button jest "something happens" a asymulowanie wciskania klawiszy z jakimś opóźnieniem to "excuted group of operations". Myślałem, ze MB ma coś na kształt skryptu i na niej coś się dodatkowo "samo robi" (a takie niecne plany ma Sundowner)

[Sundowner]

(a takie niecne plany ma Sundowner)

Muhahahahahaha...






Póki co siedzę i grzebię w dokumentacjach przetworników ADC Maxima, szukając właściwego do mixu, nie jest łatwo

[damos]

Mały update dla zainteresowanych:
Dorobiłem odczyt i zapis:

• Vendor ID
• Product ID
• Serial Number (max 8 znaków)
• Product Name (max 8 znaków)

Ograniczenie do 8 znaków jest ze względu na oszczędność pamięci. Wszystko ląduje tam w eepromie, którego jest bardzo mało a teksty są przechowywane w Unicode. Obecnie na konfigurowalne nazwy oraz identyfikatory idzie już 5% całej pamięci. Uważacie, ze 8 znaków wystarczy? Jeśli nie - proszę i feedback.
Przykładowe teksty seriala i Product Name:


IMO powinno wystarczyć.

Od razu odpowiadam, że serial jest mi potrzebny, ponieważ mój system I/O używa plików XML z opisem konfiguracji sprzętu, który identyfikuje hardware po VendorID, ProductID i Serial.

[vito_zm]

Oczywiście,że starczy(tak myślę).Dla precyzji opisu mam pytanie.Czy znak oznacza jeden bajt w pamięci?
W MJ16 opis,vendor oraz product ID zajmuje 8 bajtów.Np. 4D 4A 31 36 00 00 02 00,gdzie jest podane w kodzie ASCII nazwa MJ16 dalej ID vendor oraz ID product.
Pytam dlatego,że bajt jest reprezentowany przez 2 znaki ASCII.
Patrząc na przykład to myślę,że jest to zrobione w następujący sposób:
nazwa DM Joy 01 7 znaków ASCII
vendor 0x3eb       3 znaki ASCII
product 0x8         1 znak ASCII
Co daje 11 znaków ASCII prawie 8 bajtów pamięci.
Zmiana nazwy daje uporządkowanie w kontrolerach gry oraz SVMapper.Zmiana pozostałych parametrów umożliwia zmianę pozycji w liście kontrolerów.Nie mam pojęcia jakie są ID joysticków,ja zmieniałem intuicyjnie ID vendora na młodszym bajcie tak aby był poniżej ID Cougara.Tyle moich doświadczeń.
Wiem,że ten temat był dyskutowany na forum,może koledzy wypowiedzą się  na ten temat.

[damos]

Czy znak oznacza jeden bajt w pamięci?

Nie. Znak tekstowy z nazwy to dwa bajty w  pamięci.

Pytam dlatego,że bajt jest reprezentowany przez 2 znaki ASCII.
Patrząc na przykład to myślę,że jest to zrobione w następujący sposób:
nazwa DM Joy 01 7 znaków ASCII
vendor 0x3eb       3 znaki ASCII
product 0x8         1 znak ASCII
Co daje 11 znaków ASCII prawie 8 bajtów pamięci.

Nie. 0x3eb oraz 0x8 to hexadecymalna postać liczby zapisywanej na 2 bajtach. Tak więc 0x3eb zajmuje dwa bajty(0x03+0xeb) tak samo jak 0x8 (0x00+0x08)
Sam tekst jest zapisywany jako unicode - po dwa bajty na znak. Teoretycznie mógłbym zapisywać w ASCII i przy wysyłaniu z urządzenia do PC zamieniać na ucs2, ale wtedy stracił bym możliwość zapisu znaków narodowych. Gdy zabraknie mi eepromu - zrobię tak.
Ty jednak nie musisz się tym przejmować - w aplikacji na załączonym screenie:

1 - zaznaczasz na liście interesujące się urządzenie
2 - program łączy się z urządzeniem i wypełnia oznaczone na czerwono pola z: VendorID, ProductID, Serial number, Device name.
3 - w polach zaznaczonych na czerwono wpisujesz teksty i liczby, których oczekujesz
4 - wciskasz przycisk "save changes" (oznaczony na niebiesko) i wszystko zapisuje się w mikrokontrolerze.
Nie trzeba znać rozmieszczenia tych danych w pamięci, nie trzeba znać reprezentacji tekstu w zapisie szesnastkowym, nie trzeba nic zmieniać w pliku *.eep i później programować. Po prostu zmieniasz wartości w polach edycyjnych. Joy ma zaimplementowaną obsługę poleceń do odczytu i zapisu tych wartości a program do konfiguracji wysyła mu odpowiednio spreparowane komendy. Po restarcie urządzenia (np. odłączenie od USB i ponowne podłączenie, choć może dodam polecenie restartu) urządzenie będzie widoczne w systemie z nowymi parametrami. To ma być maksymalnie proste i przyjazne użytkownikowi.

Zmiana nazwy daje uporządkowanie w kontrolerach gry oraz SVMapper.Zmiana pozostałych parametrów umożliwia zmianę pozycji w liście kontrolerów.

Taki jest właśnie cel implementacji edycji tych właściwości.

Nie mam pojęcia jakie są ID joysticków

Nie ma czegoś takiego jak ID joysticka. Każdy producent może wystąpić o przyznanie mu VendorID a później ProductID i inne rzeczy ustala sam w-g własnego "widzimisię".