Mateusz Viste <mateusz.viste@localhost> wrote:
> On 18/05/2016 10:56, Jaros?aw Soko?owski wrote:
> > ale zapu?ciwszy gugla znalaz?em co? takiego:
> > http://aknamunka.uw.hu/mdah/1st.html
>
> Tak, czyta?em to ju?, a tak?e Cezar podawa? ten link 3 dni temu. To
> wymaga jednak ingerencji w sam? kart? MDA, a to niekompatybilne z moimi
> za?o?eniami (moje za?o?enia: be?owe pud?o wraz z wszystkimi swoimi
> wn?trzno?ciami to ?wi?to?? i nie nale?y w og?le go otwiera? - mog? tylko
> podpi?? si? do pin?w MDA z ty?u, i to tylko z nale?ytym szacunkiem i
> najwy?sz? pokor? nie patrz?c dziurkom prosto w oczy). :)
>
> P?ki co mam kilka trop?w:
> - RPi z MDA wpi?tym do GPIO (czekam na drobne cz??ci by to przetestowa?)
> - AVR kt?ry zczytuje MDA i podaje co drug? lub co trzeci? klatk? do
> RPi po jakim? SPI
> - monitor kt?ry obs?uguje 720x350 (?aden z moich LCD nie ?apie
> niestety, a do CRT chwilowo nie mam dost?pu)
> - GBS8200 (zam?wione, zobaczymy czy da si? nam?wi?, czytaj?c
> specyfikacje mam jednak du?e w?tpliwo?ci)
> - "scan doubler" kt?ry przerabia?by 720x350 na 720x700 (ale nie mam
> poj?cia jak taki doubler mia?by wygl?da? z punktu widzenia elektroniki)
>
> Czyta?em jeszcze o rzeczach typu FPGA i CPLD, ale to ju? dla mnie level
> 99 - a ja jednak bardzo chcia?bym uzyska? jaki? efekt przed rokiem 2030.
>
> Jak si? okazuje, mimo technologicznego post?pu, odczyt sygna??w
> cyfrowych o szybko?ciach rz?du 15 MHz to nie taka trywialna sprawa.

Normalnie w technice cyfrowej masz sygnaly synchroniczne, tzn. jest
zegar i sygnaly zmieniaja sie w ustalenej relacji do zegara, np.
po rosnacym zboczu zegara. Sygnal wideo nie zawiera zegara, wiec
jesli go probkujesz uzywajac nezalezny zegar powiedzmy 15 MHz to
nie wiesz ktory piksel czytasz, dany czy nastepny. Zeby w miare
prosto czytac taki sygnal potrzebujesz zegar powiedzmy 4 razy szybszy,
czyli rzedu 53 MHz. Jesli chcesz to robic w prosty sposob
programowo to bedziesz mial kilka instrukcji na probke, czyli
200-300 MIPS.

Co do twoich tropow:
- zapomij o Arduino. Jest program AVRIsp ktory czyta sygmal
USB low speed, tzn. 1.5 MHz. To jest rzezba asemblerowa
ktora trudno by polepszyc.
- GPIO w rPI tez nie daje rozsanych szans. Ludzie probowali
na GPIO robic podobne rzeczy i powyzej 100 kHz sa problemy.
Jak napiszesz w asemblerze driver jadra to sa mozliwe
wyzsze czestotliwosci, ale nie jest jasne czy bedzie lepiej
niz w Arduino. Procesor w rPI moze wykonac duzo wiecej
instrukcji niz procesor w Arduino ale odbywa sie to kosztem
tego ze nie wiesz kiedy te instrukcje beda wykonane.

Jesli myslisz o realizacji programowej to jakis (male) szanse
masz z procesorami klasy STMF4 czy STMF7 -- masz mozliwosc
czytania lini GPIO z czestoscia rzedu 40 MHz. Rozsadniejszym
rozwiazaniem moze byc uzycie sprzetowego SPI w procesorze --
w zasadzie SPI zbiera strumien bitow na wejsciu i zamienia go
na bajty. Ale potrzebujesz procesor gdzie SPI chodzi do 50 MHz
i nie ma przerw miedzy bitami. Specyfikacja SPI mowi ze transmisja
jest sterowana zegarem a procesor generujacy zegar moze robic
przerwy gdzie mu sie podoba (podobno procesor uzywany w
Arduino robi przerwe po kazdym bajcie). Dokladniej, jesli
SPI dziala w trybie master to procesor generuje zegar transmisji
i teoretycznie moze robic przerwy kiedy chce. Czysto teoretycznie
mozna ustawic procesor w tryb slave i podlaczyc mu zewnetrzny
zegar 50 MHz (ale tryb slave czesto ma mniejsza maksymalna
czestotliwosc niz master).

Co do "odczytu sygnalow 15 MHz": ty faktycznie chcesz zmiany
zegara transmisji (konwersji) co wymaga wyzszych czestotliwosci.
Nie jest to technicznym problemem ale jak uzyjesz staromodne
uklady to bedzie ich troche. No a nowoczesne uklady maja
swoje komplikacje. W przypadku procesora uzycie go do
czytania sygnalu jest marnotrawstwem, uzywasz skomplikowanego
urzadzenia zeby zrobic cos co robi prosty rejestr przesuwajacy.
Przy malych szybkosciach to marnotrawstwo nie boli, ale
przy 50 MHz rozne rzeczy ktore robi procesor moga zabierac
zbyt wiele czasu by to dobrze dzialalo.

--
Waldek Hebisch