Użytkownik "Mateusz Viste" napisał w wiadomości grup
On 20/05/2016 15:39, Jarosław Sokołowski wrote:
>> 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

>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...

Chcesz to zrobic bardzo dobrze, czy byle jak, byle dzialalo ?

Jak bedziesz probkowal 2-3 razy szybciej, to efekt na ekranie bedzie
IMO niezly, a czasu na przetwarzanie nadal 3-4 razy wiecej.
Jak bedziesz probkowal nieco szybciej, np 17MHz, to niektore
piksele/linie pionowe sie pogrubia - i z tym mozna zyc.
Gorzej, ze moga byc poszarpane ... z tym tez mozna zyc.
Choc w szczegolnym przypadku moga chyba cos zgubic, wiec chyba lepiej
z 1.5x raza szybciej.

Jesli ma byc lepiej, to trzeba PLL, i to ambitniejsze, bo trzeba sie
zsychronizowac ze zmiennym sygnalem.

>Zaczynam rozumieć problem. Jak to rozwiązują same monitory? Wszak one
>w jakiś sposób muszą dopasować się do karty?

Oprocz tego PLL i automatycznego rozpoznawania ilosci cykli na linie
miewaja ustawienia w menu pozwalajace skorygowac czestotliwosc/podzial
i faze.
Szczesliwie - oscylator w MDA jest jeden i w miare stabilny, trzeba
tylko jakos do niego dostroic, a mamy na to multum czasu i cykli, bo
wszak jak monitor przez sekunde bedzie czarny, to klient nawet sie nie
zdazy oburzyc :-)

J.