ADV/7181C/LQFP - Czy 80 megahercowy kontroler ARM Cortex obsłuży dekoder video?

Witam,
jest bardzo fajny dekoder video – Analog Devices ADV7181C. Na wyjściu jest np. 8-bitowy YCbCr 4:2:2. Przypomina to tę kamerkę:
http://www.arducam.com/camera-modules/0-3mp-ov7670/
Chciałem zdekodować PAL/NTSC, wczytać przez Texas Instruments Tiva C (80-MHz ARM Cortex MCU), przeskalować, wyświetlić na matrycy LED.

Support TI napisał mi że Tiva C nie obsłuży tego chipu AD ponieważ wyjście wideo jest taktowane 110MHz. Tutaj jest datasheet:
https://www.digchip.com/datasheets/parts/datasheet/041/ADV7181C-pdf.php

Czy to ma sens? Skoro zwykłe Arduino potrafi odczytać dane od kamerki, to dlaczego wielokrotnie silniejszy ARM nie miałby odczytać
podobnych danych od dekodera video?

PS. Dostępne tryby wyjścia dekodera wideo – będę używał pierwszego 8-bit 4:2:2: imgur.com/a/6yeYx

Pozdrawiam,
Sebastian

110MHz jest maksymalną częstotliwością taktowania ADV7181C, minimalna wynosi 12.825MHz. Ten procek powinien tyle obsłużyć.

tantalos1 napisał:

110MHz jest maksymalną częstotliwością taktowania ADV7181C, minimalna wynosi 12.825MHz. Ten procek powinien tyle obsłużyć.

Właśnie znalazłem że chodzi o wyjście LLC. Każdy tick tego wyjścia to jeden piksel z P0-P19, na ile to rozumiem.

W międzyczasie wyszło, że 32 kB pamięci to za mało żeby wczytać ramkę PAL czy NTSC (576i, 480i). Z tym, że chcę przeskalować do 32x16 dla matrycy LED tych wymiarów. Mógłbym robić skalowanie online? Każde 18 pikseli uśrednić, zapamiętać jeden. Każde 45 linii uśrednić, zapamiętać jedną. 45 linii oczekujących na uśrednienie to 45 x 32 = 1.44 kB. Wygląda na wykonalne..

Piotrus_999 napisał:

Wątpię - ale trzeba byłoby dokladnie policzyć.

Ktoś miał pomysł żeby podłączyć LLC jako przerwanie do Tivi.. Ciekawe czy to ma szansę, i do ilu MHz, do 60 MHz na przykład (na LLC)? W każdym przerwaniu bym robił to skalowanie w locie do 32x16.. Ale też dowiedziałem się że są jakieś niuanse Nyquista z down-scalingiem, że są możliwe artefakty. W każdym razie zrobiłem diagram blokowy tematu, z interfejsami jakie ma Tivia (PS. ma też uDMA):




Ta Tivia to jest niezła maszynka, tutaj pełen spis funkcjonalności: http://imgur.com/a/jHxOJ a tutaj datasheet: http://www.ti.com/lit/ug/spmu296/spmu296.pdf

Gortu napisał:

Ciekawe czy to ma szansę, i do ilu MHz, do 60 MHz na przykład (na LLC)?

Samo wejście i wyjście z przerwania (nie licząc ŻADNEGO KODU) to 12 cykli zegara. Tak więc przy 80MHz zegara rdzenia przerwania zewnętrzne z częstotliwością ledwo kilku MHz zasadniczo zajmą Twój układ w 100% samym wchodzeniem i wychodzeniem z przerwań.

Tak sytuacja się klaruje, nie da rady. Może jeszcze – ktoś napisał że może uDMA da radę, bo jest zdolne przesłać jeden bajt na każdy trigger pinu GPIO. Ale bez większej wiedzy nie wydam pieniędzy i nie dokończę płytki – choć Tivia C tania, 67 zł, ADV też, 44 zł.

Że też nie ma jakiegoś DSP do tego (skalowania), przecież YCbCr to taki standard, wszechobecne raczej.

Piotrus_999 napisał:

