Skocz do zawartości

[Kupię] Przetwornik ADC, >3 MSPS, 10 bit


Pomocna odpowiedź

Witam,
Nie udało mi się otrzymać sampli, a ceny w sklepach sięgają kolosalnych sum (o ile w ogóle mają taką część). Więc pytam was ludziska, czy ktoś posiada może walający się, niekoniecznie nowy, ADC o znacznej prędkości? Tak jak w temacie interesują mnie wartości powyżej 3 MSPS. Najchętniej 10-20, jednak nie chciałbym nie wiadomo jak żwawego (bo i cena większa). Obudowy od DIP po TSSOPY i SO mile widziane. Ewentualne inne, które w domu da się polutować, też mogą być.

Cena? Z racji, że raczej nie szukam nowych układów (wręcz z wielką chęcią odziedziczę jakiś z demontażu - byle sprawny), chciałbym się zamknąć w 20 zł z przesyłką.

Ewentualnie przyjmę pomoc przy sprowadzaniu sampli. Bo kosztuje taki układ 3 dolary, a u nas nie jest dostępny. Przykładowo: MAX1425EAI

Ewentualnie, jeśli ktoś miał styczność z obróbką sygnału telewizyjnego PAL, to z chęcią wysłucham rad, wskazówek, sugestii 😉

Link do komentarza
Share on other sites

Jeśli Twoje pierwsze pytanie ma związek z ostatnim, to 3Msps to trochę mało jak na PAL. Chyba, że chcesz łapać ze 100 pixeli w linii i tylko sygnał luminancji (B-W) ale musiałbyś go wcześniej sobie odfiltrować bo inaczej dostaniesz mory od podnośnej koloru.

Zamiast próbować wciągnąć PAL "na piechotę" użyj układu takiego jak MAX9526. Tani jak barszcz, robi całą synchronizację do pola i linii, przetwarza A/D 10 bitowo, a całość wypuszcza w standardzie BT656. Dostajesz zegar z PLL + strumień danych YCbCr + tagi początku ramki/linii, które to dane możesz łapać/obrabiać już wg własnego uznania.

Kiedyś jeszcze Philips robił całą serię układów do telewizji cyfrowej i były to fajne osobne klocki (A/D, multistandard color decoder, color space converter.. itd) nawet miałem tego dużo ale dzisiaj to nie wiem, czy coś z tego zostało w ofercie NXP (i w mojej szufladzie). Jakbyś chciał, to mogę oddać w dobre ręce 😃 przetwornik z rodziny TDA87xx. Na pewno mam sztukę w DIPie (chyba 8703) i na pewno poradzi sobie z sygnałem wizyjnym bez problemu. Przetworniki sygnału video do "ręcznej" zabawy w frame grabbery to była specjalna klasa układów mająca w sobie np. automatykę albo chociaż odcinanie poziomu czerni itp bo inaczej to na samych impulsach synchronizacji traciłeś 1/3 zakresu przetwarzania. Na pewno mam też coś Analoga, 12-bitów, 80MHz max, ale to może być wylut (TQFP) z jakiegoś starego projektu.. Jutro mogę dokładnie sprawdzić.

Napisz co Ci chodzi po głowie 🙂

Link do komentarza
Share on other sites

Liczyłem tylko na B/W. Z początku nie chciałem bawić się w jakieś gotowe dekodery, ale tak teraz pomyślałem, że po co się zajeżdżać? I tak całość będzie dość pracochłonna. Co mam zamiar zrobić: pozyskać sygnał z pegasusa, przetworzyć, wyświetlić na LCD (z Siemensa CX65 póki co). Takie tam moje fanaberie 😉

Trochę czytania jest, więc tak w skrócie, pytając jednocześnie o poprawność: podłączam takiego MAX9526AEI+ do uC żeby odpowiednio skonfigurować rejestry, następnie podłączam do niego sygnał, a wyjściowe bity prosto do uC? Czy mikrokontroler ogarnie ilość docierających danych? Taka ATmega328, bo z atmela to najlepsze co mam.

Link do komentarza
Share on other sites

No nie, tak prosto to nie będzie. Te procesory absolutnie nie mają siły do pracy z sygnałem wizji online. Standartem "w tym temacie" jest strumień 27Msps. Taki zegar (LLC) wychodzi z dekodera i z taką częstotliwością dostajesz kolejne próbki. Jest w tym trochę luminancji (Y), trochę czerwonego (Cr) i trochę niebieskiego (Cb), zgdonie z BT656. Jeśli chciałbyć wciągnąć to do procesora, musiałbyś zapewnić bezpośredni dostęp do jego pamięci RAM (DMA) z zewnątrz a żadna ATmega tego nie potrafi. No i wielkości RAMu nie te..

W zależności od tego co dokładnie planujesz: czy puszczenie video "live" na LCD (fajna zabawka ale po co?) czy też zadowoli Cię kilka klatek na sekundę kotłowanych przez procesor z lewej (wejście) na prawo (wyjście) czy też LCD będzie tylko monitorem np. operacji graficznych które będziesz robił na pojedyńczo łapanych klatkach (lub wręcz jednej), masz kilka wyjść.

Trywialne: użyć procesora mającego wejście z kamery cyfrowej. To właśnie jest taki równoległy port z DMA do RAMu, specjalizowany do łapania strumieni video. Jest tam możliwość np. rozdzielania luminancji od kolorów, synchronizacji do tagów wplecionych w strumień lub do typowych sygnałów HSYNC, VSYNC itp. Przykład: Atmel AT91SAM9G45 (interfejs ISI) lub inny, podobnej klasy procesor.

