Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup dyskusyjnych: snipped-for-privacy@falcon.lasek.waw.pl... Pan J.F. napisał:
Teoretycznie sie z Toba zgadzam, a jednak IBM w owych czasach robil inaczej. A VGA byly drogie (6 bitow to juz nie takie pare) ..
Dzis tez tak zle nie jest, trzeba byc duzym, aby przepchnac nowy "standard".
Trudno aby zaczeli od stawiania laboratorium LCD. Zauwaz, ze czestotliwosci jednak nieco inne - i nie wahali sie ich zmieniac coraz bardziej.
Tak nawiasem mowiac - telewizyjne kineskopy kolorowe sie niemal nie nadawaly do uzytku - tylko w niskiej rozdzielczosci. Trzeba bylo poczekac na monitory VGA i malymi otworkami w masce. Tak wiec ta CGA wcale taka zla jak piszesz nie byla ... to MS-DOS byl zly, bo kiepsko pracowal na 40 znakach szerokosci :-)
Sześciobitowa drabinka nie jest wielkim wyzwaniem. To też tylko teoretycznie musi być sześciobitowym przetwornikiem, dokładne być nie musi, takie tam zgrubne robienie woltów z bitów.
Jak potrzebowałem rozdzielczości pionowej 1035 (czy coś koło tego), bo mi się Ważny Program na ekranie nie mieścił, to sobie zmieniłem modeline. I karta, i monitor łyknęły. A to było wczoraj, może nawet przedwczoraj. Z czasem wszystko stało się bardziej elastyczne.
Ale tylko nieco. Tolerowane przez podzespoły telewizyjne. Dla MDA amerykanie zaimportowali nawet europejskie 50 Hz.
Po internecie czytałem ludzi którzy twierdzili że udało im się robić PWM rzędu 40 MHz na Pi2... Oczywiście może to być bujda i legendy :)
I to jest właśnie ten szczegół który mi umknął: możliwość składania bajtu z ośmiu różnych linii w hardware, jednym taktem CPU. Z początku przyjąłem że na mikrokontrolerze da się tylko odczytywać pojedynczy stan on/off każdej linii z osobna, dlatego nie rozumiałem dlaczego mógłbym być zainteresowany wykorzystaniem 8x 2MHz zamiast 1x 16 MHz. Teraz rozumiem że na MCU mogę doprowadzić 8 linii TTL, i MCU mi to odczyta całym bajtem w jeden takt.
Sądzę że będę kombinował zatem w tym kierunku:
MDA wysyła mi sygnał TTL 16 MHz, odbieram go na 74hc595 (ten podpięty pod oscylator 16 MHz, tzn. dokładnie tyle ile ma MDA), z 74hc595 wyprowadzam wtedy 8 linii do ATtiny 2313, i tam czytam bajt po bajcie (czyli grupami po 8 pixeli) z szybkością 2 MHz (do dostrojenia za pomocą odpowiedniej ilości NOPów w ASM).
Każdy odczytany w ten sposób bajt ATtiny wrzuca natychmiast w kolejkę SPI, za którą czeka RPi, któremu zostaje tylko malować piksele w swoim framebufferze (tutaj zakładam że buforowanie SPI jest wystarczający by pokryć brak obsługi w realtime na RPi). W jakiś jeszcze nieokreślony sposób będę musiał sprawić by 74hc595 reagował na HSYNC, aby wiedział kiedy dokładnie łapać sznurek bitów (no i AVR zresztą też bedzie musiał znać HSYNC żeby wiedzieć kiedy zacząć odczytywać swój 8bitowy rejestr, a także VSYNC by móc sygnalizować RPi początek każdej ramki).
Czy powyższa wypowiedź ma jakikolwiek sens, czy też rozmawiam całkiem od rzeczy?
Dla uproszczenia postanowiłem zignorować na razie linię "intensity" z MDA, i polować na samo monochromatyczne wideo. Jeśli cokolwiek z tego wyjdzie, zawsze będzie czas szukać ulepszeń.
Ten szczegół może jednak do poprawki :) właśnie spostrzegłem się że ATtiny 2313 ma tylko jeden interfejs ośmiobitowy ("PB"), a ten współdzieli piny z interfejsem SPI, więc odpada. Wyszukam więc inny model AVR który może korzystać z SPI i portu 8bit jednocześnie.
Zapomnij o prostym wykorzystaniu jakiegoś RPi czy innego arduino. Jak któryś z kolegów zauważył, najlepiej jakieś rozwiązanie z licznikami i pamięcią RAM. Generacja sygnału video banalna nie jest a przechwytywanie tegoż; jeszcze gorsze. Jednym słowem: raczej nie dasz rady. No chyba że się zaweźmierz na maxa.
16,257 MHz, tak dokładnie. Dzielone na 882 piksele w linii (widoczne i niewidoczne) oraz 369 linii (łącznie z powrotnymi). To daje częstotliowść ramki 49,95 Hz. Łatwo do tych danych dotrzeć. Zrobić realną analizę żywego sygnału nieco trudniej.
W dniu czwartek, 19 maja 2016 23:43:54 UTC+2 użytkownik jacek pozniak napisał:
Bez przesady. Starczy te bajty wypchac gdzieś gdzie podepniemy się przeglądarka i wczytywac będziemy bitmape. I tu jedna malina sampluje (pewnie dropując niektóre ramki) a druga montuje z danych bmp/jpg i wystawia przez apache... Tyle że problem bedzie z tym złapaniem, zmontowaniem bitmapy i jej oddaniu do zaserwowania...
Ano, z łapaniem 16 Mhz rozumiem że może być trudno, ale łapanie 2 MHz za pomocą ATMegi z taktowaniem 20 MHz już chyba powinno być realistyczne?
Stąd ten cały 74hc595 właśnie, za wskazówkami przedmówców dot. wykorzystania rejestru przesuwającego.
Pomysł z RPi na samym końcu jest o tyle kuszący, że umożliwia w pełni programowe malowanie ekranu, cała elektronika już jest, i to całkiem przyszłościowo (hdmi) - a gdyby wykorzystać RPi Zero to i cenowo zaczyna być bardzo interesująco. Fakt, że RPi może mieć problemy komunikacyjne związane z brakiem obsługi realtime, ale to można (?) wyrównać za pomocą odpowiednio dużych buforów na wejściu SPI po stronie RPi.
Czyli generalnie mamy 3 bloki:
rejestr przesuwny SIPO zaciąga sznurek bitowy od MDA z częstotliwością
16.257 MHzi wystawia po 8 równoległych bitów
ATMega48 odczytuje z rejestru ośmiobitowe bloczki (8 pikseli na raz) starając się utrzymać częstotliwość 2.03 MHz (być może odczyty wywoływane jakimś interruptem sterowanym z tych 16.257 MHz po dzielniku /8... do zbadania), i wysyła osmio-pikselowe bloczki po SPI
RPi odbiera piksele z SPI i maluja na swoim framebufferze
Jedyny "podejrzany" etap to komunikacja między rejestrem przesuwającym a ATMegą, ale skoro to "tylko" 2 MHz, to jakaś nadzieja chyba jest...
Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar, wtedy niedokładności przestają mieć aż takie znaczenie. A jak z RPi (albo czegoś innego podobnego) wywalisz Linuxa to może być trochę łatwiej (nie wiem czy się da). Trzeba by popatrzeć na to czym programować na odpowiednim poziomie i jak szybko peryferia potrafią działać. I poszukaj 595 trochę szybszej serii - HC to przeżytek straszny.
Wystarczającą dokładność *częstotliwości* osiągnąć łatwo. Skoro linia ma 882 piksele, to przy dokładności lepszej od 0,1% da się bezbłędnie ją spróbkować. Problemem jest *faza*. I tu dobrym podejściem (o czym też chyba ktoś pisał), jest odczyt 16257000 *bajtów* na sekundę, w ten sposób, że każdy bit jest brany z pewnym przesunięciem czsowym (da się je zrobić rejestrem lub nawet analogowo). Wtedy mamy gwarancję, że można wskazać *bit*, który w ciągu *bajtów* pokaże prawidłowy obraz wyświetlanych punktów. Ale który to bit? Ano ten, który ma takiego samego młodszego i starszego sąsiada w każdym bajcie.
Wiem, niczego odkrywczego nie napisałem. Ale to jest jakaś wskazówka, jak może dziłać prosty i klarowny algorytm poszukiwanie prawdy o tym, co by monitor wyświetlał, gdyby wyświetlał.
Tak tak, to jest jasne. Ale wtedy nie było (jeszcze) mowy o rejestrze SIPO, rozmowa dotyczyła bezpośredniego zbierania 16.257 MHz na MCU.
Teraz sytuacja jest nieco inna - odkryłem (dzięki uprzejmości grupy) że istnieje coś takiego jak "rejestr przesuwający", i wykorzystując ten cud technologiczny jestem w stanie zbić transmisję monobitową 16 MHz do zaledwie 2 Mhz (x8 bitów). A z punktu widzenia 2 MHz, to taktowanie ATMegi48 spełnia warunek "parę razy szybsze" (20 MHz). Pytanie ile instrukcji potrzeba aby odczytać bajt z rejestru, i ten sam bajt wrzucić natychmiast do SPI. Nie sprawdzałem, ale domniemywam że pewnie ze 3 albo
Aby uzyskać dokładny timing myślałem jeszcze by podpiąć moje 16.257 MHz do dzielnika częstotliwości 1:8, i wynik wyprowadzić na przerwanie ATMegi - wtedy musiałbym tylko odczytać 1 piksel w ramach obsługi przerwania, i dokładność zapewniona. Aczkolwiek nic nie wiem o ATMedze, więc może istnieją jakieś twarde limitacje związane z przerwaniami, to się okaże w praniu.
Da się, i to temat który już oglądałem. Brzmi niby zachęcająco, bo boot trwa sekundę lub dwie, ale problem w tym że to wymaga napisanie swoich sterowników do GPU i SPI, a to już znów podwyższa poprzeczkę.
Ostatecznie, przy moim obecnym schemacie nie mam już potrzeby aby RPi działało ponadprzeciętnie szybko, bo i tak żadnego bit bangingu nie ma uprawiać, tylko czytać po kolei to co przychodzi via buforowane SPI i wrzucać na ekran. Nie oczekuję 100% frame rate, jeśli od czasu do czasu zgubi się kilka ramek to dla mnie bez znaczenia.
Za to tanie :) a datasheet twierdzi że mogę oczekiwać gwarantowanego działania do 30 MHz (w zależności od serii do 100 MHz) - czyli więcej niż potrzebuję.
Hola hola, pomysł spoko, ale to mnie znów kieruje na tor łapania 16.257 MHz bezpośrednio na MCU, a to mi wcale nie po drodze :) Idea zbijania częstotliwości do 2 MHz bardzo mi się spodobała...
Policzyłem że każdy piksel wychodzący z MDA trwa 61.5 ns - czyli tyle czasu ma rejestr 74HC595 żeby przechwycić stan linii. Sam 74HC595 taktowany jest oscylatorem 16.257 MHz, więc wszystko sprowadza się do problemu "jak sprawić aby mój oscylator zaczął drgać w tym samym momencie co oscylator po stronie MDA?"... I to jak sądzę jest to co nazywasz fazą. Mógłbym np. włączyć mój oscylator w momence kiedy znika mi HSYNC, ale z tego co czytam w datahseetach oscylatorów, ich czas włączenia i stabilizacji liczy się w milisekundach, więc odpada. Dlaczego nikt nie wpadł na to by na jednym z pinów MDA wyprowadzić stan oscylatora karty? Teraz niestety jest trochę za późno (o 30 lat).
Zaczynam rozumieć problem. Jak to rozwiązują same monitory? Wszak one w jakiś sposób muszą dopasować się do karty?
Ale chodzi o to, żeby ten rejestr puścić parę razy szybciej. W kablu nie masz prostych zboczy. Na wyjściu masz tak naprawdę impulsy trochę rozmyte. Może się okazać, że przy próbkowaniu z tym samym zegarem co wejście będzie kłopot z łapaniem niektórych pikseli. Próbkując kilka razy częściej masz dużo większą szansę na poprawną detekcję. No i nie musisz mieć wtedy dokładnej częstotliwości. A jak nic o atmedze nie wiesz, to bierz się od razu za atxmegę. Podobny, a równocześnie zupełnie inny układ. Dużo więcej może i szybszy jest. Jedyny minus to 3.3V, ale z tym idzie zadziałać. Nie to, że na pewno potrzebujesz, ale po co uczyć się starego układu? A puścisz go dwa razy szybciej niż zwykłą atmegę.
Gorzej jak uda Ci się uzyskać efekt mory. Może być męczący.
No więc o to chodzi, żeby się nie bawić w HC tylko wziąć np VHC. Różnica w cenie jest....
W dniu 2016-05-20 o 15:39, Jarosław Sokołowski pisze:
No i do tego służy właśnie próbkowanie kilka razy szybciej. To przesunięcie czasowe nie jest niczym innym przecież. I niekoniecznie aż 8 razy, w sumie to niekoniecznie nawet musi być całkowity mnożnik. Kwestia jak bardzo chce się bawić w wymyślanie algorytmów.
Nie. Monitory muszą się dostosować do użyszkodnika (tak naprawdę do karty też, ale na innym poziomie). Sprawę załatwia się ramką wokół wyświetlanego obrazu, potencjometrami do regulacji w pionie i poziomie... Monitorowi tak naprawdę lata - on musi się zsynchronizować z kartą na impulsach pionu i poziomu, a potem mu to wisi czy coś będzie szybciej czy wolniej. Monitor CRT nie wyświetla pikseli. No, w kolorowym można jeszcze pod piksele jakoś podciągnąć, ale też działa to trochę inaczej. Co innego LCD, dlatego są z nimi cyrki typu łapanie fazy jak "zasilasz" go z VGA. W CRT przy przesunięciu fazy jedyne co się dzieje, to przesuwa się obraz. W LCD ... no właśnie o tym pisałem, że warto nadpróbkować.
Rejestry przesuwające, bo o tej idei teraz mowa, robi się też dłuższe niż osiem bitów. Nie doradzę konkretnego układu, bo tego nie praktykowałem, ale być może da się znaleźć nawet scalony rejestr 1024-bitowy. Słowa do guglania to "shift register", "serial-in", "parallel-out", "NNN-bit".
Nie ma potrzeby włączania za każdym razem motoru, wystarczy puścić sprzęgło. Czyli otworzyć bramkę puszczającą takty zegara dalej. Zegar może być N razy szybszy, a za nim zerowany dzielnik przez N -- wtedy faza się zsynchronizuje. Z tym że w stabilność impulsów synchronizacji poniżej szerokości piksela, to ja nie mam wiary.
Nie wiem czy o tym napisałem, czy tylko pomyślałem. Gdyby wyprowadzić zegar karty na złącze, to by było dużo łatwiej. No ale znów ten konserwator zabytków, drań jeden i służbista. A dlaczego nie zrobiono tego 30 lat temu? Nikt nie podejrzewł, że będzie komuś potrzebne.
Na ten tor też próbowałem skłonić. Scalone kontrolery paneli LCD pędzone sygnałem VGA powinny dać radę po niewielkim przestrojeniu. Warto przejrzeć dejtaszity. W końcu z czegoś te monitory MDA po 500 euro robią. Tam w sumie chodzi głównie o takie rejestry przesuwne, w dużej mierze robione sprzętowo.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.