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

[zajac]

Jeżeli chodzi o współpracę tego układu z FS-em a dokładnie poprzez dodatek FSUIPC to znalazłem coś takiego - http://www.schiratti.com/files/dowson/FSUIPC_SDK.zip?timestamp=010309 - może się przydać przy pisaniu programu / dla mnie to czarna magia  /, ale jak będę mógł pomóc np. przy pcb to natychmiast.

pozdrawiam Zając

[vito_zm]

ale jak będę mógł pomóc np. przy pcb to natychmiast

Jestem pewien,że będziesz potrzeby w tym temacie.Gdy powstanie schemat sterownika to uzgodnimy szczegóły.

[zajac]

Ok czekam na wieści 

Zając

[damos]

Jest pewien progress - mam kod obsługujący za pomocą ATmega16 maksymalnie 21 wyświetlaczy alfanumerycznych zgodnych z HD44780 - wystarczy tyle ? (można by 25 przy 4-ro bitowym protokole, ale będzie wolniejsze ze względu na protokół.). Prawdopodobnie trzeba będzie dodać jakiś bufor magistrali, aby mógł prądowo obsłużyć 21 odbiorników (wyświetlaczy), ale to nie problem. Dojdą 3 dość tanie układy scalone.
Czy ktoś z kolegów ma kilka wyświetlaczy i możliwość zbudowania układu prototypowego? Pewnie vito_zm byłby najlepszym kandydatem
Teraz muszę jedynie zdefiniować protokół przez warstwę transportu USB, obsłużyć go (to raczej prosty task), zrobić sterownik na PC i będzie gotowe do normalnych testów.

[damos]

Pierwsza wersja gotowa:
- protokół USB zdefiniowany
- obsłużony w urządzeniu
- obsłużony na PC
- prosta aplikacja testowa gotowa i przetestowana
- wykonany test na każdym z 21 wyświetlaczy (oczywiście - za każdym razem ten sam, tylko podpinany pod inne sterowanie )


teraz zostało najtrudniejsze: zrobić schemat i wysłać do vito_zm w celu wykonania niezależnego testu

[vito_zm]

Miałem problemy z komunikacją z forum,dlatego tak późno wysyłam post.Gratulacje Damos,podeślij mi szkic schematu.Ile potrzebujesz wyświetlaczy i ile wyświetlanych linii.Postaram się kupić w sklepie elementy i zrobię model na płycie uniwersalnej.

[vito_zm]

Wysłaliśmy post w tym samym czasie.Zrób odręczny szkic oraz jego zdjęcie i prześlij jako załącznik.
Jeszcze raz gratuluję i życzę miłego snu.

[damos]

ok, schemat jest tu:
http://www.damos.k11.pl/LO/lcd_avr/ATMega16_USB_LCD.png
wsad do ATMega16 tu:
http://www.damos.k11.pl/LO/lcd_avr/dm_firmware.hex
(uwaga - zegar 16MHz więc CKOPT)
aplikacja testowa tu:
http://www.damos.k11.pl/LO/lcd_avr/TestApp.exe
i sterowniki do USB, które należy zainstalować tu:
http://www.damos.k11.pl/LO/lcd_avr/libusb-win32-filter-bin-0.1.12.1.exe

Dobrze by było zobaczyć, czy program odpali się bez instalacji sterowników, jedynie z użyciem dll'a:
http://www.damos.k11.pl/LO/lcd_avr/libusb0.dll

