W dniu czwartek, 19 maja 2016 19:03:04 UTC+2 użytkownik Mateusz Viste napisał:
> On 19/05/2016 18:05, Mateusz Viste wrote:
> > wyprowadzam wtedy 8 linii do ATtiny 2313, i tam czytam bajt po bajcie
>
> 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.
>
> Mateusz

Zacznij od razu od płytek uruchomieniowych atmega lub xmega.
Kosztowac będzie nieduzo:

http://allegro.pl/modul-prototypowy-x3-dil64-atxmega
-xmega-128a3u-au-i6061007147.html
http://allegro.pl/leon-modul-x3-dil64-premium-xmega-
atxmega-avr-i6008470217.html

plus jakies dodatkowe komponenty. Zmiescisz sie w 200pln za wszystko (plus jakis
breadboard, zasilacz itp.).

Nie ma co sie szczypać z attiny :)

do góry

On 19/05/2016 23:43, jacek pozniak wrote:
> 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.

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

Praktyka na pewno zweryfikuje mój optymizm :)

Mateusz

do góry

W dniu 2016-05-20 o 13:08, Mateusz Viste pisze:
> On 20/05/2016 12:12, Andrzej W. wrote:
>> Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz w MDA, oba
>> zegary Ci się rozjadą.
>
> Trochę uprościłem z tym 16 MHz - w praktyce jak najbardziej byłoby to
> dokładnie tyle co napisane na oscylatorze który mam na karcie MDA, czyli
> 16.257000 MHz.

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.

Pozdrawiam

DD

do góry

Pan Dariusz Dorochowicz napisał:

>>> Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz
>>> w MDA, oba zegary Ci się rozjadą.
>>
>> Trochę uprościłem z tym 16 MHz - w praktyce jak najbardziej byłoby
>> to dokładnie tyle co napisane na oscylatorze który mam na karcie
>> MDA, czyli 16.257000 MHz.
>
> Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar,
> wtedy niedokładności przestają mieć aż takie znaczenie.

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

--
Jarek

do góry

On 20/05/2016 14:40, Dariusz Dorochowicz wrote:
> Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar, wtedy
> niedokładności przestają mieć aż takie znaczenie.

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

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

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.

> I poszukaj 595 trochę szybszej serii - HC to przeżytek straszny.

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

Mateusz

do góry

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

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?

Mateusz

do góry

W dniu 2016-05-20 o 15:45, Mateusz Viste pisze:
> On 20/05/2016 14:40, Dariusz Dorochowicz wrote:
>> Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar, wtedy
>> niedokładności przestają mieć aż takie znaczenie.
>
> 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
> 4. 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.

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

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

Gorzej jak uda Ci się uzyskać efekt mory. Może być męczący.

>> I poszukaj 595 trochę szybszej serii - HC to przeżytek straszny.
>
> 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ę.

No więc o to chodzi, żeby się nie bawić w HC tylko wziąć np VHC. Różnica
w cenie jest....

Pozdrawiam

DD

do góry

W dniu 2016-05-20 o 15:39, Jarosław Sokołowski pisze:
> Pan Dariusz Dorochowicz napisał:
>
>>>> Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz
>>>> w MDA, oba zegary Ci się rozjadą.
>>>
>>> Trochę uprościłem z tym 16 MHz - w praktyce jak najbardziej byłoby
>>> to dokładnie tyle co napisane na oscylatorze który mam na karcie
>>> MDA, czyli 16.257000 MHz.
>>
>> Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar,
>> wtedy niedokładności przestają mieć aż takie znaczenie.
>
> 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ł.

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.

Pozdrawiam

DD

do góry

W dniu 2016-05-20 o 16:11, Mateusz Viste pisze:
> 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...
>
> 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?

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

Pozdrawiam

DD

do góry

Pan Mateusz Viste napisał:

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

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

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

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.

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

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.

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

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.

--
Jarek

do góry