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

[vito_zm]

Witam,
cytat Damos

I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej

Jest to prawda już to zrobiono i na pewno jest to kontynuowane.Jest na naszym forum od miesiąca nowy kolega,który ma największe doświadczenie w dziedzinie budowy kokpitów.Kończy realizację kokpitu dla A320 oraz rozpoczął budowę kokpitu dla Falcona.Mam nadzieję,że włączy się do dyskusji.
Wracając do pytania co chcemy zrealizować to powiem tak to co jest realne.Dla prostego panelu wystarczy MJoy oraz sterowanie kilkoma LED,7-seg oraz 2,3 LCD.I to można zrobić amatorsko w stosunkowo krótkim czasie.Projekty kokpitów to już inna bajka.
Kokpit Falona to już kilkadziesiąt przycisków,przełączników wyświetlaczy LED, wyświetlacze graficzne LCD oraz MFD,Pozostałe wskaźniki można także zrealizować na LCD 3.4",10.4","8". Aby to uruchomić to trzeba kilku niezależnych programów.Jest to przykład korzystania z gotowych rozwiązań.
Chcąc zrealizować w sensownym czasie jakiś projekt to oprócz założeń technicznych ważny jest czas.Po drugie trzeba wykorzystać zasoby,które są dostępne.W naszym przypadku dotyczy to głównie programistów.Wyspecjalizowanie się w projektowaniu uP w C++ to nie tylko znajomość języka,ale także znajomość stuktury procesora (manuale to powyżej 200str).Aby zrobić efektywny program to trzeba mieć praktykę w tworzeniu algorytmów.
Do czego zmierzam, należy programować w tym języku,który znacie oraz projektować na uP,które także znacie.
Co do mnie o jestem zwolennikiem budowy sterownika dla  HD44780 z interfejsem USB.Dlaczego,odpowiedź jest prosta.Zakup wskaźnika DED na viperpits wymaga sporej gotówki,podobnie jest z projektem opartym na klawiaturze Logitech G15.
Jeśli jest potrzebne wsparcie w postaci zapytania o jakiś szczegół dotyczący projektu dla falcona to mogę zapytać na forum viperpits.

[vito_zm]

Uzupełnienie do ostatniego post.
Przejrzałem schemat karty USB LCD z OC i muszę stwierdzić,że zrobili bardzo dobry projekt.Karta jest zrobiona z uP 16C745 z wbudowanym USB oraz 2 buforami 74HC541.Można sterować 4 HD44780 multipleksując linie E.OC udostępnia kod wynikowy i można robiąc deasemblację zobaczyć jak zrobiono program z poziomu asemblera.Zapytałem kolegę czy jest wsparcie programowe dla PIC i otrzymałem odpowiedź

Microchip daje kompletne darmowe zintegrowane środowisko dla programowania w asemblerze. Jest to MPLAB:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002
edytor, assembler, debuger, symulator itd. Można dokupić do tego np. kompilatory C. Można też programować kości, jeśli programator jest kompatybilny z MPLABem.
Fajne jest to, że większość programów można napisać i uruchomić (za symulować) zanim jeszcze powstanie hardware

Ponieważ nikt z forum nie zna PIC to pozostają inne uP oraz programowanie z poziomu C++.Można zrobić podobny projekt z sprzętowym interfejsem USB.Co wy na to?

[damos]

Spróbuję z software'owym interface'm USB an ATmega16... Najtańszy wariant. Jednak jakieś wyniki najwcześniej po weekendzie. To będzie tylko proof-of-concept. Docelowo też myślałem o kluczowaniu po linii E i sterowaniu kilku LCD równocześnie przez bufor

[vito_zm]

Dzięki Damos jest nadzieja,że temat będzie rozwijany.Gdyby się udało zrealizować USB na ATmega16 byłoby super.Projekt byłby podobny do OC,ale na znanym uP.Trzymam kciuki
pozdrawiam,vito_zm

[damos]

To wypali pod warunkiem, że HD44780 jest odporny na chwilowe przerwy w komunikacji. Jeśli przyjdzie coś z USB podczas zapisu do wyświetlacza - zapis zostanie na chwilę wstrzymany. Jeśli to nie problem - jest szansa. Może ktoś ma doświadczenie z timingiem tego display'a ?

[vito_zm]

Rozumiem,że chodzi o to,że jeśli podczas zapisu będzie przerwanie od USB to zapis może być "zakłócony" ze względu na priorytet przerwania.Jeśli o to chodzi to jest prosta metoda zrobienia bufora albo wew.uP,albo na zew.z zapisem zboczem.Do zapisu zew.bufora potrzeba dla układów HT kilka ns.Nie wiem czy dobrze zrozumiałem pytanie.
W rozwiązaniu OC dane do HD44780 są brane prosto z portu uP.Nie wiem jak często są odświeżane 4 LCD w ich rozwiązaniu.

[damos]