Weź procesor z większymi zasobami np stm4 stm7 płytki nucleo. Tam po prostu wczytasz do ram i możesz dowolnie obrabiać przed wysłaniem. Masz instrukcje dsp, oraz bogate peryferia i dużo ramu

Dziwne ale Google nie znajduje, mógłbyś dać linki do stm4 i stm7? Z tego co piszesz będą miały zegar > 0.6 GHz i więcej ramu, a może przez DMA do pojemniejszego RAMu wtedy CPU może być słabszy. Uratowałbyś mi życie

Piotrus_999 napisał:

Sorki stm32f4 i f7

Dziwne że większość datasheet i stron w sklepach nie wyszczególnia ilości pamięci. Dla F4 znalazłem dwa boardy z 192kB, trochę za mało (potrzeba 414 kB dla ramki PAL 576i). Nie mogłem także znaleźć informacji o DMA.

Pomyślałem o Raspberry Pi. Nie chciałem go żeby mieć rozwiązanie o ładnym klimacie "biega MCU, nie komputer", ale jeżeli to by się opierało o DMA a nie o męczenie CPU, to co innego. Ale gościu mi napisał o DMA i wysokich częstotliwościach portu (o RPi):

"i think i had trouble bit-banging anything past 20mhz reliably, it felt like it was a sort of FSB issue, and that the gpio side of the die was just not clocked fast enough"

Ten limit jest potwierdzony tutaj, dla RPi 1 (jest też link do v.2): http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/

Napisz co chcesz zrobić...
Zawsze możesz użyć zewnętrznej pamięci i jakiejś logiki na CPLD/FPGA.
ARM (i generalnie większość tego typu nowoczesnych mikroprocesorów średnio radzi sobie z bitbang).

deus.ex.machina napisał:

Napisz co chcesz zrobić...
Zawsze możesz użyć zewnętrznej pamięci i jakiejś logiki na CPLD/FPGA.
ARM (i generalnie większość tego typu nowoczesnych mikroprocesorów średnio radzi sobie z bitbang).

Tutaj jest blokowy diagram urządzenia. Połączenie z matrycą LED nie stanowi problemu:



Wiadomo już że Tivi nie użyję. Chcę wyświetlać obraz z kamerek PAL, taki efekt specjalny sterowany obrazem PAL, wyświetlany na matrycy LED 32x16. Chcę użyć posiadanej kamery PAL. Tutaj ktoś zrobił to poprzez telefon z Androidem, tam przetwarza obraz biblioteką OpenCV:

http://nootropicdesign.com/projectlab/2012/01/22/displaying-android-video-on-led-matrix/

Czy te tanie breakouty CPLD mają sens? Tańszych na Farnell nie ma:

LC4256ZE-B-EVN
210-047-C2
LCMXO2280C-B-EVN

Piotrus_999 napisał:

Programowałeś kiedyś układy FPGA? Znasz VHDL np.? To jest trochę inna bajka niż uC.

Nie programowałem, w 5-letnim technikum tego nie było. Największym problemem jest brak podstawowych danych. Czy mogę kupić breakout FPGA? Bo co zrobić z chipem na 100 kulkach. Czy są tanie programatory, żeby się zamknąć z breakoutem i programatorem w 200zł? Kodować mogę się nauczyć mam 6.5 lat doświadczenia w różnych językach.

Znalazłem fajny artykuł – o upychaniu pikseli na wyjściu STM32F407. Gościu skonfigurował DMA odwrotnie: pamięć uC (źródło) jako peripheral, GPIO jako memory – dzięki temu nie musiał używać DRQ podczas transferu – i uzyskał 1/4 głównego zegara poprzez DMA – piksele na 42 MHz (1/4 168 MHz). Myślę że to ważne bo tutaj sprawa się rozchodzi o to że pixel porty są szybkie i zakłócenia np. pojemnościami mają duży wpływ. Tutaj jest informacja że STM fizycznie daje radę z 42 MHz na GPIO, poprzez DMA. Ale RAMu za mało na ramkę PAL/NTSC, 192 kB. Także ostatecznie – jest jakaś szansa na odczyt danych taktowanych 42 MHz, są sprzęty dające radę (choć RAMu za mało).

