Wątek: Kokpity, panele - dla budowniczych symulatorów

[vito_zm]

Witam,
ponieważ temat zastosowanie LCD do wyświetlania parametrów  symulatora w panelach jest na tapecie to postanowiłem napisać swoje doświadczenia z tym związane.
Co najmniej od 2 lat chciałem zrealizować wyświetlanie na LCD (4x20) DED z falcona.Znalazłem w sieci  projekt opartych na LPT oraz USB.Napisałem do autora Red Dog (nickname).Jego rozwiązanie pozwalało sterować nie tylko DED,PFL ale także RWR,ale było na nasze warunki drogie,dlatego poradził mi zastosować najtańsze w chwili obecnej rozwiązanie oparte na klawiaturze Logitech G15.I tak zrobiłem.
Parę słów na temat tego rozwiązania.Trzeba kupić najlepiej na Allegro używaną klawiaturę z której bierzemy LCD oraz sterownik.Potrzebujemy jeszcze program AirdAncE o nazwie G15 Viper z strony
http://www.viperpits.org/smf/index.php?topic=3232.0
Inne rozwiązanie polega na zastosowaniu programu FalconGauges oraz LCD połączonego do karty graficznej.Jeśli chcemy zastosować 2 PC-y to musimy użyć program komunikacyjny F4Glass oraz oczywiście FalconGauges.
Jest jeszcze inna możliwość zrobić to samemu.Oto przykład
http://www.viperpits.org/smf/index.php?topic=4381.0
Aby to zrealizować to trzeba poznać tzw.dzieloną pamięć share memory,gdzie są wszystkie dane symulatora i można je tylko  przechwycić a nie modyfikować tak jak w FS.Na forum viperpits jest paru programistów,którzy umieją z tego korzystać i robią wspaniałe programy np.FalconGauges oraz MFD Extractor.Poznałem wirtualnie jednego z nich mihi4,który napisał program FAST łączący SIOC z OC z symulatorem Falcon.Na bazie tego programu buduję kokpit F16.W jego programie jest opcja sterowania DED oraz PFL,ale nie działa.Obiecał,że może do tego wróci (obecnie zajęty jest budową domu).
Na viperpits jest teraz w modzie PHCC i pod ten hardware piszą programy.Tak jak wspomniałem nie jestem programistą i jestem skazany na ich pomoc,dlatego gdy coś nie rozumiem to pytam u źródła tzn.programistów.
Teraz parę słów na temat sterowania LCD w FS.Tutaj sytuacja wydaje się łatwiejsza,ponieważ jest gotowe rozwiązanie.Jedno to uproszczone ,które stosuje Zajac z ograniczeniem do 2 LCD (LPT) oraz karta OC na 4 LCD.Można napisać samemu program tak jak robi to codeking.Tyle moich doświadczeń w tym temacie
pozdrawiam,vito_zm

[vito_zm]

Moje gratulacje codeking.Jestem coraz większym optymistą.Ponieważ nic nie robiłem na H44780 to mam kilka trywialnych pytań.Rozumiem,że można kupić alfanumeryczny wyświetlacz z sterownikiem HD44780 w opcji 2x20,4x20 lub innej liczby znaków w zależności od potrzeb?
W Twoim rozwiązaniu musiałeś przejść z interfejsu równoległego na szeregowy RS232.Jak to zrobiłeś,mam na myśli układ scalony.
Ponieważ nie jestem programistą to nie mam pytań związanych z programem.Jestem zainteresowany Twoim pomysłem,ale dla innego symulatora Falcona.Tutaj niestety tylko programista może rozwiązać ten problem.Jest potrzebna umiejętność przechwytywania danych z share memory i ich przesyłanie na port.
Jeśli chodzi o uniwersalny hardware do sterowania LED,LED 7-seg oraz LCD to można to rozwiązać na kilka sposobów.Najprostsze rozwiązanie zastosował OpenCockpits w swojej wersji początkowej kilka lat temu.Była oparta na porcie LPT i ja ją zrealizowałem.Ta wersja jest już przestarzała i należy nowe rozwiązanie oprzeć na porcie USB i tak zrobili w OC.Idea sterowania hardware jest prosta i opiera się na cyklicznym odpytywaniu i wysyłaniu danych.Hardware jest ważne,ale najważniejszy jest program sterujący tym wszystkim.I tutaj SIOC jest tego przykładem.
Wracając do naszych problemów to można pomyśleć o rozwiązaniu codeking,ale cały ciężar tego pomysłu spoczywa na programistach.Jest już pewien postęp i to rokuje nadzieję.
Wracając do interfejsu to można oczywiście zastosować rozwiązanie z RS232,które jest lepsze od LPT.Mam nadzieję,że codeking będzie kontynuował swoje prace i odniesie sukces.

