Autor Wątek: Kokpity, panele - dla budowniczych symulatorów  (Przeczytany 130487 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #210 dnia: Czerwca 22, 2009, 09:27:08 »
Witajcie,
zajrzałem do Twojej strony Skalarki,robi wrażenie http://www.a320-project.skalarki.co.uk/
W porównaniu z Tobą to dopiero raczkujemy.W związku z projektem mam do Ciebie kilka pytań.
1.Czy projekt jest open tzn.dla wszystkich zainteresowanych.
2.Jeśli tak to czy możesz udostępnić schematy.Chciałbym porównać Twoje rozwiązanie z innymi projektami.
Wracając do projektu to Twój ma większe możliwości niż rozwiązanie OpenCockpits,mam na myśli liczbę wejść oraz wyjść.Chociaż projekt OC można powielać zwiększając jego możliwości.Wadą  OC jest cena pakietów.Ja na dzień dzisiejszy jestem skazany na OC z prostego powodu - softu.SIOC komunikuje się z Falconem porzez moduł FAST.FAST jest dziełem falconowca mihi.
FS komunikuje się z SIOC za pośrednictwem FSUIPS.W tym przypadku nie ma problemu z pisaniem skryptów.
Ja muszę rozbudować mój hardware,dlatego jestem zainteresowany nową platformą.Mogę oczywiście kupić go w OC,ale lepiej wspierać rodzime pomysły.
Cytuj
Aplikacja jest robiona pod FSX więc ze światem komunikuje się poprzez Simconnect
Wiem,że Arek rozpoczął realizację kokpitu do Falcona,dlatego ma ten sam problem co ja.Czy przewidujesz jakąś aplikację pod ten sim?
ps.
Mickey81 mnie się wdaje,że Twoje rozwiązanie nie będzie działać.Najlepiej zrobić model i to sprawdzić,ja tak zawsze robię.

mickey81

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #211 dnia: Czerwca 22, 2009, 09:32:36 »

Mickey81 mnie się wdaje,że Twoje rozwiązanie nie będzie działać.Najlepiej zrobić model i to sprawdzić,ja tak zawsze robię.

Powinno działać :) robiłem tak już z przekaźnikiem. Z tym, że zza kondensatora wyprowadzałem bazę zwykłego tranzystora NPN, a w kolektorze była cewka przekaźnika i kłapało :) Dla pewności zrobię jednak model.

Skalarki: WOW!!!

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #212 dnia: Czerwca 22, 2009, 12:24:52 »
Model będzie działał,problem jest z rozpoznaniem przez MJoy.Musisz połączyć Twój prototyp z MJoy następnie w SVMapper przypisać funkcje i sprawdzić czy działa jak toggle.

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #213 dnia: Czerwca 22, 2009, 12:56:33 »
vito_zm Dziękuję za miłe przywitanie i dobre słowa na temat mojego projektu.

1.Czy projekt jest open tzn.dla wszystkich zainteresowanych.
2.Jeśli tak to czy możesz udostępnić schematy.Chciałbym porównać Twoje rozwiązanie z innymi projektami.
Rozumiem że chodzi ci o projekt I/O nie zaś o cały kokpit. Otóż w chwili obecnej nie mam żadnego problemu z udostępnieniem schematów. Same schematy dają obraz jak projekt będzie zrealizowany jednocześnie nie odkrywają tego co w tym najważniejsze czyli oprogramowanie procka i programu samej aplikacji. Moim zamysłem początkowo było stworzenie komercyjnej wersji w stylu Opencockpits ale obecnie nie jestem pewien czy mam na to wystarczające siły i środki, więc prawdopodobnie projekt skończy jako opensource dla każdego zainteresowanego (ale co do tego to decyzji jeszcze nie ma).
Jeśli chodzi o możliwości i skalowalność projektu to są one o wiele większe niż Opencockipts tylko że nie ma takiej potrzeby bo raczej nie widzę symulatora który potrzebuje więcej wejść/wyjść niż liczby które przytoczyłem w poście powyżej. Nie dodałem tam że będzie możliwe sterowanie również silnikami krokowymi.

