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

[vito_zm]

Protest przyjęty,obiecuję poprawę  .Masz rację Damos przepraszam za nieścisłości .Zastanawiam się dlaczego nikt nie pyta o szczegóły może jest to dla nich dziwne,że ktoś w Polsce też projektuje konkurencyjne sterowniki oraz platformy programowe za free.Zobaczymy czy zareagują na prototyp EGHI gaugesów dla Falcona,który mam zamiar zaprezentować.Może nasze polskie forum za jakiś czas będzie alternatywą dla pitbuilderów.

[damos]

Nie przejmuj się, Vito_zm - uwierzą, kiedy zobaczą działające (ja z resztą też )
Pierwszy Firmware do testowego DMKeys8 jest już w 3/4 gotowy. Dziś lub jutro Ci wyślę.

[damos]

Dziś dzięki uprzejmości vito_zm DMkeys8 przeszedł pierwsze testy po za moim kompem - pomyślnie! Mimo kilku niespodziewanych trudności udało się uruchomić pierwszą, ograniczoną wersję. Klikanie w podłączone push-buttony jest już zamieniane na wysyłanie predefiniowanej sekwencji przycisków. Teraz zostało dorobić tool do zapisywania ustawień wewnątrz kości i urządzenie niemal gotowe!

[vito_zm]

Potwierdzam DMkeys8 jest widziany jako klawiatura.Zrobiłem testy z push-button jest o.k.Układ (program)jest odporny na drgania styków nie ma powtórzeń,reaguje bardzo szybko.Te niespodziewane trudności jak zwykle okazały się trywialne.Trzeba było zmienić dane sterownika w pliku .eep.Teraz widać jak ważna jest możliwość dokonania tych zmian w programie Damosa to tak przy okazji.

[damos]

Potwierdzam DMkeys8 jest widziany jako klawiatura.Zrobiłem testy z push-button jest o.k.Układ (program)jest odporny na drgania styków nie ma powtórzeń,reaguje bardzo szybko.

I tak miało być  :banan

Te niespodziewane trudności jak zwykle okazały się trywialne.Trzeba było zmienić dane sterownika w pliku .eep

hmm... czy my zmienialiśmy cokolwiek w plikach?  Chyba nie  Życie staje się prostsze, jeśli masz odpowiednią opcję w programie  Prawda 

[vito_zm]

Jak zwykle masz rację,dostępna opcja rozwiązała problem.DMkeys8 jest widziany w menedżer urządzeń jako klawiatura HID.Oczywiście nie ma go w kontrolerach gier co rozwiązało następny problem z SVMapper.
Sprawdziłem wyprowadzone na łączówkę porty testując program.Wszystkie działają.Jeszcze nie wiemy czy Damosowi wystarczy pamięci do zaprogramowania 169 wejść,ale wstępnie można założyć,że maxymalna pojemność matrycy diodowej wyniesie 169 lub mniej.
W związku z czym prośba do Zajca aby się temu przyjrzał.Wyprowadzenia są dostępne na stronie Damosa.Mam taką sugestię aby wyprowadzić każdy wiersz z 13 kolumnami na łączówkę co daje 13 łączówek 14 pin.Myślę,że można wstępnie rozpocząć dyskusję jak wyprowadzić sygnały z matrycy.

[damos]

W związku z czym prośba do Zajca aby się temu przyjrzał.Wyprowadzenia są dostępne na stronie Damosa.Mam taką sugestię aby wyprowadzić każdy wiersz z 13 kolumnami na łączówkę co daje 13 łączówek 14 pin.Myślę,że można wstępnie rozpocząć dyskusję jak wyprowadzić sygnały z matrycy.

apropos matrycy - ze względów wydajnościowych planuję matrycę 10x16. 10 kolumn będzie zasilanych a z 16 wierszy będę odczytywać dane. Odczyt będzie realizowany na 2 pełnych portach po 8 wyjść każdy, co umożliwi realizację tego w 2 cyklach zegarowych.
Tak więc cała prawa strona z obrazka:

będzie zmapowana do wierszy a piny z lewej: PC6-PF0 będą kolumnami.
Sumarycznie ubędzie 9 wejść (160 zamiast 169), ale pozwoli to na znaczną optymalizację kodu jak i struktur danych.