[codeking]

Rozumiem,że można kupić alfanumeryczny wyświetlacz z sterownikiem HD44780 w opcji 2x20,4x20 lub innej liczby znaków w zależności od potrzeb?

Tak, do wyboru jest kilka wersji, przy czym z opisu na stronie http://radzio.dxp.pl/hd44780/4x40/ wynika, że sam sterownik udźwignie max 80 znaków czyli 2x40. 4x40 to już jakby dwa wyświetlacze 2x40 połączone ze sobą, ale nie ma to dużego wpływu na sposób sterowania.

W Twoim rozwiązaniu musiałeś przejść z interfejsu równoległego na szeregowy RS232.Jak to zrobiłeś,mam na myśli układ scalony.

Nic szczególnego nie trzeba robić, uC AVR'y mają wbudowane USART'y czyli obsługę transmisji szeregowej. Jedyną konieczną rzeczą jest przetworzenie sygnału z RS232 tak by był odpowiedni dla AVR. Wykonywane to jest przez mały układzik MAX232. Jest też taki układ dla USB (FT232 czy jakoś tak) ale jeśli się nie mylę to jest układ z wbudowaną przejściówką RS232<>USB.

Jest potrzebna umiejętność przechwytywania danych z share memory i ich przesyłanie na port.

To jest kwestia posiadania gry i wiedzy które offsety czytać.

Jeśli chodzi o uniwersalny hardware do sterowania LED,LED 7-seg oraz LCD to można to rozwiązać na kilka sposobów.

