Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wyświetlacz graficzny WG320240B0 przez LPT zakłócenia

07 Kwi 2016 10:32 660 7
  • Poziom 6  
    Witam wszystkich


    Podłączyłem wyświetlacz Winstar WG320240B0 (http://www.winstar.com.tw/products_detail_ov.php?lang=pl&ProID=143) przez LPT do komputera zgodnie ze znalezionym w sieci schematem: http://www.turbokeu.com/mycomputer/glcd1/glcd1.pdf


    Pojawiają się zakłółcenia:

    Wyświetlacz graficzny WG320240B0 przez LPT zakłócenia


    Gdzie szukać problemu? W płytce lutowanej? Czy jest szansa to wysterować programem? Czy problemem jest sam sposób komunikacji?


    Pozdrawiam
  • Pomocny post
    Poziom 29  
    Napisz coś więcej o:
    - zastosowanym kablu LPT (długość, czy ekranowany, czy fabryczny),
    - komputerze - laptop/stacjonarny,
    - czy stacjonarny podpięty do gniazda z bolcem,
    - rodzaju zasilania modułu wyświetlacza (zasilacz sieciowy - jaki?, zasilanie akumulatorowe).

    Jeżeli masz możliwość (laptop lub zasilanie akumulatorowe wyświetlacza), spróbuj zobaczyć, czy da poprawę zasilanie jednego z elementów z akumulatora.
  • Poziom 6  
    Witam ponownie, dziękuję za przesłaną odpowiedź.

    Przewód LPT 1,8m nie jestem pewien czy ekranowany; kupiony w zwykłym sklepie, nie jest jakiś specjalny.
    Podłączone do komputera PC, i3 8GB RAM podpięty do gniazda z bolcem przez listwę.
    Zasilane jest bezpośrednio z portu USB (wlutowane gniazdo), sprawdzałem zasilanie zarówno przez USB bezpośrednio z komputera, jak i przez ładowarkę 5V.

    Dziękuję za zainteresowanie. Siedzę nad tym kilka dni i próbowałem już wszystkiego

    pozdrawiam
  • Pomocny post
    Poziom 29  
    [poniższy wpis wysłany wczoraj wieczorem jakimś cudem nie został zapisany przez serwer Elektrody, a może czekałeś na odpowiedź - właśnie odkryłem, przywracam i uzupełniam z kopii lokalnej zapisanej w cookie]

    Nie ma za co, wiem jak to jest uganiać się za cieniem :).

    Ekranowanie można stwierdzić, otwierając obudowę wtyczki. Ale kabel nie jest jakiś specjalnie długi i prawdopodobnie został fabrycznie przetestowany. Dla wszelkiej pewności możesz go "przegwizdać" multimetrem pin po pinie. Ale to raczej nie to.

    Grube problemy związane z zasilaniem (zwłaszcza napięcia między masami obu urządzeń powodujące prądy zakłócające płynące w przewodzie masy) chyba wykluczyliśmy, skoro zasilane są z jednego źródła. Zwłaszcza że tutaj mamy osobną masę sygnałową w kablu LPT i osobną masę zasilania w kablu USB. No chyba że w komputerze między masą USB (minus zasilania) i masą LPT jest jakieś napięcie. Ale byłoby to nieprawidłowe. A rzeczy subtelne musiałbyś tropić oscyloskopem na poszczególnych liniach interfejsu.

    Na karcie katalogowej modułu wyświetlacza nie ma prawie żadnych informacji, natomiast na projekcie Chrisa Deceunincka podane są prądy zasilania sumujące się do około 220 mA. Czy sprawdzałeś, że tyle rzeczywiście jest i nie ma jakiegoś nadmiernego poboru na poziomie granicy wydajności portu USB?

    Komunikacja z kontrolerem SED1335 nie jest mi znana, ale na poziomie 8-bitowego interfejsu do mikrokontrolera z kilkoma sygnałami sterującymi to klasyka. Dlatego połączenie LPT<->kontroler składa się tylko z drutów. Nie sprawdzałem projektu, czy nie ma tam grubych błędów (numery pinów itd.), ale nie przypuszczam. Przy 1,8-metrowym kablu to musi działać, o ile zależności czasowe sygnałów na interfejsie są zachowane - ale to zależy głównie od programu. W sieci znajdziesz furę sprawdzonych projektów różnych urządzeń (np. programatory) komunikujących się po LPT dzięki możliwości zastosowania dwukierunkowej transmisji znacznie szybszej niż po COM/RS232. Dziś króluje USB jako szybki interfejs, ale w latach minionych komunikacja po LPT była ceniona i skuteczna. Kiedy nie było dysków USB i interfejs LAN był w komputerach rzadkością, łączyło się je właśnie po LPT i dane śmigały szybko i pewnie bez takich trudności jak twoje. Problemem były dłuższe odległości, włączenie do różnych faz sieci energetycznych, różnych listew zasilających. Zdarzyło mi się spalić port w jednym komputerze, bo - jak się później okazało w czasie śledztwa - elektryk-geniusz w jednym z gniazdek bolec uziemiający dołączył do fazy, a komputery stały na przeciwległych końcach pokoju, więc musiały zostać zasilone z różnych gniazd.

    Ale jeszcze kolejne pytania, które przychodzą mi do głowy:
    - czy zakłócenia pojawiają się na ekranie w sposób przypadkowy i zmienny w czasie niczym szum na ekranie analogowego telewizora przy kiepskim sygnale; czy może mają charakter statyczny (od resetu do resetu, od zmiany obrazu do zmiany obrazu, stały - zawsze w tym samym miejscu); czy mają charakter jakkolwiek zdeterminowany (np. cała linia przesunięta o X pozycji, konkretna grupa pikseli zawsze przesunięta tak samo)?
    - co wiesz o programie, którym to sterujesz? czy masz absolutną pewność, że nie ma w nim błędów?
    - czy masz również absolutną pewność, że moduł wyświetlacza jest sprawny?
    - czy masz możliwość przetestowania modułu wyświetlacza na innej platformie z innym programem (są biblioteki i przykładowe programy na Arduino)?
  • Poziom 6  
    Program jakiego używam nie ma chyba znaczenia, ponieważ testowałem to zarówno na swoim sofcie, jak i programem LCDStudio i zarówno tu jak i tu pojawiają się zakłócenia.


    Kupiłem 3 wyświetlacze i na każdym pojawia się to samo.

    Wcześniej sprawdzałem układ na pająku i myślałem że jakość przewodów jest słaba i to jest przyczyną. Ale jak zrobiłem swoją płytkę to znowu się zastanawiam czy znowu wina nie leży po stronie lutów :D

    Widać że zakłócenia są nieregularne, potrafi się pół bitmapy wysłać bez błędu by potem wyrzucić zakłócenia.

    Wygląda to w taki sposób, że wysyłam komendę WRITE pinami sygnałowymi, a potem by wyświetlacz przechwycił sygnał zmieniam stan na pinach sterujących. Wtedy adres pamięci wyświetlacza automatycznie przesuwa się +1. W moim przypadku widać że właśnie w niektórych momentach brakuję tego przesunięcia, jakby pomijał niektóre komendy. Czas nie ma tu znaczenia, bo nawet jak dawałem sekundę to zdarzenie się pojawiało.

    pozdrawiam
  • Pomocny post
    Poziom 29  
    Nie napisałeś tego wprost, ale rozumiem, że błędy wyskakują w procesie komunikacji, a potem ten zniekształcony obraz jest statycznie wyświetlany na ekranie. To prawda?

    Z obrazka można było przypuszczać, a ty to wprost teraz napisałeś, że program stosuje mechanizm komunikacji sekwencyjnej - (adres początkowy A0, wartość @A0, wartość @A0+1, wartość @A0+2... itd.). Czy próbowałeś zastosować komunikację z adresowaniem bezpośrednim (adres A0, wartość @A0), (adres A1, wartość @A1), (adres A2, wartość @A2)... itd.? Wiem, że to wprowadza ograniczenie prędkości komunikacji i szybkości działania, ale chodzi o próbę, czy w takim wariancie pojawiają się błędy.

    Na obrazku widać, że są przypadki linii przesuniętych w lewo (co może świadczyć o takim "niezłapaniu" jakichś wartości w komunikacji sekwencyjnej, jeśli np. sygnały sterujące były za krótkie. Ale też wydawało mi się, że były takie linie, gdzie czarnych pikseli było za dużo, czyli jakby było przekłamanie na szynie danych, a nie na liniach sterujących.

    I jeszcze jedno - obrazek pokazuje błędy w trybie graficznym. Czy tryb tekstowy działa OK?

    Podkreślam - nie znam kontrolera SED1335/RA8835 i przejrzałem tylko jego listę rozkazów. Ale nie ma tam komendy WRITE (jest MWRITE), więc nie do końca rozumiem - czy korzystasz z biblioteki, która tworzy jakąś warstwę abstrakcji i mediuje między programem a kontrolerem? Równocześnie zrozumiałem, że twój program sam bezpośrednio steruje liniami sterującymi. Mam tu sprzeczność.

    Czy możesz wystawić dokumentację, z której korzystasz? Byłoby łatwiej się zastanawiać.
  • Poziom 6  
    Jesteś wielki!

    Pomogła zmiana w kodzie która po każdej komendzie ustawia się kursor ręcznie, zamiast automatycznie.

    Zakłócenia się jeszcze pojawiają, ale jest ich 90% mniej niż było na początku. Postaram się jeszcze to wysterować do końca, a także przejrzę jeszcze raz luty i płytkę.

    pozdrawiam
  • Poziom 29  
    To bardzo dobre wiadomości! Miałem w poprzednim wpisie zwrócić twoją uwagę na fakt, że masz 3 moduły i każdy ma problem, ale się rozpisałem i to mi umknęło.

    Z mojego punktu widzenia wygląda to tak:
    - jeżeli masz zawsze takie samo zniekształcenie dla danego obrazu testowego - błąd na poziomie algorytmu obliczeniowego w programie;
    - jeżeli zakłócenia są różne dla kolejnych odświeżeń tego samego obrazu, ale obraz jest statyczny - problem na interfejsie, najprawdopodobniej z dynamiką sygnałów;

    Pamiętaj, że oprogramowanie wykorzystujące komunikację na magistrali (nawet jeśli za pośrednictwem LPT) ma zawsze silne ograniczenia. Wiadomo, że dąży się do jak największej prędkości komunikacji, ale musi zostać zachowany kompromis z wymaganiami związanymi z dynamiką układów współpracujących z magistralą i oczywiście najwolniejszy narzuca innym swoje wymagania. Muszą być zachowane odpowiednie czasy zwłoki między kolejnymi etapami sekwencji (np. najpierw musisz podać dane na magistralę, odczekać na ich stabilizację, a dopiero potem wysłać impuls zapisu, który oczywiście musi mieć zachowany minimalny czas trwania, a w czasie impulsu zapisu dane nie mają prawa się zmienić).

    Na zasadzie zerknięcia do absolutnej klasyki popatrz na stronę 7 tego dokumentu, zwłaszcza na cykl zapisu (port w trybie wyjścia). Tu masz nawet jeszcze weselej, bo najpierw adresujesz układ, potem generujesz zbocze opadające impulsu !WR, wystawiasz dane na magistralę, po ich stabilizacji generujesz zbocze narastające impulsu !WR - i to jest ten moment, kiedy port przejmuje dane z magistrali, ale trwa jeszcze chwila zwłoki, zanim dane się przepropagują na wyjście portu.

    Ja nigdy nie pisałem programu na PC do szybkiej komunikacji, raczej budowałem urządzenia komunikujące się po LPT z gotowym programem. Trudno mi więc powiedzieć, czy mechanizmy systemu operacyjnego typu Windows separujące aplikację od fizycznego sprzętu w istotnym stopniu zaciemniają programiście obraz. Ale na poziomie programowania mikrokontrolerów współpracujących z peryferiami byłem dość leniwy - i zamiast z dokumentacją, kartką i ołówkiem w ręku wyliczyć czasy cykli wykonania instrukcji dla danego typu mikrokontrolera i częstotliwości zegarowej, sprawdzałem eksperymentalnie z użyciem oscyloskopu ile trwa N martwych cykli - na początek programem wystawiającym na linię portu falę prostokątną, później zaś wbudowując w funkcję służącą do komunikacji mechanizmy opóźnień skalowane z jednego miejsca. Dobierając współczynnik skalujący można było znaleźć optymalny kompromis między bezpieczeństwem i szybkością komunikacji.

    Może ktoś z innych użytkowników Elektrody się zlituje nad tym wątkiem i zaproponuje inny praktyczny i może lepszy sposób określenia wymagań dla programu sterującego pod kątem dynamiki interfejsu LPT-kontroler LCD, ale jeżeli masz dostęp do oscyloskopu, to popróbuj na razie po mojemu.

    Hardware oczywiście możesz przejrzeć, nie zaszkodzi.

    I odezwij się, jak rozwiążesz do końca problem, powodzenia!