http://cliffle.com/article/2015/06/06/pushing-pixels/

Może podasz więcej założeń projektowych.

Ile ramek na sekundę chcesz wyświetlać?
Czy masz już opracowany algorytm skalowania?
Czy robiłeś eksperymenty jak wygląda obraz na wyświetlaczu o tak małej rozdzielczości?

Pozdrawiam
JarekC

JarekC napisał:

Może podasz więcej założeń projektowych.

Ile ramek na sekundę chcesz wyświetlać?
Czy masz już opracowany algorytm skalowania?
Czy robiłeś eksperymenty jak wygląda obraz na wyświetlaczu o tak małej rozdzielczości?

Pozdrawiam
JarekC

Chciałbym wszystkie ramki, albo ile się da. Nie mam tego algorytmu ale robiłem research że Nyquist będzie miał wpływ. Wygląd obrazu wkleiłem wyżej:

http://nootropicdesign.com/projectlab/2012/01/22/displaying-android-video-on-led-matrix/

Przy takiej rozdzielczości możesz zrobić to trochę inaczej - zewnętrzny dekoder PAL do RGB, akwizycja RGB przy pomocy wbudowanego ADC, możesz zrobi układ sample & hold na CD4066, 32 piksele na linie to będzie jakieś 1.5uS na piksel, dodawałbym ok 18 linii w pamięci (288/16) i miałbyś dane do wyświetlenia na matrycy 32x16.

Popatrzyłem na układy które chcesz użyć i powiem ci ze wybrałeś drogi dekoder video (wielokrotnie droższy niż uC) a uC po porstu nie nadający się do tego co chcesz robić - już prędzej zainteresowałbym się choćby prostym https://getchip.com/pages/chip - masz tam port BT.656 i zasoby by w czasie rzeczywistym nie tylko obrabiać video ale tez dekodować pliki multimedialne.

Piotrus_999 napisał:

Nie proponuj tego bo to jest przekrét. ludzie nie dostali zamówionych juz od wielu miesiecy. Przecztaj blog ludzi z Olimex - to Ci sie otworza oczy

Nie wiem, szukałem czegoś taniego z wejściem video i z możliwości uruchomienia Linuxa - oczywiście można poszukać innego wyjścia - np RPi i akwizycja sygnału video przez USB (prosty konwerter CVBS USB) do tego wyświetlacz na WS2812B (SPI da rade) - można pokusić się wtedy o wyższą rozdzielczość bo 32x16 to straszna bida - powiedzmy ze 64x48 da już możliwość rozpoznania obrazu.

Piotrus_999 napisał:

RPi zero -----------

Np i wtedy właśnie trzeba użyć jakiegoś rozwiazania po USB by wprowadzić sygnał wizyjny - tak czy siak będzie to łatwiejsze i chyba bardziej sensowne niż budowanie czegoś z łączonych na silę elementów.

Problemem jest prędkość pixel portu – 12 MHz do 110 MHz. Nie tylko potencjalnie wysoka częstotliwość, ale również to, że dla PAL/NTSC będzie to bardzo bliskie 12 MHz (niby dobra wiadomość) – kolejne ramki są wtedy w małych odstępach, nie można poczekać na całą ramkę i potem poświęcić trochę cykli na downsize do 16x32. Dekoder wypycha dane z takim uporządkowaniem i prędkością jak w sygnale PAL. Info o 12 MHz mam od autora tego dema co generuje obraz bez karty graficznej: youtube.

Dla 576i (tylko czy to nie 625i jednak, z dodatkowymi liniami z meta-danymi..) liczba pikseli to 576 * 720 = 414720. Zakładając częstotliwość 12 MHz czas na spłynięcie jednej ramki to: 414720 / 12000000.0 = 34 ms. Czas pomiędzy ramkami dla FPS 25 to: 1/25 = 40 ms. Czyli zostaje 6 ms na downscaling, wydaje się to mało? Interpolacji się nie zrobi. Wygląda, że potrzebny jest sprzętowy downscaling co ma tylko niewielką liczbę cykli opóźnienia pomiędzy wejściem a wyjściem?