Wiem,że Arek rozpoczął realizację kokpitu do Falcona,dlatego ma ten sam problem co ja.Czy przewidujesz jakąś aplikację pod ten sim?
Nie mówię tak i nie mówię nie. W chwili obecnej nie mam zielonego pojęcia co to jest FAST i inne tego typu hasła od których roi się na tym forum, ale jeszcze parę miesięcy temu tyle samo wiedziałem o simconnect. Lubię się uczyć i pokonywać nowe wyzwania - a to być może byłoby następne.

To byłoby tyle na razie, chętnie odpowiem na wszystkie pytania związane z projektem, ale proszę o wyrozumiałość za opóźnienia w odpowiedziach gdyż ostatnio zbyt dużo robię na raz. Schematy przygotuję w formie .pdf do końca tygodnia. Będą do pobrania z mojej stronki.

PS. A propos mojej stronki. Bardzo dawno jej nie aktualizowałem, cały wolny czas zżera projekt I/O dlatego między innymi nie znajdziecie tam ani słowa o tym o czy tera piszę. Ale wkrótce coś uaktualnię.

mickey81

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #214 dnia: Czerwca 23, 2009, 10:09:19 »
model zrobiony, przetestowany i działa  :banan Wprowadziłem jednak kilka zmian. Wyjaśnię działanie na schemacie. Po podaniu napięcia za pomocą przełącznika następuje ładowanie kondensatora C1 poprzez rezystor R1. Czas ładowania w sekundach wyznaczamy ze wzoru T=R*C i możemy go dobrać do własnych potrzeb. Wartości ze schematu generują coś ok 0.5s, ponieważ na czas ładowania kondensatora ma wpływ rezystancja 'styków' klucza 4066. Przebieg napięcia na wejściu sterującym klucza (pin 13) oznaczyłem numerem 1. Ten krótki impuls wystarczy do chwilowego zadziałania klucza i wysterowania dowolnego wejścia mjoya typu pushbutton. Po przełączeniu w pozycję 2 kondensator rozładowuje się przez rezystor do masy układu. Proces ten obrazuje krzywa nr 2. Przełącznik jest niezbędny ponieważ kondensator przed ponownym załączeniem układu musi zostać rozładowany. W przeciwnym wypadku układ nie zadziała, gdyż naładowany kondensator będzie stanowił dla prądu stałego przerwę. Dioda Led została użyta do sygnalizacji zadziałania klucza.

Poniżej schemat połączeń układu docelowego, sprawdzonego z mjoyem.



Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #215 dnia: Czerwca 23, 2009, 10:47:49 »
Układ działa tak jak opisałeś tzn.generuje impuls na wyjściu 4066 w momencie załączenia przełącznika do pozycji 1.Rozumiem,że wyjścia podłączasz zgodnie z mapą od poz. 1 do 64.
Przełączniki dwu pozycyjne podłączane są wg.mapy od poz.65 do poz.94.Przełączniki te mają 2 pozycje on oraz off do których możemy przypisać funkcję sima typu on off.Np.poz.65 odpowiada załącz a poz.73 wyłącz jakąś funkcję zgodnie z SVMapper.
Jak chcesz to zrealizować Twoim układem.

mickey81

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #216 dnia: Czerwca 23, 2009, 11:46:44 »
Za pomocą drugiej sekcji przełącznika. Wtedy jeden 4066 obsłuży dwa przełączniki i wykorzysta dwa wejścia typu pushbutton. Oczywiście układ ma ograniczenie, jak opisałeś. Przez SVMapper nie zrealizuję mapowania funkcji off - to duży minus, ale niedużym nakładem pracy i kosztów mogę rozszerzyć możliwości mjoya. Pushbuttonów jest na tyle dużo, że nie powinno ich zabraknąć do realizacji innych funkcji kokpitu. Zresztą sam wiesz, że w razie czego można dorzucić drugiego mjoya ;) z tym, że pracującego w trybie ustawiającym na pierwszych pozycjach enkodery i toggle (chyba mode2, ustawiany zworką).
Jeśli masz jakąś propozycję usprawnienia tego rozwiązania, jestem otwarty na każde rozwiązanie, które może nam ułatwić zabawę w pitbuilding :)
Pozdrawiam
mickey81

