Generator OSD VGA i synchronizacji, od pomysłu do urządzenia

Witam. Dziś przedstawię historię pewnego urządzenia oraz drogę "od pomysłu do przemysłu". W komentarzach do tekstu o RP Pico pojawiły się pytania o generowanie obrazu VGA, @TechEkspert zasugerował głównemu zainteresowanemu czyli @AlekZ zadać pytanie o możliwość wygenerowania OSD (ang. On Screen Display czyli informacje wyświetlane na tle głównego obrazu). @AlekZ konstruuje urządzenie zbliżone swym działaniem do mikroskopu elektronowego i stosował technikę analogową do generowania sygnałów synchronizacji oraz siatki celowniczej a do obrazowania stary monitor CRT (fotografia obok). O ile samo wygenerowanie sygnałów w standardzie VGA to praktycznie niewielki problem, to już "wszczepienie" OSD do sygnału wyjściowego nie jest takie proste jak się wydaje. Lata temu zajmowałem się trochę montażem analogowego wideo oraz naprawami konsol monterskich więc obowiązujące zasady z grubsza znam. W celu zminimalizowania kosztów zaproponowałem użycie typowych scalonych generatorów OSD z odbiorników TV lub monitorów CRT, @AlekZ stwierdził jednak że to rozwiązania raczej archaiczne i nie dają możliwości żadnej rozbudowy bez znaczącej modyfikacji strony sprzętowej. Oczywiście RP Pico oraz podobne a nawet stara poczciwa ATMega328 da radę wygenerować odpowiedni sygnał VGA jednak jako dość marny programista byłem sceptyczny co do tego. Tu z pomysłem wyszedł Mariusz @khoam ;

khoam napisał:

@arturavs Jak masz płytkę z ESP32, to możesz spróbować uruchomić przykłady generowania sygnału VGA: Link
Biblioteka jest prosta w obsłudze i "arduinowa"

ArduinoIDE nie jest co prawda dla mnie nowością i też wielu rzeczy muszę się jeszcze nauczyć ale mając w "przydasiach" kilka wersji ESP32 postanowiłem pobawić się zaproponowaną biblioteką oraz modułem Heltec. Zbudowałem na płytce prototypowej układ testowy i okazało się że biblioteka jest łatwa w życiu i dobrze działa;






Powyższy widok to zdjęcie mojego monitora Nec V422 który ze względu na funkcję PIP wręcz idealnie nadaje się do takich zabaw . Próby z ESP32 wypadły na tyle zachęcająco że postanowiłem nieodpłatnie zbudować dla @AlekZ kompletny prototyp urządzenia.

Sygnały VGA już mamy, ale jak dodać je do analogowego sygnału z urządzenia Alka?

TechEkspert napisał:

Przydałby się schemat blokowy określający gdzie Rapsberry PI Pico miałoby wstrzykiwać sygnał, do którego sygnału się synchronizować,
a być może można by przejąć część bloków analogowych, zająć się generowaniem sygnału i wkomponować w generowany przez Pico sygnał wartości luminancji z podglądu elektronowego.

O ile nie ma potrzeby jakichś płynnych przejść etc. to trzeba to zrobić przy użyciu szybkiego multipleksera który we właściwym momencie przełączy sam sygnał wizyjny bez wpływu na impulsy synchronizacji. Poniżej przykład stosowany w kamerach analogowych;



Oraz OSD w monitorze komputerowym;



Do przełączania potrzebny jest sygnał Key czyli kluczowania, mamy do wyboru dwie możliwości (najczęściej). ChromaKey i LumaKey, pierwszy to kluczowanie kolorem a drugi jasnością. ChromaKey to często stosowana metoda wmontowywania np. prezentera na tło innego obrazu czyli tzw. Blue Box lub Green Box.

Cytat:

Blue box (inaczej: bluescreen, greenscreen, chroma key) – technika obróbki obrazu, polegająca na zamianie tła o w miarę jednolitym kolorze (pierwotnie niebieskim, stąd nazwa) na dowolny obraz. Szeroko stosowana w telewizji (najczęściej podczas prezentacji prognozy pogody i w programach informacyjnych) oraz w filmie (do umieszczania aktorów w komputerowo generowanym środowisku). Kolor tła to zazwyczaj niebieski lub zielony, ponieważ są one uważane za najmniej podobne do koloru skóry i najrzadziej pojawiają się w kostiumach i rekwizytach.

Ponieważ Alek nie przedstawił jakichś szczególnych wymagań co do ilości kolorów, postanowiłem że użyję trzy bitowego sterowania (co dla składowych RGB mogących przyjąć jeden ze stanów 0 lub 1 daje 8 dostępnych kolorów) a kolorem kluczującym będzie czarny czyli Black Box .
Sygnał wejściowy jest monochromatyczny (czarno-biały) więc nałożenie informacji w siedmiu jaskrawych kolorach powinno być wystarczające.
Po drobnych przemyśleniach postanowiłem w roli testowego multipleksera użyć 4053;