To nie jest stricte "zakłócenie" a jedynie wstrzymanie wykonywania kodu. Po prostu - czasem przerwy w wysyłaniu danych do wyświetlacza mogą być dłuższe niż wynikało by to z kodu. Jeśli protokół przewiduje ustawienie danych na odpowiednich liniach i zatrzaśnięcie ich chwilowym stanem niskim/wysokim na innej linii, to nie będzie gwarancji maksymalnego czasu miedzy kolejnymi strobe'ami. Nie będzie problemu z zawartością wysyłanych danych. Jeśli protokół nie jest "time critical" to nie będzie problemu.

[vito_zm]

Witam,
kiedyś zapytałem twórcę programu FAST,który pośredniczy pomiędzy Falconem a SIOC wykorzystując rozwiązanie OC podobne do naszego

mihi4 you wrote in your manual about DED and PFL.I mean it is possible
to use FAST to control them but which hardware should I use?
greetings,vito_zm

odpowiedź

Yes, the data is there. But since the IOCProtocol works with changing stats
of variables, other than continuously updated data, it doesn't work very
well without some programming knowledge. For a working and simple DED/PFL
solution I would recommend Airdance's G15/Z10 solution

Może ta odpowiedź coś Tobie podpowie.Ja się domyślam,że te problemy wynikały może z tego,że SIOC reaguje na zdarzenia tzn.porównuje zapisane stany w pamięci współdzielonej (share memory w Falconie) w czasie cyklicznego jej sprawdzania.Jeśli nastąpiła zmiana to wysyła dane na peryferial,jeśli nie to dane pozostają bez zmian.HD44780 musi mieć co jakiś czas odświeżanie jeśli pracuje w opcji multipleksowania.Może to był powód problemów mihi4.
Myślę,że testy Gerrah mogą odpowiedzieć na te wątpliwości,chociaż warunki są inne,ponieważ nie ma multipleksowania LCD.

[Gerrah]

U mnie właśnie dane do LCD są wysyłane tylko jeśli zmienił się stan zmiennych w pamięci współdzielonej (co 50ms). Odświeżać wyświetlacza w moim przypadku nie muszę. Raz zapisane dane w pamięci kontrolera są wyświetlane aż do odłączenia zasilania lub wysłania innego rozkazu.

[vito_zm]

Jest to dobra wiadomość.Czy możesz potwierdzić,że Twój program przepytuje co 50 ms dane (PFL) w RAM pod adresem gdzie są zapisane i jeśli się zmieniły to wysyłasz je do kontrolera?Tak działa SIOC,reaguje na zmiany.Jeśli Damos zaprogramuje USB w uP to mamy prawdopodobnie rozwiązanie podobne do OC.
Problem odświeżania będzie aktualny gdy będzie multipleksowanie np.4 LCD,ale to można rozwiązać.
ps
Co do USB w uP to czy nie można zrobić deasemblacji programu wynikowego MJoya i zobaczyć jak to rozwiązano?Nie wiem jak wygląda sprawa praw autorskich?

[damos]

Raz zapisane dane w pamięci kontrolera są wyświetlane aż do odłączenia zasilania lub wysłania innego rozkazu.

I to jest logiczne - po to jest kontroler "on-board" aby zapamiętać wprowadzony tekst.
Gerrah - możesz zrobić kilka eksperymentów i wpakować jakieś duże delay'e do procedury przesyłającej dane do wyświetlacza ? Jeśli kontroler display'a czeka do skutku na kolejne dane (nie ma timeout'a) - to jesteśmy dużo bliżej

Problem odświeżania będzie aktualny gdy będzie multipleksowanie np.4 LCD,ale to można rozwiązać.

Nawet wtedy nie bedziemy mieć problemu z odświeżaniem.

Co do USB w uP to czy nie można zrobić deasemblacji programu wynikowego MJoya i zobaczyć jak to rozwiązano?

Nie.... Mam źródła, widziałem stack USB z MJoya i skłaniam się ku innemu rozwiązaniu Cierpliwości...

[Gerrah]

Nie wiem co masz na myśli przez "duże delay", ale 1000s nie robi na nim wrażenia. Gorzej jeśli w tym czasie zostanie coś innego przesłane. Jak łatwo się domyśleć "oczekujący" znak nie zostanie wyświetlony.

[Galimex]

Witam
Trochę kombinuje z OC na płytkach uniwersalnych pod FSX
Jakoś to wyglądało do momentu zerwania kontaktu z posiadaczem programatora do mikro-kontrolerów a na wydatek +100zł mnie na dzień dzisiejszy nie stać.

[damos]

Nie wiem co masz na myśli przez "duże delay", ale 1000s nie robi na nim wrażenia.

No to jestesmy w domu   Myślałem o delay'u rzędu 10-100 ms. W niektórych kontrolerach masz ograniczoną ilość czasu pomiędzy kolejnymi transferami danych. Np. karty chipowe wymagają podawania danych z zegarem nie mniejszym niż ustalony w dokumentacji (np. 1 MHz). Jeśli na chwile wstrzymasz transmisję to tracisz synchronizację i musisz nawiązywać połączenie na nowo...

Gorzej jeśli w tym czasie zostanie coś innego przesłane.

To absolutnie nie będzie miało miejsca.

[Gerrah]

Muszę tylko ostrzec, że u mnie LCD działa na kontrolerze KS0066U. Niby jest zgodny ze standardem HD44870, ale nigdy nic nie wiadomo.