Dla NTSC te liczby to: 345600 / 12000000.0 = 28 ms (czas spłynięcia 1 ramki) oraz 1/30 = 33 ms (czas pomiędzy ramkami). Zostaje 5 ms.

Dla 1 GHz procesora dostępny czas CPU po każdym pikselu to: 1000000000 / 12000000 = 83 cykle. Dla 168 MHz CPU (STM32) jest to: 168000000 / 12000000 = 14 cykli. Tu te cykle są trwonione, bo generalnie przewaga CPU jest duża, to jednak cykle są rozproszone w krótkich okresach po odebraniu piksela.

Chodzi też o wydajność pinów. Jak szybko mogą się przełączać. Tutaj jest sprawdzone, że STM32 potrafi 42 MHz: pushing pixels. Tylko, że są chyba różni producenci wykorzystujący STM32, różne płytki mają różne pojemności na płytce i w różnym stopniu wygładzają sygnał? W każdym razie znalazłem (wikipedia) płytki z 0.5 MB ramu: NUCLEO-F767ZI, tylko że 8 bitów na piksel (te 414k) to może być obraz czarno biały, a dla 16 bitów na piksel potrzeba 1 MB ramu. Wtedy bym wczytał całą ramkę, ale to i tak bez sensu, bo jest 6 ms na downscaling.

Także ostatecznie możliwe jest chyba: DMA pomiędzy pixel portem ADV7181C a GPIO płytki z STM32, zapamiętywanie co 22 piksela (720 / 32), co 36 linii (576 / 16). Tylko nie wiem jak taki downscaling będzie wyglądać.
Dodano po 19 [minuty]:

Piotrus_999 napisał:

deus.ex.machina napisał:

jakiegoś rozwiazania po USB by wprowadzić sygnał wizyjny

Po co - przecież RPI zero ma interfejs MIPI-CSI2. Wystarczy jakiś dekoder pal z takim wyjściem (a jest ich dużo) i już.

Na tej stronie napisano, że RPi ma MIPI-CSI2 zrobiony pod oficjalny moduł kamery RPi, że nie da go się użyć z ADV7280-M bo nie jest tak naprawdę standardowy. Szkoda, bo to fajny dekoderek, wspiera 3 analogowe standardy wejść i ma mało pinów.

UPDATE: Policzyłem ile to jest 5 ms na 168 megahercowym STM32: 168000000 * (0.0333333 - 0.0288) = 761594 cykli. Tyle zostaje po odebraniu ramki NTSC na zrobienie downscalingu. Wystarczy?

Problemem z MIPI CSI2 jest mala ilość gotowych mostków spinających ten port z otoczeniem (gdyby było coś takiego łatwo dostępne to już dawno zbudowałbym sobie flicker fixer z 3D karta graficzna i koprocesorem do Amigi).
Użycie RPi jest fajne bo jest to w tej chwili najprzystępniejszy cenowo duży ARM z pełną dokumentacja dla programisty co pozwala na użycie go nawet bez Linuxa.
Co od operacji programowych - nie ma takiej potrzeby bo RPi ma dedykowany sprzęt graficzny który wykonuje wszystko czego potrzeba.
Niestety ponieważ RPi używa MIPI CSI2 to najtańszym sposobem dostarczenia sygnału wideo jest właśnie USB i jak myślę jeśli autorowi zależy na sukcesie tzn działającym rozwiązaniu to będzie to najsensowniejsze.
A teraz trochę rachunków.
Po pierwsze w przypadku sygnału video wygodniej operować na sygnale w przestrzeni YCbCr niż RGB (a jeśli zastosujemy 4:2:0 powszechne w konsumenckim video to redukujemy ilość danych o 50%)
Ponieważ rozdzielczość wyświetlacza jest niska nie musimy robić akwizycji pełnej rozdzielczości - w zupełności wystarczy nam 352x288 i 25 klatek na sekundę (to bedzie i tak ponad 100x oversampling) - to oznacza ze już na wejściu korzystając z dedykowanego HW (USB) znacząco redukujemy ilość danych do przetwarzania.
Wyprowadzenie danych jak już napisałem SPI (DMA) i WS2812B - nie będzie ani taniej ani lepiej.
Dodatkowo w RPi mamy GPU które może wykonać wszystkie operacje na grafice wielokrotnie szybciej niż CPU.
Przy dwóch buforach można robić akwizycje danych w jednym i operacje na drugim - 40ms na bufor .