Powyższy układ oczywiście nie działał, w natłoku myśli umknęło mi że każdy monitor ma wejściową impedancję 75Ω dla każdej składowej RGB, to w połączeniu z rezystancją wewnętrzną włączonego klucza 4053 sprawiało że sygnał na wejściu monitora to było jedynie kilkadziesiąt mV. Należało dodać jakiś bufor/driver o odpowiedniej wydajności prądowej. Przeszukawszy zasoby internetu znalazłem kilka interesujących układów jednak były niedostępne na krajowym rynku, myśląc czy nie zaprojektować od zera drivera w oparciu u elementy dyskretne, mój wzrok padł na dekoder NBOX. No chwila... Przecież ma gniazdo SCART mogące pracować w trybie RGB więc jakiś driver musi być. Przejrzałem schematy i faktycznie, jest driver od razu z multiplekserem i dwoma wejściami RGB!




W międzyczasie zacząłem projektować płytkę dla całego urządzenia, ponieważ pomysł z 4053 nie wypalił a FMS6403 to maleństwo w obudowie TSSOP20 to musiałem również zrobić osobną niewielką płytkę do testów drivera;












Zamontowanie gniazda szpilkowego z długimi wyprowadzeniami miało na celu wetknięcie PCB do płytki stykowej aby ułatwić sobie zabawę;



Pierwsze podłączenie do ESP32 i działa;



Widoczne na obrazie zakłócenia to efekt "wiszących" w powietrzu wejść FMS'a, układ okazał się bardzo czuły. Ponieważ może pracować jako bufor/driver zarówno dla sygnałów RGB oraz component a także posiada wbudowane programowalne filtry to chwilę mi zajęło dobranie optymalnej pod względem jakości obrazu konfiguracji. Wymaga również synchronizacji, tu też jest opcja wyboru zewnętrznego sygnału co też zrobiłem. Wypadało podać na drugie wejście jakiś sygnał testowy, tu pomyślałem że wykorzystam starą kamerę CCTV w tej roli. Obraz z kamery będzie oczywiście niezsynchronizowany z OSD lecz w docelowym zastosowaniu urządzenie Alka będzie się synchronizować do sygnałów z ESP32. No dobrze, a co z kluczowaniem? Nie mając na podorędziu żadnej bramki OR w THT postanowiłem zbudować takową z szybkich diod.
Powstał taki schemat;



Połączyłem wszystko na płytce stykowej;



I uzyskałem poniższy efekt;



To tylko obraz testowy, lecz do wybadania efektów współpracy FMS z ESP32 wystarczy. Teraz należało zająć się końcowym projektem płytki oraz oprogramowaniem spełniającym wymagania Alka. Ponieważ znalazłem w "przydasiach" niewielką aluminiową obudowę pochodzącą z trackera GPS to uznałem że wręcz idealnie nada się na "ubranko" dla generatora. Obudowa zdeterminowała wielkość płytki do 100x100mm, aby zachować możliwość ewentualnej rozbudowy wyprowadziłem większość niewykorzystanych GPIO ESP32 na dodatkowe złącza szpilkowe dla ewentualnego wykorzystania w przyszłości. Samo docelowe oprogramowanie postanowiłem napisać już po zmontowaniu płytki prototypu co wydawało mi się słusznym założeniem. Ponieważ miałem luźne ESP32-WROOM-32UE wlutowane na płytkę adaptera, to taką wersję zdecydowałem się użyć;




Oczywiście zacząłem od rozplanowania układu gniazd oraz przycisków sterujących aby całość zmieściła się do poniższej obudowy;





Większość elementów miałem w zapasach a brakowało głównie gniazd BNC i D-Sub VGA oraz nietypowej drobnicy, zamówiłem brakujące elementy w TME wraz z formatką laminatu światłoczułego Rademacher. Do robienia płytek od lat stosuję laminaty Bungard, pokryte fabrycznie emulsją światłoczułą. Płytka do testów FMS6304 którą zrobiłem testowo na laminacie Rademacher wyszła bardzo dobrze i postanowiłem że w ramach testu samego laminatu, płytkę główną również zrobię na nim. Podczas oczekiwania na dostawę brakujących elementów dokończyłem projekt płytki;










Gdy tylko dotarły zamówione podzespoły zabrałem się do pracy...




Niestety, w wyniku mojego niedopatrzenia zbyt mocno zagrzałem wywoływacz do emulsji światłoczułych i znaczna część ścieżek od strony TOP została podmyta;





Podejrzewając już że bez druciarstwa się nie obędzie, zrobiłem kolejną płytkę na laminacie Bungard przy okazji poszerzając ścieżki gdzie tylko się dało. Tu już było ok. .