damos

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #217 dnia: Czerwca 23, 2009, 11:53:44 »
Witaj skalarki !
Gratuluję projektu - naprawdę robi wrażenie  :010:

Rzuciłem okien na "twojego" PIC18f4550. Ładnie się prezentuje - sprzętowe USB, obudowa DIP, zegar 48 MHz. Powiedz mi, dlaczego on ma jedynie 12 MIPS ? Jest to średnia, czy większość instrukcji zajmuje kilka cykli zegarowych? Czy odczyt stanu portu zajmuje jeden cykl, czy więcej? Jak zrealizowałeś obsługę tylu wejść i enkoderów? Czy tak wysoki zegar pozwala zwykły polling i key matrix ? W przypadku enkoderów przy szybkim kręceniu przesunięcie fazowe spada do kilkuset us (przy 500us i 512 wejściach masz ok. 48 cykli zegarowych na obsługę jednego, co przy średniej wydajności daje ok. 12 instrukcji uP bez uwzględnienia czasu na komunikację).

Rzuciłem okien na simconnect - to interface Microsoftu? Mógłbys w kilku słowach opisać ideę jego działania (zależności między modułami, interakcja ze sprzętem i symulatorem) ? 
Czy są inne symulatory zgodne z tym interface'm ?
Czy aby posiadać SDK nie trzeba kupić bardziej "wypasionej" (droższej) wersji FSX'a ?

Ja ze swej strony będę kontynuować zabawę z Atmelami "just for fun".

Jeśli coś pominąłem to proszę uzupełnić.
Wydaje się, że uwzględniłeś wszystkie potrzebne czynniki. Ja jedynie zastanawiam się nad pozostawieniem na MB miejsca na drivery prądowe. W przypadku nie używania ich -można "zmostkować" odpowiednie nóżki. To pozwoli zachować to samo PCB MB dla różnych zastosowań

Jeszcze pytanie do Damosa - udostępnisz bibliotekę do bezpośredniego sterowania tymi urządzeniami ew. Tzn. protokół wykorzystywany przy komunikacji PC -> MB (USB) ?
Protokół będzie dość prosty i chyba będzie można go "upublicznić". Jednak wolał bym uniknąć sytuacji, kiedy inny soft komunikuje się się bezpośrednio ze sprzętem. Będzie wtedy ryzyko powstania wielu rozwiązań, które nie będą wzajemnie kompatybilne ze względu na bezpośrednie odwołania do sprzętu. A takie odwołania mogą sobie nawzajem przeszkadzać. Od tego jest warstwa abstrakcji w postaci softu, aby przez nią była realizowana komunikacja świata z hardware'm.
« Ostatnia zmiana: Czerwca 23, 2009, 11:59:14 wysłana przez damos »

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #218 dnia: Czerwca 23, 2009, 12:45:24 »
Jednak wolał bym uniknąć sytuacji, kiedy inny soft komunikuje się się bezpośrednio ze sprzętem. Będzie wtedy ryzyko powstania wielu rozwiązań, które nie będą wzajemnie kompatybilne ze względu na bezpośrednie odwołania do sprzętu.
To może nie bezpośrednio do sprzętu ale poprzez jakąś bibliotekę, którą będziesz używał do komunikacji z urządzeniami w usłudze systemowej/serwerze.

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #219 dnia: Czerwca 23, 2009, 13:04:33 »
Cytuj
Jeśli masz jakąś propozycję usprawnienia tego rozwiązania, jestem otwarty na każde rozwiązanie, które może nam ułatwić zabawę w pitbuildin
Jest to najprostsze rozwiązanie i dlatego nie ma sensu komplikować układu.