Dodano po 3 [minuty]:

Piotrus_999 napisał:

deus.ex.machina napisał:

jakiegoś rozwiazania po USB by wprowadzić sygnał wizyjny

Po co - przecież RPI zero ma interfejs MIPI-CSI2. Wystarczy jakiś dekoder pal z takim wyjściem (a jest ich dużo) i już.

Ano w tym problem ze jest ich mało - Toshiba robi dwa mostki MIPI CSI2 ale ich dostępność może być problemowa, dla RPi dostępny jest moduł akceptujący HDMI na wejściu wiec potrzeba jeszcze konwerter CVBS/VGA na HDMI.

Szukając o MIPI CSI2 trafiłem na ADV7280(-M). Co za wspaniały chip – tylko 32 piny! Nie ma podziału na dwa procesory SDP (standard proc.) i CP (component proc.), wszystkie funkcjonalności upakowane w jednym procesorze video. To oznacza że autodetekcja standardu wejścia PAL/NTSC jest zawsze, nie tylko w SDP, i że jeżeli SDP miał jakiś np. filtr którego CP nie miał, to teraz ten już jeden procesor to ma. Przykładem jest filtr 2D Comb, dostępny tylko w trybie SDP. Odporność na zakłócenia VCR jest zawsze, nie tylko dla wejść Composite i S-video. I chyba najważniejsze: I2P, konwersja interlaced do progressive! Tego ADV7181C w ogóle nie ma. Jak będę odbierać dane przez DMA do np. STM32 to wielka różnica czy muszę coś mieszać z dwoma rodzajami ramek parzyste/nieparzyste czy nie. Ze strat to niepełne wsparcie SCART (tzn. ten FBLINK, co pozwala nanosić OSD na obraz), brak wzmianki o RGB (ale component to po prostu YPrPb i już, czyż nie? jeżeli nie, i może być RGB, to ten ADV7280 po prostu musi to wspierać i tylko nie napisali), mniej dostępnych formatów na wyjściu (po prostu 8 bit YCrCb 4:2:2 i już). Wersja -M, dostępna w Farnell, ma MIPI CSI2. Może ktoś zna MCU z ładnie biegającym MIPI CSI2? Raspberry Pi 2 jest droogie i podobno ma niestandardowe MIPI CSI2.. Plus jeszcze te problemy z mostkiem.

Taktowanie pixel portu zamiast "12-110MHz" stoi: "The clock output is nominally 27 MHz but it increases or decreases according to the video line length." Od razu rozsądniej, bez bajdurzenia o możliwych 100 megaherzach.

Napiszę jeszcze o jednej rzeczy tylko – napięcia wejściowe. Było (7181C):

AVDD = 3.15 V to 3.45 V, DVDD = 1.65 V to 2.0 V, DVDDIO = 3.0 V to 3.6 V, PVDD = 1.71 V to 1.89 V

czyli 4 różne napięcia. Jest (7280):

AVDD, DVDD, PVDD, and MVDD = 1.71 V to 1.89 V, DVDDIO = 2.97 V to 3.63 V

Czyli dwa napięcia Teraz to można spokojnie robić PCB, 32 piny to nie 64, dwa napięcia to nie cztery BTW czy muszę dostarczyć kryształ bo jest napisane: XTALP – "Connect this pin to the external 28.63636 MHz crystal, or leave it unconnected if an external 1.8 V, 28.63636 MHz clock oscillator source is used to clock the ADV7280. The crystal used with the ADV7280 must be a fundamental crystal."