Tak, możliwości jest wiele, mi osobiście podobają się rozwiązania najprostsze i najtańsze, co nie wyklucza, że dobre. Mało elementów i nieskomplikowana budowa i proces uruchamiania (czyli tak jak w przypadku genialnego MJoy'a) powoduje, że wiele osób bez doświadczenia elektronicznego czy programistycznego sobie poradzi.

Wracając do interfejsu to można oczywiście zastosować rozwiązanie z RS232,które jest lepsze od LPT.

I ma tą przewagę, że przejściówki na USB działają

Mam nadzieję,że codeking będzie kontynuował swoje prace i odniesie sukces.

Sukcesem jest to, że dotarłem do tego miejsca A projektu nie zarzucę dopóki nie będzie działał przynajmniej tak, żebym mógł zrealizować swoje pomysły na proste panele do FSX.

[Gerrah]

Codeking, mógłbyś dokładniej opisać jak wygląda komunikacja z HD44780 w twoim rozwiązaniu? Wczoraj napisałem aplikację, która wyciąga z pamięci współdzielonej Falcona tekst z PFL i wyświetla to na LCD 2x24. Jednak w moim rozwiązaniu ja bezpośrednio wysyłam dane do kontrolera (przez LPT). U ciebie muszą one najpierw przejść przez ATtiny2313 i dopiero potem uC przesyła je dalej do LCD. W jakim języku trzeba go programować? Mógłbyś zamieścić jakieś schematy budowy dla swojego rozwiązania? Poza PFL chciałbym zbudować jeszcze DED a i kiedyś może nawet MFD i RWR (czy za pomocą twojego rozwiązania da się pogodzić wyświetlacze alfanumeryczne i graficzne?). Ciekaw jestem też w jakim języku napisałeś swoją aplikację. Nie wiem czy to tylko moje urojenia, ale mało który program do obsługi wyświetlaczy LCD jest napisany w moim ukochanym C++.

[vito_zm]

Witam,
oprócz postów w tym wątku koresponduję z kolegami na priv.Nasuwa się następujący wniosek dotyczący budowy paneli.Czy jest możliwa współpraca lub koordynacja naszych działań.Dobrym przykładem był projekt Damosa,który przy współpracy kilku kolegów został sprawnie zrealizowany.Teraz na tapecie jest wyświetlacz alfanumeryczny HD44780.Z tego co wiem to 2 kolegów próbuje rozwiązać ten problem jeden wykorzystuje interface LPT drugi COM.Następna różnica w projekcie to symulatory FS oraz Falcon.Myślę,że pomimo pewnych różnic w założeniach można zrobić uniwersalny sterownik,który będzie sterował układ HD44780 oraz współpracował z USB.Są uP które mają wbudowany interface szeregowy (USB) np.PIC 16C745.Podobnie można pomyśleć o protokole wymiany informacji PC uP.Pozostają różnice w bloku programowym współpracującym z symulatorami FS oraz Falcon,ale to nie zmienia faktu,że do tego momentu protokół komunikacyjny oraz hardware może być wspólne.W protokole mogą być opcje uwzględniające np.ilość wyświetlanych lini w zależności od zastosowania,ale to są szczegóły.
Moim zdaniem to 90% pracy przy tym projekcie musieliby wykonać programiści programująć uP oraz aplikacje w PC a resztę elektronicy oraz projektanci pcb.Co sądzicie o tym pomyśle?

[Gerrah]

Pomysł jest OK. Cel, pomimo różnych symulatorów, jest ten sam - kilka wyświetlaczy LCD na jednym kablu (i najlepiej USB właśnie, bo ja na przykład COM już nie posiadam a i LPT wychodzi już z użytku). Jak dla mnie problemem może być język w jakim miałoby zostać napisane oprogramowanie. Ja jestem zatwardziałym si plus plusowcem

[codeking]

Wyświetlacz podłączyłem do Attiny2313 wg. opisu na stronie http://radzio.dxp.pl/hd44780/hd44780_avr_4-bit_rw_c.htm. Tam jest też również zamieszczony kod z funkcjami do sterowania wyświetlaczem (kod dla uC) w C i to właśnie C używam do programowania uC. Attiny2313 podpiąłem przez MAX232 do RS232 przy PC. Zrobiłem prosty protokół, który będzie mi też służył do sterowania innymi urządzeniami (diody LED i wyświetlacze LED). Nie wiem jak wygląda sterowanie wyświetlaczami graficznymi, jeśli jest to podobne do HD44780 to nie ma problemu.

Jeśli chodzi o aplikację desktopową to wg. mnie nie ma lepszego narzędzia do szybkiego tworzenia oprogramowania od C# - szybko, prosto i bezboleśnie.

vito_zm - można coś takiego zrobić, trzeba tylko ustalić jak to wszystko ma wyglądać i działać. Stworzyć układ, wsad dla uC i przyjąć jakiś protokół komunikacji z urządzeniem. Moja wiedza dot. uC jest na poziomie sterowania wyświetlaczem i diodami - czyli niewielka (aczkolwiek do prostej zabawy wystarczająca ) USB jest jak najbardziej najlepszym rozwiązaniem ze względu na uniwersalność. LPT rzadko się spotyka. RS232 również, aczkolwiek tu są dostępne przejściówki. Nigdy nie programowałem USB po stronie Windows, może ktoś z forumowiczów ma w tej dziedzinie jakieś doświadczenia. Ale wszystko jest dla ludzi. Jeśli będę w stanie pomóc to chętnie pomogę.

[damos]

Witaj Gerrah! Ciesze się, że w końcu odezwałeś się w tym wątku !

Co sądzicie o tym pomyśle?

Jak już wiesz - jestem jak najbardziej "za". Tym bardziej, że uniknęło by się dublowania pracy i stworzenia kilku niekompatybilnych rozwiązań.

Pomysł jest OK. Cel, pomimo różnych symulatorów, jest ten sam - kilka wyświetlaczy LCD na jednym kablu

Tylko wyświetlaczy? Można by od razu dodać jeszcze trochę diod.

  najlepiej USB właśnie, bo ja na przykład COM już nie posiadam a i LPT wychodzi już z użytku

IMHO wniosek oczywisty. USB jest obecnie najbardziej uniwersalną magistrala.

Jak dla mnie problemem może być język w jakim miałoby zostać napisane oprogramowanie. Ja jestem zatwardziałym si plus plusowcem

a to akurat zaleta jeśli znasz QT to można zrobić coś multiplatformowego. Warstwa software'u komunikująca się ze sprzętem POWINNA być napisana w C++. Programowanie mikrokontrolera to tez C++ lub C. Po zdefiniowaniu protokołu komunikacji z modułem sterującym graficzne nakładki można by robić w dowolnym języku: (C++ , C#, VB, Java, Python, Perl ....) BTW - używasz boost'a i template'ów ?

Jeśli chodzi o aplikację desktopową to wg. mnie nie ma lepszego narzędzia do szybkiego tworzenia oprogramowania od C# - szybko, prosto i bezboleśnie.

Z pewnością jest to bardzo efektywne narzędzie do robienia wszelkiego rodzaju programów narzędziowych dla Windows. Szybko, łatwo i wygodnie.

Nigdy nie programowałem USB po stronie Windows, może ktoś z forumowiczów ma w tej dziedzinie jakieś doświadczenia.

  USB jest dość złożoną materią (właśnie dla celów mojego projektu  przymierzam się do przenośnej biblioteki do obsługi USB - wygląda obiecująco: "libusb" oraz "libusb-Win32" ). Jeśli chodzi jedynie o wyświetlanie czegoś na kilku wyświetlaczach LCD, to można pójść "na skróty" i użyć prymitywnej implementacji USB na Atmega16. Planowałem sobie coś innego, ale to z pewnością będzie szybsze do zrobienia. Jeśli HD44780 używa zewnętrznej linii strobującej i nie jest wrażliwy na spowolnienia transmisji, to powinno być możliwe obsłużenie kilku wyświetlaczy LCD za pomocą jednej Atmegi podłączonej do USB.

Może jednak umówić się na jakiś chat i porozmawiać o celach działania i zasobach ludzkich? Kto co może zrobić? Ile ma czasu? Jakie ramy czasowe sobie stawiamy? Czy ma być to jeden zryw, czy coś dłuższego? Tylko LCD, czy coś więcej? Open source czy nie? Multiplatform, czy nie? Poziom kompatybilności z innymi platformami i jakieś protokoły... Co wy na to?

Namawiał bym na wieloplatformowość i OpenSource - wtedy mamy szanse na pomoc ze strony ogromnej rzeszy programistów.
Z innej beczki: dobry protokół komunikacji między hostem sterującym urządzeniem a światem zewnętrznym (inne aplikacje, symulatory itd) to... sockety (!) w Linuxie to działa doskonale i gwarantuje 100% separację (logiczna i binarną) oraz niezwykłą elastyczność. A może działać nawet pomiędzy różnymi kompami...

[codeking]

Wiele pytań i wiele do ustalenia, trzeba jednak wziąć pod uwagę to, aby nie tworzyć przesadnie skomplikowanego i ograniczonego rozwiązania, ani nie kopiować OC czy FSBUS. Wg. mnie to prostota wykonania (dla budowniczych tzn. płytka + wgranie wsadu = gotowe urządzenie) i uniwersalność jest najważniejsza. Trzeba by zacząć zastanowić się od najniższego poziomu - sprzęt, biorąc pod uwagę stopień skomplikowania jego programowania. No i jakie moduły, proponuję sterownik dla kilku LCD na HD44780 (małe Attiny2313 bez problemu poradzi sobie z kilkoma takimi wyświetlaczami), matryca diód LED i wyświetlacze 7-segmentowe LED. Tylko czy ma być centralka do której podpinamy takie moduły czy może każdy moduł jest samodzielny. W takich projektach najgorzej jest zacząć. Przyjęcie jakiegoś jednego rozwiązania i trzymania się go do końca to jest chyba klucz do powodzenia projektu (oczywiście nie wykluczając ew. poprawek gdy wystąpią poważne problemy projektowe).

Sockety - to jest OK, urządzenia podpinane do sieci Ethernet Ha, to było by ciekawe rozwiązanie i niesamowicie uniwersalne!

[damos]

prostota wykonania (dla budowniczych tzn. płytka + wgranie wsadu = gotowe urządzenie) i uniwersalność jest najważniejsza.

Oczywiście, że to jest klucz! Ilość elementów dyskretnych w rozwiązaniach OC jest zbyt duża. Im więcej można upchnąć w oprogramowaniu kości i sofcie - tym lepiej.

Sockety - to jest OK, urządzenia podpinane do sieci Ethernet Ha, to było by ciekawe rozwiązanie i niesamowicie uniwersalne!

Nie do końca. Stacki TCP w mikrokontrolerach maja ograniczoną ilość równoczesnych połączeń. Myślałem o tym, że oprogramowanie kontrolujące hardware jest dostępne poprzez TCP - działa jak serwer (jak X'y i GL pod linuxem). Sam hardware jest kontrolowany przez USB. Jednak spokojnie całość może siedzieć na innym kompie niż sam symulator i komunikować się po TCP.

[codeking]

Nie do końca. Stacki TCP w mikrokontrolerach maja ograniczoną ilość równoczesnych połączeń. Myślałem o tym, że oprogramowanie kontrolujące hardware jest dostępne poprzez TCP - działa jak serwer (jak X'y i GL pod linuxem). Sam hardware jest kontrolowany przez USB. Jednak spokojnie całość może siedzieć na innym kompie niż sam symulator i komunikować się po TCP.

OK, rozumiem.

Może przez najbliższe dni zebrać różne pomysły co i jak itd. a później wybrać najlepsze pomysły i połączyć je w jedno rozwiązanie, rozdzielić pracę i do dzieła.

[damos]

Tak łatwo nie będzie Nie obejdziemy się bez fazy R&D oraz "proof of concept". Jednak należy zacząć od założeń...
Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn. To budzi pewne obawy odnośnie poprawności zdefiniowanych protokołów i interface'ów.

I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej Mnie bardziej bawi tworzenie więc dla mnie to nie problem. A dla was?

[some1]

Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn.

Jakby kogoś interesował FSX (może w ograniczonym stopniu FS2004) to służę. Ale nie śledzę wątku regularnie, "o so chodziiii"?

[vito_zm]

Witam ponownie,
cieszę się,że pomysł znalazł akceptację.Szkoda,że nie mogę pomóc w dziedzinie oprogramowania chociaż mam ogólne pojęcie.Jeśli chodzi o hardware OC to zrobiono na początku prosty projekt oparty o technikę dyskretną.Następnie powstawały nowe pakiety,które były oparte o uP i rozszerzały możliwości systemu (USB Expansion) lub zastępowały stare karty (Display II) lub były nowymi kartami do sterowania innych układów wykonawczych.Nie chcę bronić rozwiązań OC,ale ich siła to soft,hardware to sprawa drugorzędna (tak mi się wydaje).Jeśli przeciętny użytkownik potrafi napisać skrypty w SIOC ta dobrze świadczy o programie.
Jeszcze jedna uwaga co do ich rozwiązań.Mają pakiety,które pracują autonomicznie np.USB LCD.
Obserwuję na viperpits,że tworzą system otwarty to co sugeruje Damos ale pod PHCC w języku C++
http://www.viperpits.org/smf/index.php?topic=3962.0
Nie wchodziłem w szczegóły,ale  hardware jest podzielone na płytę matkę oraz córki.Programy piszą niektórzy członkowie forum.
Wracając do naszego podwórka,czy nie można na początek zrobić jeden moduł do sterowania jednego lub paru HD44780 ale komunikującego się z pc przez USB.Można oczywiście pomyśleć także o sterowaniu LED czy 7-seg.przy wykorzystaniu tego samego sterownika lub zaprojektować nowy tak jak to robią w OC.
Przykład prostego rozwiązania to G15 Viper (soft).Jest możliwość wyboru DED lub PFL gdzie sterownik komunikuje się z pc przez USB.Sterownik oraz soft jest tylko do wyświetlania tych parametrów.Podobnie można zrobić dla FS.Jest to tzw.dekompozycja projektowania,czyli proste funkcjonalne moduły(podobnie robi OC).
Pytanie dla nas czy jesteśmy w stanie zrobić projekt kompleksowy,czy raczej na początek zrobić moduł do sterowania kilkoma LCD?
ps
zauważyłem post Damosa i odpowiadam.Damos już o tym kiedyś pisał projektowanie to wiedza oraz dosyć drogi sprzęt.Możemy ten projet potraktować jako zabawę lub hobby,dlatego sugeruję zrobienie prostego modułu opartego na USB i zobaczymy co z tego wyniknie.Jeśli ktoś poważnie myśli o zrobieniu kokpitu to trzeba szukać gotowych rozwiązań.Natomiast ma to sens jeśli robimy tylko panele a nie cały kokpit.

[Gerrah]

Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn. To budzi pewne obawy odnośnie poprawności zdefiniowanych protokołów i interface'ów.

To IMHO zupełnie inna sprawa. Ja także nie mam pojęcia o innych simach niż Falcon. Głównym problemem byłoby napisanie API do obsługi wyświetlaczy LCD (alfanumerycznych i graficznych) czy też segmentowych. Potem każdy mógłby je zastosować do swoich potrzeb.

I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej Mnie bardziej bawi tworzenie więc dla mnie to nie problem. A dla was?

Jako że programuję czysto hobbystycznie to dla mnie również to nie problem. Nie ukrywam, bardziej pociąga mnie korzystanie z efektów własnej pracy, nie cudzej