Widać znaczne podtrawienia i miejscami całkowite wytrawienie oraz przeźroczyste pola masy, praktycznie nie nadawałaby się do montażu. Po kilku godzinach "zmęczyłem" wiercenie i wstawiłem przelotki oraz gniazdo mini USB. Jako przelotek użyłem drucików miedzianych, mam co prawda dedykowane do tego celu nity miedziane, ale poprawny ich montaż bez dedykowanej prasy jest bardzo czasochłonny.




Płytkę zamierzałem docelowo w całości pocynować mechanicznie, a moje technika lutowania jedną ręką wymaga dużych ilości topnika. Oczywiście po skończeniu montażu trzeba będzie wszystko zmyć. Poniżej kolejne etapy składania "prototypa";







I już gotowe;





Całą płytkę pocynowałem mechanicznie. Tu jednak niezauważona przeze mnie zwora na linii zasilania 3,3V sprawiła mnóstwo problemów, podłączyłem do portu USB i nim zdążyłem zareagować ukazał się "magiczny dym" i komputer się wyłączył . Usmażył się stabilizator LDO na płytce generatora oraz płyta główna komputera. Bardzo opóźniło to dalsze prace. Uruchomienie nowego komputera już z systemem Linux również do łatwych nie należało, po kilku tygodniach w miarę doprowadziłem całość do porządku i przystąpiłem do wstępnego uruchamiania.
Tu pojawił się problem z programowaniem ESP;



Po walce ze znalezieniem i dograniem odpowiednich pakietów generator zaczął być widoczny dla ArduinoIDE;



Jednak nie był to koniec problemów... Użyłem GPIO 02 ESP jako wejście jednego z przycisków i to był błąd, podciągnięcie tego pinu do 3,3V blokowało dostęp do pamięci flash ESP. Musiałem przeciąć ścieżkę i podłączyć się pod wolne GPIO;



Jednak dopiero po zmniejszeniu prędkości transmisji do 115kbps udało się rozwiązać kłopoty z komunikacją;



Wreszcie mogłem przystąpić do uruchamiania generatora od strony sprzętowej zostawiając oprogramowanie na deser . Ponieważ kod testowy już miałem, to posłużył on do uruchamiania. Tu jednak już na starcie pokazał się problem wynikający z zaniku wąskich pionowych linii celowniczych.




Winne okazały się zastosowane przeze mnie diody BAV70 w bramce OR które miały zbyt duży spadek napięcia dla pewnego wysterowania FMS6403. On pracuje z logiką 5V a ESP32 3,3V. Spadek napięcia na diodach w połączeniu z dzielnikiem do wyłączania OSD powodował że przy krótkich impulsach multiplekser nie nadążał się przełączać. Zamówiłem diody shottky'ego o identycznych rozkładzie wyprowadzeń czyli BAT54C-G;




Po wymianie linie powróciły



Pojawił się też niepożądany efekt, takie jakby podbarwianie wyświetlanego obrazu które ustępowało w chwili dotknięcia kondensatorów separujących wejścia FMS. Tu pomyślałem że albo przegrzałem układ podczas kilkukrotnego demontażu i montażu HOT'em albo pod układ dostały się resztki agresywnego (i przewodzącego) topnika. Zdemontowałem układ, dokładnie wymyłem i wysuszyłem płytkę. Z kolejnego NBOX'a wylutowałem FMS i wstawiłem. Wszystko się uspokoiło i pozostało jeszcze troszkę dopasować poziomy sygnałów RGB. Tu też wyszedł na jaw błąd w użytych kondensatorach separujących składową stałą na wejściach multipleksera/bufora. W założeniu (zgodnie z DS) miały być 100nF, i takie też zamontowałem. Podczas dobierania dzielników zmierzyłem wszystkie i okazało się że mają 2,2µF! Okazało się że fragment taśmy z kondensatorami był źle oznakowany (takiej drobnicy kupuję po 100 szt.), i tak zmuszony zostałem do mierzenia wszystkich kondensatorów na płytce . Koniec końców skończyło się na 100nF+220Ω szeregowo, dało to najlepsze efekty wizualne.

Oprogramowanie. Tu doszedłem do wniosku iż podwójne buforowanie nie jest potrzebne gdyż generowany obraz jest w zasadzie statyczny i same odwołania do funkcji rysujących powinny być wywoływane tylko wtedy jeśli wystąpi jakaś zmiana parametrów (np. współrzędne celownika) co pozwala oszczędzić RAM ESP32. Przyciski sterujące przesuwem linii celowniczych oraz wł/wył OSD są odczytywane w pętli głównej programu.
Po włączeniu zasilania odczytywane są zdefiniowane współrzędne startowe (środek ekranu), naciskają przyciski sterujące zmieniamy zmienne a następnie linie na poprzednich danych są zamazywane (kolor czarny=przeźroczysty) i nowe linie są rysowane na nowych współrzędnych. Następnie dane są przepisywane do starych współrzędnych. Wyłącznie/włączenie OSD następuje poprzez wysterowanie pomocniczego tranzystora NPN który zwiera do masy wejście sterujące multipleksera a ten przepuszcza jedynie sygnał wideo z urządzenia Alka bez wpływu na synchronizację.