mickey81

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #220 dnia: Czerwca 23, 2009, 13:10:21 »
Prawda? Nawet nie ma sensu robić innej płytki niż montaż na uniwersalnej.
Pozdrawiam
mickey81

mickey81

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #221 dnia: Czerwca 23, 2009, 13:23:37 »
Vito_zm to działa tak:

Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #222 dnia: Czerwca 23, 2009, 22:16:12 »
damos ... wiedziałem że poprzeczka powędruje bardzo wysoko ... straszna szkoda że nie zgrały się nasze procki, bo byśmy wymodzili coś odlotowego - czuję.

Zanim wyskrobię coś dalej muszę lojalnie uprzedzić: co prawda z zawodu jestem elektronikiem ale do zeszłego roku miałem bardzo długą przerwę w gmeraniu w tych sprawach. Jeśli chodzi o programowanie to całkowicie samouk. :002: Więc pewno na twoim poziomie to nie pogadamy ale wymiana rozwiązań i informacji na pewno się przyda.

Powiedz mi, dlaczego on ma jedynie 12 MIPS ? Jest to średnia, czy większość instrukcji zajmuje kilka cykli zegarowych?
Nie umiem dokładnie odpowiedzieć na to pytanie, ale z tego co się zorientowałem MIPS MIPSOWI nie równy i jak mi ktoś już to tłumaczył nie za bardzo da się porównywać procki tylko patrząc na ten parametr. jedno jest pewne jest to o wiele szybszy procek niż to co używa OC.
Wybór padł na ten procek głównie ze względu na duże możliwości we/wy, prostote w programowaniu, sprzętowe USB, sprzętowe SPI, sprzętowe I2C, 10 bitowe przetworniki A/D, gotowy USB stack od Microchipa wraz z driverami (nie HID) co daje o wiele szybszą transmisję przez USB.

Jak zrealizowałeś obsługę tylu wejść i enkoderów? Czy tak wysoki zegar pozwala zwykły polling i key matrix ? W przypadku enkoderów przy szybkim kręceniu przesunięcie fazowe spada do kilkuset us (przy 500us i 512 wejściach masz ok. 48 cykli zegarowych na obsługę jednego, co przy średniej wydajności daje ok. 12 instrukcji uP bez uwzględnienia czasu na komunikację).

Załączam schemat urządzenia, żeby było wiadomo o czym mówię - werja uproszczona do testów.

Widoczne są 3 bloki: wejścia, wyjścia oraz wyświetlacze 7-segmentowe.
Port B docelowo będzie sterował 4 grupami expanderów skonfigurowanych jako wejśćia oraz 4 grupami expanderów skonfigurowanych jako wyjścia.

Wszystko działa na szynie SPI, czyli wszystkie bloki są podłączone do SPI ale każdy blok ma oddzielną linię CS, dzięki czemu w jednej chwili można sterować konkretnym blokiem. Expandery MCP23S17 są o wiele lepszym rozwiązaniem od zwykłego rejestru SIPO ze względu na sprzętowe adresowanie oraz  możliwość konfiguracji pinów jako wejśćia lub wyjścia, wewnętrzy PULL-UP oraz bardzo fajna rzecz: dwa piny sterowane z INTERRUPT ON CHANGE REGISTER. Każdy MCP w grupie ma osobny adres, co daje możliwość czytania i zapisywanie do konkretnego układu.

Enkodery są niczym innym jak tylko urządzeniami wykorzystującymi trzy piny wejściowe. Ponieważ adresowanie pozwala na dostęp do konkretnego expandera, jeśli podłączymy enkoder do pierwszego chipa można czytać z niego informacje z inną częstotliwością niż z innych wejść, co ma wpływ na wydajność urządzenia. Jeśli dobrze się doczytałem w założeniach Twojego projektu tutaj właśnie jest największa różnica. Zresztą co by tu nie kombinować pewno potrzebny będzie kompromis (w OC jest ograniczenie szybkościpracy encoderów) ale zobaczymy.