Obecnie pracuję nad zapisem konfiguracji układu do pamięci eeprom, która ma zaledwie 1024 bajty. 44 bajty "poszły" na VENDOR_ID, Product_ID, Serial, Name i tym podobne. Tak więc na config zostało ok. 980 bajtów. To daje średnio 6 bajtów na opis jednej kontrolki, wliczając w to sekwencje klawiszy, które mają być wysłane . Piekielnie mało:
każdy element (button, switch, przełącznik multipozycyjny, encoder) musi być opisany swoim ID - 1 bajt
każdy pin musi mieć opisane - do którego punktu matrycy jest dołączony (1 bajt * ilość pinów), (przycisk = 2 bajty,enkoder i prosty przełącznik = 3 bajty)
wysyłana sekwencja klawiszy może być wysłana po naciśnięciu lub po zwolnieniu - więc dwie sekwencje na przycisk, 2 na enkoder, 2 na każdą z pozycji przełącznika...
sekwencja to:
1 bajt opisu długości, 1 bajt na modyfikatory typu shift, ctrl, alt itp. 1 bajt na każdy klawisz, w sumie: min 3 bajty
W tym układzie na każdy przełącznik potrzeba min 10 bajtów, na każdy push-button z podpiętymi 3 klawiszami (np. ctrl+M+D+1) trzeba 9 bajtów... wychodzimy za limit

Tak więc teraz rozpracowuję sposób na zmieszczenie w kości opisu o wielkości większej niż eeprom  :karpik (ok 1,5 KB).

[vito_zm]

Tak więc teraz rozpracowuję sposób na zmieszczenie w kości opisu o wielkości większej niż eeprom

Jeśli nie wyrobisz z pamięcią to pozostają dwa rozwiązania.Zmniejszyć pojemność matrycy lub zrobić zewnętrzny program podobny do SVMapper o ile jest to możliwe.Jeszcze jedna myśl przyszła mi do głowy.Ponieważ jest różnica 1 bajtu w opisie push-button oraz przełączników to można ograniczyć liczbę tych ostatnich tak jak w MJoyu zyskując kilka bajtów.

[damos]

U mnie sam decydujesz, co jest podpięte gdzie - jak wstawisz sobie dużo przełączników to zostanie mniej wolnych miejsc dla przycisków. Możesz nawet dać tylko 8 push buttonów, do każdego podpiąć 16 sekwencji po 6 klawiszy każda (osobne 16 na na ON i osobne 16 na OFF ) i zużyjesz całą dostępną pamięć  :karpik .  Tu NIE MA wejść na sztywno przypisanych dla przełączników lub innych dla przycisków. Wszystko możesz podłączyć wszędzie - i odpowiednio skonfigurować w programie.
Program we właściwym momencie sam powie - STOP - więcej się już nie da, nawet jeśli pozostaną wolne piny ma matrycy.

[vito_zm]

Damas jesteś genialny,jest to rozwiązanie problemu.W ten sposób użytkownik sam decyduje o konfiguracji mając świadomość ograniczeń.

[Sundowner]

Chwileczkę. Ale czemu nie ograniczyć się na bazowej konfiguracji do powiedzmy 64 przycisków, a skrzydła rozwijać dopiero po podpięciu płytki - matrycy, na której umieścić kość zewnętrznego EEPROMu, komunikującego się po IIC ? I wtedy już właściwie bez limitów pamięci, bo te EEPROMy są ogromne, w porównaniu z "on chip".


Albo w ogóle na ostatecznej wersji płytki dać miejsce na zewnętrzny EEPROM, jak ktoś będzie potrzebował zwykłego kontrolera joya, to zostawi wolne, a jak kontroler panelu, to go tam wciśnie.

[damos]

Chwileczkę. Ale czemu nie ograniczyć się na bazowej konfiguracji do powiedzmy 64 przycisków, a skrzydła rozwijać dopiero po podpięciu płytki - matrycy

Bo "bazowo" mamy tylko 26 przycisków.

, na której umieścić kość zewnętrznego EEPROMu, komunikującego się po IIC ? I wtedy już właściwie bez limitów pamięci, bo te EEPROMy są ogromne, w porównaniu z "on chip".
Albo w ogóle na ostatecznej wersji płytki dać miejsce na zewnętrzny EEPROM, jak ktoś będzie potrzebował zwykłego kontrolera joya, to zostawi wolne, a jak kontroler panelu, to go tam wciśnie.