Teraz kilka słów objaśnień.
1 - schemat
- przycisk RESET nie jest konieczny
- rezystor R3 (1M) nie jest konieczny -dałem go, żeby mi D+ nie pływało - tak na wszelki wypadek
- diody D1 i D2 MUSZĄ być diodami zenera na 3,3V
- R1 i R2 powinny mieć 68 ohm, ja miałem tylko 100 ohm i działa bez problemu
- C1 i C4 (elektrolit + ceramiczny) nie są konieczne, lecz dałem je na wszelki wypadek, aby nie mieć problemów z zakłóceniami. Należy je umieścić jak najbliżej IC1
- uwaga na linie z USB: D+ i D-, nie można ich zamieniać. D+ musi być podłączona do PD2, a D- do PD4. Po płytce MJoy'a można dojść, które wyjścia z gniazda USB są które: D- jest podciągana rezystorem 1K5 do plusa.
- IC2 i IC3 - nie podłączałem ich, jako, że mam tylko jeden wyświetlacz - sterowałem go bezpośrednio z portów uP
- LCD1 - LCD21, to symbolicznie pokazane złącza na wyświetlaczach. Jak widać większość linii jest połączona równolegle (współdzielona), za wyjątkiem pinu nr 6 (linia "E"), który jest odpowiedzialny za "selekcję" wyświetlacza, który ma w danym momencie odbierać dane. Potencjometr jest przykładowo, ja mam chyba 3 kilowy rezystor - zależy od wyświetlacza. Złącze na górze ekranu jest czysto symboliczne i pokazuje do których pinów uP należy podłączać linie "E" kolejnych wyświetlaczy. Oszczędziłem sobie dzięki temu umieszczania na schemacie kolejnych 19-tu złączy LCD... Kolejność jest następująca: pierwszych 8 LCD do PA0-PA7, następne 8 do PB0-PB7, ostatnie 5 to PD0,PD1,PD3,PD5,PD6.
Zasilanie... nie wiem, czy USB "pociągnie" 21 LCD - prawdopodobnie nie. Dlatego umieściłem osobne VCC. Jednak ja zasilałem układ z USB

2 - drivery:
- załączyłem instalkę lib-usb. Teoretycznie aplikacja testowa może działać bez tej instalacji, wymaga jedynie obecności załączonego dll'a. Nie testowałem jeszcze tego wariantu.

3 - program w uP:
obsługuje 21 wyświetlaczy zgodnych z HD44780. Jak się okazuje, z tą zgodnością różnie bywa. Mój wyświetlacz obsługuje tryb 2 linii.... w ten sposób, że każda linia ma 8 znaków i są umieszczone jedna za drugą w ... jednej linii ! Bo sam wyświetlacz pokazuje jedynie jeden wiersz tekstu. I jest to zgodne z HD44780. Nie testowałem kodu na wyświetlaczu 4-ro liniowym ani prawdziwie - 2 liniowym, z 40-toma znakami na linię (bo takich nie posiadam). Nie mam supportu (na razie ?) dla wyświetlaczy z dwiema liniami "E". Oprogramowanie na razie nie supportuje scrollowania okna ani zapisywania własnych fontów, ale to drugie jest w planie Jeśli chodzi o USB, to korzystam jedynie z transmisji kontrolnych (usb_control_msg) a nie z raportów HID. Tak więc nie ma sensu podłączać się do tego "Generic Hid Testerem".


4 - program na PC:
jest to prosty, testowy programik zawierający combo-box'a oraz 4 pola edycyjne. Za pomoca combo wybierasz nr wyswietlacza (od 0 do 20) a w polach tekstowych wpisujesz tekst, który pojawia się na wyświetlaczu. W moim przypadku, przy podłączeniu linii E wyświetlacza do PA0 (nóżka nr 40), wybieram na combo "LCD0" i następnie w "Line0" wpisuję pierwsze 8 znaków a w "Line1" kolejne 8 znaków. W ten sposób zapełniam wyświetlacz (16 znaków). I faktycznie na takim działaniu ma polegać testowanie Oczywiście  - przedtem należy podłączyć układ do USB !
Gdyby program nie odpalał się z braku dll'i typu MSVCRT*.* czy podobnych, daj znać, wtedy je dorzucę (jednak jest prawdopodobne, że już je masz). Naturalnie - finalny interface będzie zupełnie inny !

To chyba wszystko, co przychodzi mi teraz do głowy.... w razie pytań - nie krępować się