Ta sama zasada dotyczy wyświetlaczy 4 grupy po 4 MAX-y (na rysunku są trzy bo taka akurat była potrzeba :002:)  sterowane z wyjść portu B.

Cytuj
Rzuciłem okien na simconnect - to interface Microsoftu? Mógłbys w kilku słowach opisać ideę jego działania (zależności między modułami, interakcja ze sprzętem i symulatorem) ?

Otóż jest to interfejs dla developerów piszących aplikacje umożliwający odczytywanie i zapisywanie danych z FSX. Dzięki niemu mamy dostęp do wszystkiego co dzieje się w FSX. Bardzo fajną opcją jest możliwość pobierania danych z FSX tylko kiedy jakaś zmiana się pojawi, np. zamiast nonstop wysyłać KURS informacja wysyłana jest tylko wtedy gdy kurs zostanie zmieniony itp. FSUIPC wykorzystuje intensywnie simconnect do przetwarzania danych.

Cytuj
Czy są inne symulatory zgodne z tym interface'm ? 
Niestety simconnect jest napisany specjalnie dla FSX.

Cytuj
Czy aby posiadać SDK nie trzeba kupić bardziej "wypasionej" (droższej) wersji FSX'a ?
 
SDK było dostępne od pierwszej wersji FSX, ale potem były serwis-packi. Wszytko jest dostępne na oryginalnej płycie FSX-a z bibliotekami oraz gotowymi przykładami.

Może na tyle na razie bo się post - kobyła zrobił.

Chętnie powymianiam dalej wszelkie informacje. Damos - nie powstrzymuj się przed krytyką jeśli widzisz jakiś problem itp.

Pozdrawiam

damos

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #223 dnia: Czerwca 24, 2009, 00:52:27 »
damos ... wiedziałem że poprzeczka powędruje bardzo wysoko ... straszna szkoda że nie zgrały się nasze procki, bo byśmy wymodzili coś odlotowego - czuję.
Nic straconego :) Trzeba było się wcześniej ujawnić ;)

z tego co się zorientowałem MIPS MIPSOWI nie równy i jak mi ktoś już to tłumaczył nie za bardzo da się porównywać procki tylko patrząc na ten parametr.
MIPS to Mega Instructions Per Second. Innymi słowy - ilość milionów instrukcji assemblera wykonywanych w ciągu sekundy. Da się procki porównywać w-g tego parametru... Oczywiście - różne instrukcje mają różną ilość cykli zegarowych, ale jest pewna średnia typowa dla procka. Najczęściej podaje się, ile MIPSÓW dany procek "wyciąga" z 1 MHz. Widzę tutaj, że PIC ma około 0,25 MIPS z 1MHz. AVR32 ma ok. 1,32 MIPS z MHz. ATmega to ok. 1MIPS/MHz. Naturalnie - w konkretnym zastosowaniu ratio może się zmieniać. No i u ciebie jest sprzętowe USB  :021: :010:
Najbardziej interesuje mnie, czy odczyt i zapis portów masz w jednym cyklu zegarowym - tzn: jeśli w pętli dasz na porcie wyjściowym zapis do niego 0, później 1 i tak w kółko - czy długość impulsu na wyjściu będzie równa 2 długościom impulsu taktowania uP ?


Wybór padł na ten procek głównie ze względu na duże możliwości we/wy, prostote w programowaniu, sprzętowe USB, sprzętowe SPI, sprzętowe I2C, 10 bitowe przetworniki A/D, gotowy USB stack od Microchipa wraz z driverami (nie HID) co daje o wiele szybszą transmisję przez USB.
To fakt - PIC ma lepszy support niż Atmel.   :015:

Expandery MCP23S17 są o wiele lepszym rozwiązaniem od zwykłego rejestru SIPO ze względu na sprzętowe adresowanie oraz  możliwość konfiguracji pinów jako wejśćia lub wyjścia, wewnętrzy PULL-UP
To zależy :)
1 - moje MBI mają wbudowaną regulację prądu dla wszystkich 16-tu kanałów
2 - cena... MCP23S17 znalazłem tylko w TME za... 8PLN sztuka (a ma tylko 16 pin). Za 8 PLN mam ponad 2 "moje" MBI - a one dają mi 32 porty OUT, więc wychodzi 2 razy taniej :) Za 10 PLN mam ATmege a ona ma 32 konfigurowalne porty i SPI i TWI i 6 ADC i PWM i .... :)
3 - MCP23S17 to adresacja, konfiguracja, SPI - bez zewnętrznego zegara - nieźle :)


oraz bardzo fajna rzecz: dwa piny sterowane z INTERRUPT ON CHANGE REGISTER.
  :011: A do czego tego można użyć?

Każdy MCP w grupie ma osobny adres, co daje możliwość czytania i zapisywanie do konkretnego układu.
I to jest duża zaleta. Masz większą szybkość akwizycji danych.

Enkodery są niczym innym jak tylko urządzeniami wykorzystującymi trzy piny wejściowe. Ponieważ adresowanie pozwala na dostęp do konkretnego expandera, jeśli podłączymy enkoder do pierwszego chipa można czytać z niego informacje z inną częstotliwością niż z innych wejść, co ma wpływ na wydajność urządzenia. Jeśli dobrze się doczytałem w założeniach Twojego projektu tutaj właśnie jest największa różnica. Zresztą co by tu nie kombinować pewno potrzebny będzie kompromis (w OC jest ograniczenie szybkościpracy encoderów) ale zobaczymy.
Rozumiem, że jeszcze nie masz oprogramowanych enkoderów? Szkoda :( Liczyłem na jakieś wnioski i timingi. Bez ograniczenia prędkości się nie obejdzie.


SDK było dostępne od pierwszej wersji FSX, ale potem były serwis-packi. Wszytko jest dostępne na oryginalnej płycie FSX-a z bibliotekami oraz gotowymi przykładami.
Hhhhmm... a co powiesz np. na to:
http://www.fsdeveloper.com/forum/showthread.php?p=21067
Cytat: Microsoft Game Studios
The FSX SDK is currently only available by purchasing FSX Deluxe. I am not aware of any plans to change that.
Cytuj
there is no upgrade path from Standard to deLuxe so you would have to buy the deLuxe version at full price to get the SDK.

Chętnie powymianiam dalej wszelkie informacje. Damos - nie powstrzymuj się przed krytyką jeśli widzisz jakiś problem itp.
Problem? Problemem może się okazać szybkość odczytu expanderów w przypadku obsługi enkoderów. Jednak to jedynie kwestia ograniczeń na prędkość tych drugich.  Jeśli expandery mają sprzętowy, szybki SPI - to powinny dać radę. jeszcze jedno Enkoder można traktowac jak urządzenie wykorzystujące 2 a nie 3 piny wejściowe. Wystarczy ustawić pull-up na wejściach a środkowy pin enkodera do masy. Wtedy jeden expander zamiast 5-ciu obsłuży ci 8 enkoderów.

BTW - zdradź, jakie układy zastosowałeś do sterowania 7-seg. :) Jest gotowy hardware do multiplexowania 7 seg?
« Ostatnia zmiana: Czerwca 24, 2009, 01:06:29 wysłana przez damos »

damos

  • Gość
Odp: Kokpity, panele - dla budowniczych symulatorów
« Odpowiedź #224 dnia: Czerwca 24, 2009, 01:28:01 »
ok - jest taki hardware... (MAX 7219) ale 35 PLN za sterowanie 8-mioma segmentami to przesada :( http://www.seguro.pl/sklep/?zobacz=3185&producent=