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

NonoPI Fire - podłączanie wyświetlaczy RGB

29 Lip 2017 23:12 2223 2
  • Poziom 30  
    Wyświetlacze do minikomputerów to ciągle jest nie do końca rozwiązany problem. Wyświetlacze z interfejsami HDMI czy MIPI DSI to znacznie ograniczona oferta i nie zawsze są dobrej jakości. Dlatego zainteresowałem się modułami NanoPI Fire które są wyposażone w całkiem pożądne procesory Samsung-a i posiadają wyprowadzone złącze RGB, czyli najprostszy interfejs LCD. Takich wyświetlaczy jest najwięcej i są najtańsze.


    Ale do rzeczy, opiszę tutaj jak podłączyłem dwa wyświetlacze firmy Winstar o całkiem przyjemnym obrazie i pojemnościowym ekranem dotykowym: 5'':WF50BTIAGDNGY i 7'': WF70GTIAGDNG0. Wyświetlacze można kupić w Polsce w cenie 128 i 220zł.

    NonoPI Fire - podłączanie wyświetlaczy RGBNonoPI Fire - podłączanie wyświetlaczy RGB


    Problem #1
    Dla NanoPI Fire, producent przewidział kilka modeli wyświetlaczy, jednak są dość drogie (>300zł) i jakość też jest słaba (mam http://wiki.friendlyarm.com/wiki/images/d/d8/CMOS-camera-nanopi2.png ). Złącze na module jest 45-pinowe do taśmy FPC. Wyświetlacze z interfejsami RGB występują zwykle w dwóch odmianach: 40-pinowej i 50-pinowej. Czyli potrzebny będzie adapter krosujący sygnały z 45 złącza NanoPI na układ wyświetlacza.

    Problem #2
    Zasilanie. Tu jest znacznie ciekawiej. Wyświetlacze potrzebują kilku napięć i to podanych w odpowiedniej kolejności. Ten 5'' ze złączem 40-pinowym posiada wbudowany zasilacz do wszystkich tych napięć (widać go na taśmie). Z zewnątrz podajemy tylko 3.3V i zasilanie diod backlight-u. Wyświetlacze z taśmą 50-pinową wymagają podania tych napięć z zewnątrz. Tych napięć jest aż pięć + backlight.

    Problem #3
    Oprogramowanie NanoPI Fire ma taki ich mechanizm rozpoznawania LCD na podstawie wymyślonego protokołu po 1Wire. Ich wyświetlacze są rozpoznawana i działają bez problemu. Potrzebny jest mechanizm rozpoznawania typu wyświetlacza bo każdy ma inny zestaw parametrów.


    Na początek hardware. Postanowiłem sprawdzić czy da się zrobić tanią przejściówkę, to znaczy oszczędzić złącze i taśmę od przejściówki do NanoPI. Wykonałem druki a następnie przy pomocy wiertła diamentowego do glazury i dobrej wiertarki stołowej, zeszlifowałem laminat nad złączem krawędziowym do ok 0.3-0.4 mm. Trzeb uważać bo taki laminat jest łamliwy. Tak zeszlifowany laminat wchodzi w złącze FPC. Można taką płytkę zrobić na laminacie 0.3mm czy zrobić "flex" ale cena przy małej ilości jest kosmiczna.
    NonoPI Fire - podłączanie wyświetlaczy RGBNonoPI Fire - podłączanie wyświetlaczy RGB
    Na przejściówce do wyświetlacza 5'' jest tylko zasilacz 3.3V (z Nano mamy 5V) i przetwornica step-up dającą 19.5V dla backlight-u na MCP1661.
    W przypadku wyświetlacza 7'', generacją napięć zajmuje się specjalny do tego celu TPS65105
    NonoPI Fire - podłączanie wyświetlaczy RGB
    Schematy:
    fire2_lc..0.pdf Download (48.73 kB) fire2_lc..0.pdf Download (62.18 kB)

    Software - UBOOT:
    NonoPI Fire bazuje na UBOOT-cie. To i dobrze. Trzeba zrobić kompilację i w dość sprawny sposób uaktualniać UBOOT bo zmian wykonuje się sporo (np. po SCP,SSH).
    Każdy LCD ma zestaw parametrów czasowych. Każdy inne. Parametry te opisywane są w dokumentacji:
    - zegar w MHz
    - horyzontalnie czas trwania imp. synchronizacji (w cyklach zegara)
    - horyzontalnie czas trwania rozbiegu przed danymi : back-porch (blanking) (w cyklach zegara)
    - horyzontalnie czas trwania wygaszania po danych : front-porch (w cyklach zegara)
    - wertykalnie czas trwania imp. synchronizacji (w liniach)
    - wertykalnie czas trwania rozbiegu przed danymi : back-porch (blanking) (w liniach)
    - wertykalnie czas trwania wygaszania po danych : front-porch (w liniach)
    - polaryzacja impulsów synchronizacji.
    W pliku "board/s54418/nanopi2/lcds.c" znajdują się definicje parametrów dla wspieranych wyświetlaczy. W pliku "board/s54418/nanopi2/board.c" następuje detekcja wyświetlacza, funkcja "bd_lcd_init" - nadpisujemy zmienną "myid":
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Następnie w pliku "lcds.c" odszukujemy definicję parametrów dla indeksu 3: tablica "nanopi2_lcd_config" i tam jest przypisanie:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Szukamy struktury "wvga_s70" i modyfikujemy ją w zależności od parametrów naszego wyświetlacza:
    dla WF50BTIAGDNGY ja wykombinowałem:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Dla WF70GTIAGDNG0
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Parametry "width", "height" są oczywiste. Parametry "p_width" i "p_height" są bez znaczenie (nie ma żadnych odwołań), "freq" ustawiamy jakoś sensownie np. 63Hz bo to może się jeszcze zmienić co wyjaśnię. Znaczenie: "h_fp" - front-porch, "h_bp" - back-porch, "h_sw" - sync-width, podobnie dla v. Co robi "v_fpe" i "v_bpe" nie wiem, wszędzie jest 1 (enable?). Niby proste a jednak. parametry dla v należy dobierać jak najkrótsze czyli wartości bliskie minimum z DS. Długie wartości powodowały brzydki rozbłysk ekranu po wyjściu z UBOOT-a a przed kernelem. Wydawało by się, że back-porch jest krytyczne bo DS podaje bez marginesu ale tak nie jest. Krytyczne okazało się coś zupełnie innego.
    Otóż, na końcu jest jeszcze jeden parametr:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Jest to wskaźnik na funkcje której zadaniem jest ustawienie "strength" pinów. Są tam 3 grupy: CLK, RGB i HS,VS,DE. Wszystkie glitch-e i paskudne zachowania obrazu zależą od tych wartości. Siła pinu jest od 0 do 3. Tutaj jedynie metoda prób i błędów, jeśli coś dzieje się w środku obrazu, np przejście z białego na czarne daje duszki pikselowe, to jest to relacja pomiędzy pinami RGB a CLK, jeśli coś dzieje się na końcu czyli na krawędzi to grzebiemy przy HS,VS,DE. Jeśli już będzie nam się to dobrze zachowywało dla jednego obrazu, to np. terminal tekstowy pokaże że coś drży i zaczynamy dostrajanie od nowa.
    Ja ustaliłem:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    UBOOT ma łatwy sposób na podstawienie logo, po prostu plik "logo.bmp" w katalogu "/boot". Wrzuciłem tam obraz kontrolny i tak regulowałem aby wszystko było wyświetlane idealnie, obraz ma być bez żadnych drgań czy pikselków w niewłaściwych miejscach:
    NonoPI Fire - podłączanie wyświetlaczy RGBlogo.png Download (2.84 kB) (trzeba przerobić na BMP).

    Software - KERNEL:
    UBOOT detektuje LCD i jego nazwę przekazuje do kernela jako parametr "lcd=", jeśli wybraliśmy "3" to odpowiada to nazwie LCD "S70" i na takiej podstawie drajwer kernela wybierze parametry.
    Niestety, drajwer UBOOT-a nie jest spójny z drajwerem kernela i wszystkie zmiany musimy powtórzyć ręcznie. Plik: "linux-3.4.y/arch/arm/plat-s5p4418/nanopi2/lcds.c". Wyszukujemy parametry dla wyświetlacza "S70", kopiujemy z UBOOT-a i dodajemy odpowiednio funkcje dla "siły" pinów. Po tym, okazało się że jeszcze trochę regulacji właśnie w "sile" pinów było konieczne, bo choć obraz kontrolny był idealny to np. LXDE już pokazało pewne problemy. Też obraz konsoli w trybie tekstowym lekko drżał i kilka iteracji dla każdego wyświetlacza było koniecznych. Potem, to co poprawiłem w kernelu przeniosłem do UBOOT-a.

    Uwaga co do częstotliwości. Jeśli specyfikacja podaje jaki min/max ma być zegar, to liczy się go tak:
    Fclk = freq*(width+h_fp+h_bp+h_sw)*(height+v_fp+v_bp+v_sw)
    Czyli jest to częstotliwość uwzględniająca wszystkie takty. Trzeba przeliczyć i sprawdzić czy to co jest w parametrze "freg" daje odpowiednią częstotliwość CLK.

    Efekt:


    To z czym nie było problemu to dotyk. Po prostu działa. Wymagał jedynie kalibracji w X11, w LXDE jest do tego narzędzie ale można też ręcznie.

    Chciałem zrobić on/off korzystając z pinu GPIOB25 do backlight, ale nie zauważyłem, że 3.3V to za mało dla MCP1661. Też widzę że układ płytek jest nieco niefortunny i trzeb będzie to inaczej przemyśleć, w końcu to pierwszy prototyp.
  • Specjalista - Mikrokontrolery
    michcior napisał:
    horyzontalnie czas trwania imp. synchronizacji (w cyklach zegara)
    - wertykalnie czas trwania imp. synchronizacji (w liniach)


    Po polsku: czas impulsu synchronizacji poziomej/pionowej.
    ;)