[vito_zm]

Dzięki Damos za dokumentację.Przystępuję do działania.Będę informował o wynikach.

[codeking]

ok, schemat jest tu:
http://www.damos.k11.pl/LO/lcd_avr/ATMega16_USB_LCD.png

Czy te ULN'y są naprawdę konieczne ? Prąd na wyjściach uP do wyświetlaczy idzie tylko gdy trzeba wysłać jakiś rozkaz, no i nie musi on być szczególnie duży. Jeśli się mylę to proszę o poprawkę.

aplikacja testowa tu:
http://www.damos.k11.pl/LO/lcd_avr/TestApp.exe

Jakiego interfejsu można się spodziewać ? Z mojego punktu widzenia najlepsza byłaby statyczna biblioteka z funkcjami (wyeksportowanymi) do obsługi wyświetlaczy. Nie wiem jakie przewidujesz metody, w moim prostym rozwiązaniu były praktycznie dwie główne: czyść ekran i pisz znak C na X i Y. Metodę czyść można zrealizować tą drugą ale HD44780 ma rozkaz Clear i działa on w tym przypadku szybciej. Pytam o to, bo chciałbym dodać obsługę tych wyświetlaczy do swojego programu. A w C# wystarczy znać deklarację metod i po sprawie (nie lubię gdy na komputerach zwykłych użytkowników trzeba rejestrować jakieś biblioteki (ActiveX itp.)).

Dobrze by było zobaczyć, czy program odpali się bez instalacji sterowników, jedynie z użyciem dll'a:
http://www.damos.k11.pl/LO/lcd_avr/libusb0.dll

Byłoby super gdyby nie trzeba było instalować sterowników, w końcu do HID.

Zasilanie... nie wiem, czy USB "pociągnie" 21 LCD - prawdopodobnie nie. Dlatego umieściłem osobne VCC. Jednak ja zasilałem układ z USB

Czy tryb USB, który daje 500mA nie da rady ? Nie wiem ile taki wyświetlacz potrzebuje, chociaż licząc samo podświetlenie wyświetlaczy to może dać kilkaset mA. Fajnie gdy nie był potrzebny zewnętrzny zasilacz, aczkolwiek to sprawa mało istotna.

3 - program w uP:
obsługuje 21 wyświetlaczy zgodnych z HD44780. Jak się okazuje, z tą zgodnością różnie bywa. Mój wyświetlacz obsługuje tryb 2 linii.... w ten sposób, że każda linia ma 8 znaków i są umieszczone jedna za drugą w ... jednej linii ! Bo sam wyświetlacz pokazuje jedynie jeden wiersz tekstu. I jest to zgodne z HD44780.

Ciekawe Kod do obsługi LCD pisałeś sam czy może korzystałeś ze strony http://radzio.dxp.pl/hd44780/ ? Jest tam zaimplementowana metoda coś jak GotoXY, która przesuwa kursor w odpowiednie miejsce. Może to jakoś pomoże.

Nie mam supportu (na razie ?) dla wyświetlaczy z dwiema liniami "E".

Taki wyświetlacz podpina się chyba jako dwa, używając tych samych linii oprócz "E".

Oprogramowanie na razie nie supportuje scrollowania okna ani zapisywania własnych fontów, ale to drugie jest w planie

Definiowanie własnych fontów jest OK, co prawda ilość znaków jest ograniczona ale zawsze coś. Co do scrollowania to można to zrzucić na programistów konkretnych aplikacji

4 - program na PC:
jest to prosty, testowy programik zawierający combo-box'a oraz 4 pola edycyjne. Za pomoca combo wybierasz nr wyswietlacza (od 0 do 20) a w polach tekstowych wpisujesz tekst, który pojawia się na wyświetlaczu. W moim przypadku, przy podłączeniu linii E wyświetlacza do PA0 (nóżka nr 40), wybieram na combo "LCD0" i następnie w "Line0" wpisuję pierwsze 8 znaków a w "Line1" kolejne 8 znaków. W ten sposób zapełniam wyświetlacz (16 znaków). I faktycznie na takim działaniu ma polegać testowanie