1 - Odczyt eeprom jest wolny, a zewnętrznego jeszcze bardziej
2 - wewnętrznego RAM'u jest jedynie 2,5 KB na wszystkie zmienne (wliczając w to stack USB oraz na stos)...
A odczytywanie eeprom "na raty" przy każdej iteracji odpytania wyjść odpada - nie zmieści się między kolejnymi ramkami USB. (myślałem o tym)

[damos]

Mały update DMKeys8:
Trafiło się kilka wolnych nocy i rozwiązałem problemy z pamięcią i dynamiczną konfiguracją wejść układu. Zrobiłem obsługę:
- przycisków,
- przełączników,
- emulacji przełącznika bistabilnego za pomocą przycisku
- obsługę 3 rodzajów enkoderów.

Ciekawostka: po skonfigurowaniu na obsługę ponad 50 enkoderów (!) układ nadal "wyrabiał się" czasowo i poprawnie je obsługiwał, co jest pozytywnym zaskoczeniem

Całość zaczyna wyglądać obiecująco. Teraz pozostał do zrobienia jakiś "przyjazny" program do konfiguracji wejść i będzie gotowe.

[vito_zm]

Ciekawostka: po skonfigurowaniu na obsługę ponad 50 enkoderów

Moje gratulacje.Jest to bardzo dobra wiadomość,ponieważ zauważyłem,że do realizacji kokpitu F16 potrzeba trochę enkoderów.W moim przypadku liczba 50 jest dużym zapasem.

[damos]

zauważyłem,że do realizacji kokpitu F16 potrzeba trochę enkoderów.W moim przypadku liczba 50 jest dużym zapasem.

OK, odpaliłem nawet 80 enkoderów  :banan   (więcej się nie da ze względu na ilość wejść matrycy) wymagało to nieco zabawy w optymalizacje kodu, ale w końcu poszło.
W międzyczasie zetknąłem się z problemem, jakim jest jakość enkoderów.
Normalnie przebieg sygnału powinien wyglądać tak: (sygnały przesunięte w fazie o 90stopni)


Niestety - w praktyce wygląda to dużo mniej idealnie. Musiałem dostosować firmware do obsługi 2 typów enkoderów, które akurat posiadam:
- enkoder bez przycisku, 12 kroków/obrót
- enkoder z przyciskiem w osi, 24 kroków/obrót

Pierwszy generuje takie przebiegi:
obrót w prawo:

obrót w lewo:


Widać bardzo mocną degenerację sygnału i praktycznie brak przesunięcia fazowego z jednej strony. Okres istnienia przesunięcia fazowego jest czasem bardzo mały: 240 uS, co wymagało by odpytywania z częstotliwością ponad 8000 razy na sekundę, co w naszym przypadku nie jest możliwe.

Drugi typ enkodera (z przyciskiem w osi) ma lepszy kształt sygnału, generuje za to dużo większy jitter
obrót w prawo:

obrót w lewo:


Ze względu na większą ilość impulsów na obrót timingi też są bardziej krytyczne - przesunięcie sygnałów bywa i na poziomie 160uS (wymaga próbkowania 12000/s)

Do tego poważny jitter: tu o amplitudzie 4.6V i czasie trwania kilku szybkich impulsów !

Generuje dodatkowe, przekłamujące impulsy:




Przy powolnym obracaniu (nie szybciej niż 1 sek/obrót) układ działa bezbłędnie. Przy bardziej dynamicznym obracaniu zaczyna generować "fałszywe klawisze" tzn - w ciągu klawiszy przypisanych obrotowi w prawo pojawia się jeden lub kilka klawiszy przypisanych obrotowi w lewo.

Obawiam się, że enkodery jeszcze gorszej jakości mogą nie pracować idealnie.

Niestety - nie mam tu zbyt wielkiego pola manewru i jeśli taka jakość wystarczy - wolał bym na razie przy niej pozostać. Jedyny sposób na złagodzenie tych dolegliwości to obniżenie ilości stosowanych przez użytkownika elementów i zwiększenie (ustawienie w opcjach programu konfiguracyjnego) wartości filtra cyfrowego (ustawiane osobno dla enkoderów i osobno dla przycisków i przełączników)

Co Wy na to ?