Ponieważ oprócz samego celownika urządzenie miało pozwalać również na wyświetlanie aktualnych parametrów badanej próbki, dodałem ramkę.
Dane miały być odbierane poprzez UART poprzez ten sam konwerter USB/UART który służy do programowania (CH340). Aby linie celownika nie zasłaniały parametrów, dopisałem ograniczniki;




Przy odbieraniu danych do wyświetlenia pokazały się problemy, użyta biblioteka za nic nie chciała wyświetlać poprawnie odebranego ciągu znaków. Po dłuższym czasie i różnych dziwnych kombinacjach, okazało się iż to przesyłane razem z tekstem kody sterujące ASCII przeszkadzają.
Po prostu biblioteka ich nie obsługuje . Nie mając pojęcia co z tym zrobić (a programista ze mnie marny) postanowiłem wyłuszczyć problem forumowej SI (moderatorzy uzyskali wcześniej dostęp do testów);



Po dostosowaniu zaproponowanego kodu do swojego programu, uzyskałem to o co chodziło i mogłem już spać spokojnie .


Pozostało wyczyścić kod programu z różnych testowych śmieci i zająć się zrobieniem front paneli obudowy, dodałem do programu instrukcję obsługi w formie "ekranu startowego";


Front panele niestety musiałem zrobić ręcznie i bez opisów, początkowo zamierzałem je wykonać w formie wytrawionej na laminacie jednak nie udało mi się zmusić mojej drukarki do filmów PCB do współpracy z systemem Linux -(. Panele wyciąłem ze zbędnych fragmentów laminatu i po pomalowaniu przykręciłem do obudowy;







Na panelu przednim dodałem zieloną diodę LED sygnalizującą włączenie zasilania, nie pomyślałem o niej podczas projektowania płytki i jest podłączona przewodami do linii 3,3V. Przy okazji narysowałem też gotowy schemat z naniesionymi podczas uruchamiania poprawkami;


Na schemacie dwie wolne bramki 74HC86 mogą pełnić rolę dodatkowego opóźnienia sygnałów synchronizacji dla monitora, sygnały pochodzą bezpośrednio z ESP32 zaś sygnały RGB przechodzą przez FMS6403 który wprowadza około 27ns opóźnienia. Na moim monitorze jest to widoczne jako trzy-pikselowe przesunięcie obrazu. Dla Alka nie powinno to przeszkadzać. Poniżej film z działania od włączenia (reset);


Szczegółów programu chwilowo nie będę udostępniał, w tej chwili Alek dostosowuje swe urządzenie do nowych wymogów i testuje generator a to może wymagać pewnych zmian w kodzie/schemacie. Po pomyślnych testach dodam do tekstu. Z adaptacji obudowy nie jestem dumny, z perspektywy czasu kilka rzeczy zrobiłbym inaczej, np. zamiast przycisków użyłbym joysticka;


Uprościłoby to konstrukcję obudowy. Zamiast złącz BNC mogłem też użyć SMA, pozwoliłoby to na zmniejszenie całości. Dużą pomocą okazały się podpowiedzi Mariusza @khoam odnośnie ESP32 a także @TechEkspert oraz @acctr . Jak widać przy współpracy może powstać ciekawe urządzenie. Tu link do dyskusji; https://www.elektroda.pl/rtvforum/topic3947972.html Jeszcze słowo o płytce rozszerzeń, ma ona na celu ewentualną rozbudowę generatora o interfejsy kontrolno/sterujące. Jak dotychczas Alek zasila swe urządzenie za pomocą kilku zasilaczy regulowanych ręcznie, być może zbuduje zasilacze sterowane cyfrowo a wtedy dzięki płytce rozszerzeń będzie możliwe automatyczne odczytywanie parametrów oraz sterowanie. Ponieważ jest wymagana optoizolacja to dodatkowa płytka pozwoli takową zmieścić w obudowie.


Dla mnie było to ciekawe doświadczenie z ESP32 i gdyby nie awaria warsztatowego komputera to bardzo bym się cieszył. Nie mniej już mi chodzi po głowie kilka ciekawych pomysłów dotyczących rozbudowy układu oraz zastosowania ESP32 jako generatora VGA .

Link do biblioteki bitluni; https://github.com/bitluni/ESP32Lib