Tutaj zapytam o to co wspomniałem wcześniej: czy będzie możliwość pisania znaku na wybranej pozycji X, Y ?

[damos]

Czy te ULN'y są naprawdę konieczne ? Prąd na wyjściach uP do wyświetlaczy idzie tylko gdy trzeba wysłać jakiś rozkaz, no i nie musi on być szczególnie duży. Jeśli się mylę to proszę o poprawkę.

Na szynie danych WSZYSTKIE wyświetlacze pobierają prąd. Maksymalne obciążenie jednego portu w ATMega to 40 mA. Przy 21 wyświetlaczach daje to 1.9 mA na LCD. To przemnożone przez ilość odbiorników daje peek minimalnie poniżej 360 mA - czylu USB jeszcze dycha... Jak jeden pin pobierze więcej - mamy kłopoty - z dymem idzie ATMega.

Jakiego interfejsu można się spodziewać ? Z mojego punktu widzenia najlepsza byłaby statyczna biblioteka z funkcjami (wyeksportowanymi) do obsługi wyświetlaczy.

STATYCZNA ? Przypominam, ze ja piszę w C++. Chcesz do C# linkować lib'a z C++? Z tego, co wiem - to nie wypali. Lepiej już biblioteka dynamiczna (*.dll). Jednak osobiście skłaniam się serwisowi/samodzielnej aplikacji , która będzie komunikować się "ze światem" po TCP i (ewentualnie) named pipes. Będzie też mieć wbudowany własny mini-serwer WWW do konfiguracji i testowania wyświetlaczy. Oczywiście - w przyszłości będzie mogła kontrolować więcej rzeczy niż tylko wyświetlacze.

  Nie wiem jakie przewidujesz metody, w moim prostym rozwiązaniu były praktycznie dwie główne: czyść ekran i pisz znak C na X i Y.

Układ ma reprezentować 21 "virtualnych" wyświetlaczy LCD z płaskim adresowaniem linii. Wysyłasz komendę wyczyszczenia lub ustawienia tekstu podając wiersz i kolumnę oraz ciąg znaków do wpisania. Program sam ustala, jaki tekst uległ zmianie i co wysłać przez USB i w jaki sposób. Można by pomyśleć również o definiowaniu własnych  obszarów wewnątrz wyświetlaczy (identyfikowanych przez ID) i wysyłaniu tekstu do nich. Takie ID obszaru definiowało by jednoznacznie wyświetlacz i zakres znaków na nim. Wtedy wysyłasz jedynie ID obszaru, adres początkowy i string. (zawijanie tekstu wewnątrz obszaru i brak możliwości wyjścia tekstu po za zdefiniowany obszar, indywidualne czyszczenie całego obszaru).

Metodę czyść można zrealizować tą drugą ale HD44780 ma rozkaz Clear i działa on w tym przypadku szybciej.

Implementacja tego to jedna z pierwszych rzeczy, jakie zrobiłem.

w C# wystarczy znać deklarację metod i po sprawie

Tylko w przypadku DLL'i. Mój Lib ci nic nie da. Ponadto po stronie "sterownika" chcę pamiętać treść wyświetlacza (detekcja zmian, definiowanie obszarów) i wysyłać dane w osobnym wątku (nadawca nie czeka na wysłanie danych do LCD) - więc potrzebuję osobnego procesu.

(nie lubię gdy na komputerach zwykłych użytkowników trzeba rejestrować jakieś biblioteki (ActiveX itp.)).

Apage satanas! Jakie ActiveX'y !?

Byłoby super gdyby nie trzeba było instalować sterowników, w końcu do HID.