Pośrednie 1: to zależy od tego, czy upierasz się przy AVR. Jeśli tak, to jesteś skazany na ich marniutką moc obliczeniową i prędkość. Video to jednak duże ilości szybko napływających danych i nawet rozkręcona do 20MHz ATmega niewiele tu może zdziałać. W każdym razie mogę sobie wyobrazić rozwiązanie w którym między dekoder a procesor wstawiasz układ (np. jakiś CPLD) który:

a) umie wyłapać tagi synchronizacji by jakoś ogarnąć początek pola i linii,
b) wybiera ze strumienia np. tylko Y i tylko co któreś słowo oraz prezentuje je zatrzaśnięte np. w jakimś rejestrze tak, by ATmega mogła to spokojnie wczytać przez port. Tą metodą mógłbyś wczytać pewnie ze 100 pixeli B-W w linii.

Pośrednie 2: Użyć procesora który nie ma dedykowanego portu video ale za to jest wystarczająco szybki by nadążyć za strumieniem BT656 np. jakiegoś DSP. Mogę oddać w dobre ręce różne procki Texasa, z rodziny 320(V)C54xx np. TMS320VC5416. To stałoprzecinkowy, 16-bitowy DSP, którego używałem lata temu do różnych projektów. Po rozkręceniu PLLa do 160MHz daje naprawdę fajną moc. Gdyby podłączyć dekoder video do szyny pamięci zewnętrznej i zsynchronizować całość, spokojnie by wciągnął pełną ramkę do swojego RAMu.

Pośrednie 3: Między dekoder a procesor wstawiasz np. FIFO. Mam do oddania różne, np. 1024 bajtowe Cypressa. To bardzo szybki dual-port-RAM ale pozbawiony wejść adresowych. Z jednej strony ma 9-bitowe wejście (tak, 9-bitowe, to taki standart w FIFO) i sygnał zapisu a z drugiej 9 bitów i sygnał odczytu. Strona zapisująca dostaje też sygnał "FIFO Full" i wtedy nic już się nie zmieści a odczytująca sygnał "FIFO Empty" i wtedy nic już odczytać się nie da. Prosty układ CPLD wybierałby jedną, wskazaną przez procesor linię z całego pola i wczytywał ją z pełną prędkością do FIFO po czym sygnalizował ATmedze, że "gotowe". Ta by FIFO opróżniała z dowolną, wygodną prędkością i prosiła o następną linię obrazu. Taki proces, powtarzany wielkrotnie spowodowałby wciągnięcie całego obrazu ale trwałoby to tyle ramek ile linii chcemy wczytać czyli.. wiele sekund. To się raczej nadaje do still-video ale ograniczenia procesora robią swoje.

Pośrednie 4: układ CPLD + mały SRAM np. 32 lub 128Kbajtów łapią całą ramkę z dekodera na żądanie procesora, dają znać, że gotowe a potem umożliwiają jej wciągnięcie np. przez SPI bez konieczności ciagnięcia od procesora mnóstwa drutów, adresowania pamięci itp

Low cost: bierzesz w miarę szybki przetwornik A/C i synchronizujesz się do pola i linii (sygnały SYNC z kamerki analogowej). W każdej linii odmierzasz jakiś czas od jej początku i zaczynasz próbkować z maksymalną dla procesora szybkością. W ten sposób wciągasz kilkanaście pixeli w każdej linii. W następnej ramce robisz to samo ale "trochę dalej "od początku linii i tak kilka(naście?) razy aż przesuniesz sie na tyle by pierwszym próbkowanym pixelem podjechać do oryginalnej pozycji drugiego. W ten sposób po kilku(nastu) ramkach masz cały obraz w procku tylko wcześniej.. pamięci pewnie zabraknie.

No i pewnie jeszcze całe mnóstwo innych rozwiązań, których nie ma co opisywać dopóki sam dokładnie nie będziesz wiedział co chcesz zrobić i jakie cele osiagnąć.

  • Pomogłeś! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

O cholera 😃

Myślałem, że takie 20 MHz wystarczy do przetworzenia obrazu w mikrokontrolerze. Chciałbym uzyskać znośny obraz rzędu 15-20 fps. Sygnał PAL wydawał się "prymitywny". No i zabawka, bo cóż innego? Postawiłem sobie cel, żeby przez zabawę i dążąc do zabawy, się czegoś nauczyć.

Co do procków, to mam TMS320F28027DAS, no ale to w szczycie daje 60 MHz (plus fakt, że nie ruszyłem go nawet bo...nie było kiedy). CPLD to kosmos dla mnie.

AVR daje radę, jeśli chodzi o generowanie prostego obrazu. Myślałem, że raptem kilkukrotnie większym nakładem da radę zrobić dekoder.

Twoja wiedza na wszystkie tematy mnie zdumiewa. Wszędzie jesteś w stanie się wypowiedzieć, rzadko kiedy krócej niż na kilkaset słów. Podziwiam 😉

Dalsze prowadzenie tego wątku tutaj nie ma sensu. Temat można zamknąć. I tak już dużo "naśmiecone".

Ewentualną kontynuację możemy prowadzić via prv, ale nie chciałbym aż tak wykorzystywać 😉

Link do komentarza
Share on other sites

E tam, zaczynałem gdy sam procesor składał się z 3 scalaków nie licząc pamięci i peryferiów a karty graficzne robiło się z TTL więc miałem naprawdę dużo czasu by pobawić się w różne rzeczy. I tak wciąż brakuje mi doby by nadążać.

Gdybyś wciąż miał ochotę na frame grabber, pisz na priv - po to przecież jest 🙂

Link do komentarza
Share on other sites

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.