Może później. Pisałem, że nie korzystam z raportów HID a jedynie transmisji kontrolnych.  Do kompilacji modułu używającego deskryptorów HID muszę mieć DDK. DDK, który jako taki nie jest już dystrybuowany. O DDK trzeba żebrać w M$ o WDK , rejestrować się, ściągać kilkaset MB itd. innego na W2K, XP itd. Dodatkowo to działa tylko na "Wingrozie". Do zrobienia, ale później. Moim celem jest uzyskanie wieloplatformowości, co daje niezwykle prosty w instalacji lib-usb.

Czy tryb USB, który daje 500mA nie da rady ? Nie wiem ile taki wyświetlacz potrzebuje, chociaż licząc samo podświetlenie wyświetlaczy to może dać kilkaset mA. Fajnie gdy nie był potrzebny zewnętrzny zasilacz, aczkolwiek to sprawa mało istotna.

Fajnie by było, ale na jeden wyświetlacz zostaje wtedy jakieś 19 mA. Może wystarczy?

Ciekawe Kod do obsługi LCD pisałeś sam czy może korzystałeś ze strony http://radzio.dxp.pl/hd44780/ ? Jest tam zaimplementowana metoda coś jak GotoXY, która przesuwa kursor w odpowiednie miejsce. Może to jakoś pomoże.

Swój kod oparłem na jego kodzie, ale musiałem usunąć bugi w f-cji "_LCD_Write" (złe timingi) i przerobić na obsługę wielu wyświetlaczy. GotoXY to nic innego jak wyliczanie adresu komórki, pod który trafią dane. Używam tego. Tam nie ma żadnej logiki robiącej z 2 linii jedną. Poprostu adres pierwszych 8-miu znaków to 0x00 a adres następnych 8-miu znaków tej samej linii to 0x40.

Taki wyświetlacz podpina się chyba jako dwa, używając tych samych linii oprócz "E".

Najprawdopodobniej masz rację

Definiowanie własnych fontów jest OK, co prawda ilość znaków jest ograniczona ale zawsze coś. Co do scrollowania to można to zrzucić na programistów konkretnych aplikacji

Też tak uważam.

Tutaj zapytam o to co wspomniałem wcześniej: czy będzie możliwość pisania znaku na wybranej pozycji X, Y ?

Oczywiście, ze tak. Inaczej się nie da. Jeden znak zapiszesz, jeśli wyślesz string o długości 1.

[codeking]

Na szynie danych WSZYSTKIE wyświetlacze pobierają prąd.

No chyba że tak.

STATYCZNA ? Przypominam, ze ja piszę w C++. Chcesz do C# linkować lib'a z C++?

Przepraszam, pomyliłem się. Chodzi mi o to aby nie tworzyć biblioteki "rejestrowanej" (COM, ActiveX itp.) tylko zwykłą DLL (jak w WinAPI).

Jednak osobiście skłaniam się serwisowi/samodzielnej aplikacji , która będzie komunikować się "ze światem" po TCP i (ewentualnie) named pipes. Będzie też mieć wbudowany własny mini-serwer WWW do konfiguracji i testowania wyświetlaczy. Oczywiście - w przyszłości będzie mogła kontrolować więcej rzeczy niż tylko wyświetlacze.

Czyli kompleksowe rozwiązanie Pozostaje czekać na kolejne urządzenia.

Można by pomyśleć również o definiowaniu własnych  obszarów wewnątrz wyświetlaczy (identyfikowanych przez ID) i wysyłaniu tekstu do nich. Takie ID obszaru definiowało by jednoznacznie wyświetlacz i zakres znaków na nim. Wtedy wysyłasz jedynie ID obszaru, adres początkowy i string. (zawijanie tekstu wewnątrz obszaru i brak możliwości wyjścia tekstu po za zdefiniowany obszar, indywidualne czyszczenie całego obszaru).

Taką rzecz zrobiłem u siebie. Można zdefiniować obszar np. trój-znakowy ale każdy znak w zupełnie innym miejscu i z pokręconą kolejnością

Apage satanas! Jakie ActiveX'y !?

To była pomyłka (napisałem wyżej).

Wspomniane było wcześniej o obawie timingów przy komunikacji USB przerywającej komunikację z LCD. Czy próbowałeś wykonać test (jakiś testowy programik) polegający na szybkim wysyłaniu różnych tekstów na wyświetlacz (dłuższa seria kilkunastu lub więcej rozkazów wyświetlenia napisów na LCD) i sprawdzeniu czy stan na LCD jest taki jak powinien ?

[damos]

Wspomniane było wcześniej o obawie timingów przy komunikacji USB przerywającej komunikację z LCD. Czy próbowałeś wykonać test (jakiś testowy programik) polegający na szybkim wysyłaniu różnych tekstów na wyświetlacz (dłuższa seria kilkunastu lub więcej rozkazów wyświetlenia napisów na LCD) i sprawdzeniu czy stan na LCD jest taki jak powinien ?

Już wcześniej pisałem, że zaskoczył mnie nieco model pracy stosowanego u mnie stack'a USB (polling). Obecnie każdy request USB jest przetwarzany "w czasie rzeczywistym" i Host czeka na odpowiedź kontrolera. W tym czasie  wątek na PC jest idle i czeka na powrót call'a do USB. Między innymi dlatego aplikacja kontrolna będzie pracować na osobnym wątku. uP musi cyklicznie odpytywać USB pod kątem nadchodzących danych/komend. Z tego powodu zmieniłem planowany model głównej pętli softu na uP, która miała cyklicznie update'ować wyświetlacze i być przerywana przez przychodzące z zewnątrz requesty USB. Obecnie update jest wykonywany w obsłudze requesta USB i nie jest niczym przerywany. Robiłem testy z "masowym" wysyłaniem danych do LCD. Aplikacja testowa, którą wystawiłem na WWW liczy średni czas wykonania komendy USB przez wywołanie komendy (wysłanie 16-tu znaków) w pętli 10 razy i pomiar tego czasu. Przedtem było to 100 iteracji - bez problemów. tak więc tamten problem już nie istnieje.

edit:
Apropos ULN2003A:
Można (należało by ?) zrobić test bez nich. Wyniki dostaniesz jedynie dla testowanych egzemplarzy. Jeśli ktoś inny zastosuje kompatybilne układy innego producenta - apetyt na prąd może być większy.  Ew w przypadku mniejszej ilości wyświetlaczy - zamiast montować układy na płytce można połączyć ze sobą odpowiednie pary nóżek:
1->16
2->15
3->14
4->13
5->12
6->11
7->10

[vito_zm]

Jutro kończę montaż i rozpoczynam testy.Kupiłem 2 wyświetlacze 2x16 podobno są kompatybilne z HD44780 (tak twierdzą sprzedawcy-zobaczymy).Jeden ma 16 pin w jednym rzędzie,drugi ma 2 rzędy po 7 pin.Mam obawy co do wyprowadzeń tego drugiego (na których pinach są sygnały).Znalazłem stronę gdzie jest tzw.model KFC
http://symlink.dk/electro/hd44780/
Czy ktoś zna może wyprowadzenia tego z 7x2pin?
Co do buforowania to OC dla 4 wyświetlaczy stosuje bufory 74HC541.

[damos]

2 rzędy po 7 pin wygląda jak zwykły interface, tylko pozbawiony LED+ i LED- (15 i 16 styk). Powinno działać. sygnały na pinach o odpowiednich numerach są na linku przedstawionym przez Ciebie. Jak są ułożone numery na wyprowadzeniach? Nie mam pojęcia - może jest "jedynka" na płytce przy pierwszym pinie? Może kwadratowe pole, do którego został przylutowany pierwszy pin?

Co do buforowania, to wrzuciłem kość, która akurat leżała na biurku i OC jej chyba używało Jednak zastanawia mnie brak podłączania jej do plusa... Wygląda tak, jakby ona potrafiła jedynie zwierać do masy ? Wtedy faktycznie potrzebny jest inny driver.