Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

Gortu 10 Sty 2017 11:00 1524 52
  • #31 10 Sty 2017 11:00
    deus.ex.machina
    Poziom 31  

    Jak z dostępnością ADV7280? Kolega Piotrus_999 już napisał ze RPi Zero w sytuacji gdy chcesz użyć MIPI CS2 - taniej niż 5$ z taka ilością RAM nie będzie.

    Co do pytań - nie obraz się ale spróbuj przeczytać ze zrozumieniem dokumentacje bo inaczej nie zrobisz tego projektu.
    Masz dwa napięcia tak czy siak tylko masz oddzielne linie dla części cyfrowej i analogowej (co implikuje odpowiedni routing PCB i konieczność użycia np dławików by oddzielić od siebie sekcje).
    Możesz użyć albo kwarcu albo generatora, generator musi posiadać poziom 1.8V dla logicznej '1', jeśli kwarc to nie może być typu overtone (częstotliwość drgam podstawowych musi mieć te 28MHz).

  • #32 10 Sty 2017 11:48
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    Jak z dostępnością ADV7280? Kolega Piotrus_999 już napisał ze RPi Zero w sytuacji gdy chcesz użyć MIPI CS2 - taniej niż 5$ z taka ilością RAM nie będzie.


    Jest w Farnell .

    deus.ex.machina napisał:
    Co do pytań - nie obraz się ale spróbuj przeczytać ze zrozumieniem dokumentacje bo inaczej nie zrobisz tego projektu.


    Przeczytam na razie staram się rozeznać, pracuję nad tym po 7 godzin dziennie, tyle zajmuje samo wyszukanie układów, uC i ustalenie co i jak :/ Jestem po technikum elektronicznym ale niestety obliczanie napięć dla tranzystora i superpozycja z Kirchofem itp. plus RLC to byłoby tyle.

    deus.ex.machina napisał:
    Masz dwa napięcia tak czy siak tylko masz oddzielne linie dla części cyfrowej i analogowej (co implikuje odpowiedni routing PCB i konieczność użycia np dławików by oddzielić od siebie sekcje).
    Możesz użyć albo kwarcu albo generatora, generator musi posiadać poziom 1.8V dla logicznej '1', jeśli kwarc to nie może być typu overtone (częstotliwość drgam podstawowych musi mieć te 28MHz).


    Dzięki!

    Okazuje się że deinterlacer w ADV7280 to interpolacja brakujących linii z tych sąsiednich istniejących. Raczej bym nie chciał patrzeć na sztuczny obraz, gdzie połowa linii to jakieś średnie. Mają patenty które usuwają low-angle noise powstały w ten sposób i niby ma być OK, ale to dalej są sztuczne średnie IMO. Poza tym włączenie I2P podwaja częstotliwość pixel portu z 27 MHz do 54 MHz. Dwa razy więcej danych do wysłania. A że ja i tak będę skalował poprzez DMA w STM32 pomijając piksele i linie... Podobno można to zrobić poprzez timer-counter peripheral, ustawiony aby był zewnętrznie taktowany przez ADV7280, aby generować zdarzenie DMA co każde 22 zbocza zegara – i w nim zapisać piksel. To da szerokość 32 pikseli, bo 720 / 22 = 32. Aby uzyskać zdecymowaną wysokość podobno można wywołać przerwanie na sygnał HSYNC – to przerwanie by blokowało odpowiednio całkowicie łąpanie pikseli lub pozwalało na to pobieranie tego 1 na 22. Pytanie jaki to da efekt, ciekawe że ten ADV ma filtry anti-alias, a one są potrzebne (ale czy dokładnie takie?) jak się robi downscaling, to wynika z częstotliwości Nyquista, dotyczy bezpośrednio downscalingu.

    Do zrobienia jest SCART -> YPbPr. Niby są układy ale będę musiał wyciągać sygnał(-y?) synchronizacji z pinu Composite SCART. Lepsze to niż 64 piny.

  • #33 10 Sty 2017 12:45
    deus.ex.machina
    Poziom 31  

    Gortu napisał:

    Przeczytam na razie staram się rozeznać, pracuję nad tym po 7 godzin dziennie, tyle zajmuje samo wyszukanie układów, uC i ustalenie co i jak :/ Jestem po technikum elektronicznym ale niestety obliczanie napięć dla tranzystora i superpozycja z Kirchofem itp. plus RLC to byłoby tyle.


    Chodziło mi o to ze bez zrozumienia dokumentacji będzie ci bardzo trudno uruchomić ten układ - do elektroniki dojdzie ci masa programowania - tak wysokopoziomowego jak i niskopoziomowego.

    Gortu napisał:

    Okazuje się że deinterlacer w ADV7280 to interpolacja brakujących linii z tych sąsiednich istniejących. Raczej bym nie chciał patrzeć na sztuczny obraz, gdzie połowa linii to jakieś średnie. Mają patenty które usuwają low-angle noise powstały w ten sposób i niby ma być OK, ale to dalej są sztuczne średnie IMO.


    Ok, to teraz zderzę cie z faktami:

    SDTV to maksymalnie 720 pikseli w linii i 576 linii - to dotyczy sygnału luminancji, sygnał chrominancji t 1/4 sygnału luminacji czyli 360x288.
    To wszystko 25 razy na sekundę.
    Najprostszy deinterlacing (poza odrzuceniem półobrazów)to field blending- najprościej uzyskać go dokonując zmniejszenia obrazu dokładnie o połowę w jakimś układzie interpolacji - w wypadku RPi taki układ znajduje sie w części procesora graficznego - wszystko co musisz zrobić to użyć go.

    Nie martw się jakimiś średnimi przy deinterpolacji - przy rozdzielczości twojego wyświetlacza (32x16) nie zobaczysz żadnej różnicy - tak naprawdę ty potrzebujesz tych średnich tak bardzo jak się da ale to powinno eis stać w RPi przy użyciu dedykowanego resizera.


    Gortu napisał:

    Poza tym włączenie I2P podwaja częstotliwość pixel portu z 27 MHz do 54 MHz. Dwa razy więcej danych do wysłania. A że ja i tak będę skalował poprzez DMA w STM32 pomijając piksele i linie... Podobno można to zrobić poprzez timer-counter peripheral, ustawiony aby był zewnętrznie taktowany przez ADV7280, aby generować zdarzenie DMA co każde 22 zbocza zegara – i w nim zapisać piksel. To da szerokość 32 pikseli, bo 720 / 22 = 32. Aby uzyskać zdecymowaną wysokość podobno można wywołać przerwanie na sygnał HSYNC – to przerwanie by blokowało odpowiednio całkowicie łąpanie pikseli lub pozwalało na to pobieranie tego 1 na 22. Pytanie jaki to da efekt, ciekawe że ten ADV ma filtry anti-alias, a one są potrzebne (ale czy dokładnie takie?) jak się robi downscaling, to wynika z częstotliwości Nyquista, dotyczy bezpośrednio downscalingu.


    Mieszasz tak wiele rzeczy ze zaczynam się gubić. Nyquist nie jest twoim zmartwieniem przy tej rozdzielczości (32x16).

    Antialising w tym układzie mówi ze nie trzeba budować żadnego dodatkowego filtru dolnoprzepustowego bo układ próbkuje sygnał video 4x szybciej wiec filtracja dolnoprzepustowa jest samoistna (nie powinno być sygnału o częstotliwości bliskiej Nyquista w sygnale).

    Gortu napisał:

    Do zrobienia jest SCART -> YPbPr. Niby są układy ale będę musiał wyciągać sygnał(-y?) synchronizacji z pinu Composite SCART. Lepsze to niż 64 piny.


    SCART ma sygnał CVBS - możesz użyć go bo rozdzielczość twojego wyświetlacza jest mizerna w porównaniu z parametrami najgorszego CVBS (najgorszy CVBS niesie 100x więcej danych niż możesz wyświetlić na swoim wyświetlaczu).
    A zrobienie konwertera SCART RGB na YPbPr to pikuś w porównaniu ze skomplikowaniem tego projektu - szacuje ze elektronika to będzie jakieś 30% twojej pracy - jeśli robisz to na jakieś zaliczenie to obawiam się ze kilka miesięcy będzie za mało na zrobienie HW i jego oprogramowanie - doradzam byś użył jak najwięcej gotowców i skupił się na software. Nawet poskładanie klocków i zebranie i uruchomienie gotowego kodu będzie moim zdaniem wyzwaniem - to ambitny projekt który wymaga szerokiej wiedzy.

    RPi oferuje ci świetną bazę wyjściowa - cena i możliwości najlepsze na rynku- nie zbudujesz systemu z uC o jakim piszesz który będzie zdolny do obróbki sygnału chyba ze zastosujesz dodatkowa logikę która odciąży twój program - przygotuj się wtedy na to ze będziesz sam musiał zdobywać wiedze - to wymaga czasu - moim zdaniem ok 2 - 3 lat.

    Oczywiście jest wiele możliwości zrobienia tego układu tak by działał jak chcesz - jak już pisałem wybrałbym RPi i jakiś grabber po USB ale alternatywnie można byłoby zrobić dekoder CVBS na RGB z filtrem dolnoprzepustowym i układem S&H i użyć wbudowanego przetwornika ADC.

  • #34 10 Sty 2017 13:56
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    Nie martw się jakimiś średnimi przy deinterpolacji - przy rozdzielczości twojego wyświetlacza (32x16) nie zobaczysz żadnej różnicy - tak naprawdę ty potrzebujesz tych średnich tak bardzo jak się da ale to powinno eis stać w RPi przy użyciu dedykowanego resizera.

    ...

    Gortu napisał:

    Do zrobienia jest SCART -> YPbPr. Niby są układy ale będę musiał wyciągać sygnał(-y?) synchronizacji z pinu Composite SCART. Lepsze to niż 64 piny.


    SCART ma sygnał CVBS - możesz użyć go bo rozdzielczość twojego wyświetlacza jest mizerna w porównaniu z parametrami najgorszego CVBS (najgorszy CVBS niesie 100x więcej danych niż możesz wyświetlić na swoim wyświetlaczu).


    Te 16x32 chciałbym aby było deterministyczne. Żeby nie potraktować tego jak worka bo celem jest tworzenie nastroju w pomieszczeniu. VHS lub klasyczny odtwarzacz DVD (sprzed np. 10 lat, mam taki z 2004 bodajże) który determinuje co się pojawi na wyświetlaczu. Klasyka, odwzorowanie, klimat. Dlatego ten graber USB tak średnio mi pasuje, bo tam jakieś Manty, Hamy, itp. firmy sobie składają nie do końca wiadomo na ile poprawnie.. Wolałbym doświadczenie np. bywalca elektroda.pl, żeby z tego doświadczenia powstał układ, a nie z dumpingowej strategii Hamy.. Nawet STM32F4 mi mniej się podoba bo ma bugi ;) Ale czytając o bugach również w ADV7280 zaczynam rozumieć że to standard niestety.. Taki RPi 3 może mieć nawet mniej bugów, takie sprawia wrażenie, tworząc 3 generację komputera a nie pionierski od podstaw STM32 chyba łatwiej uniknąć bugów, może. MCU ma lepszy klimat niż miniaturowy komputer, ale jeżeli będzie mniej bugów (raczej fałszywa teza jednak, większe -> więcej bugów), to byłby lepszy. Tylko ta cena RPi 3..

    deus.ex.machina napisał:
    RPi oferuje ci świetną bazę wyjściowa - cena i możliwości najlepsze na rynku- nie zbudujesz systemu z uC o jakim piszesz który będzie zdolny do obróbki sygnału chyba ze zastosujesz dodatkowa logikę która odciąży twój program - przygotuj się wtedy na to ze będziesz sam musiał zdobywać wiedze - to wymaga czasu - moim zdaniem ok 2 - 3 lat.


    W sumie jakoś przestałem wierzyć w triki DMA w STM32F4 teraz.. Ale że ludzie 800x600 VGA obraz z tego generują i śmiga.. To budzi zaufanie. Padi-Stamp dopiero budzi zaufanie, jak przy 83 MHz zegarze jest w stanie wygenerować 41.33 MHz sygnał VGA – jak elegancko musi chodzić DMA że dzielnik głównej częstotliwości to tylko 2: https://github.com/kissste/rtl8710_VGA_Display_Driver . I ta cena, tylko $2! Gdyby miał więcej pinów i zegar 168 MHz dla pewności, to by odbiór 27 MHz nie stanowił problemu zapewne. Ciekawe że 83 dzieli się prawie równo przez 27 (tyle MHz ma NTSC na wyjściu ADV7280), wynik to 3,07407, ale różnie może być z ułamkami.. I powinno to być raczej 4x dla pewności, dzielnik 3 chyba niespotykany.

    deus.ex.machina napisał:
    Oczywiście jest wiele możliwości zrobienia tego układu tak by działał jak chcesz - jak już pisałem wybrałbym RPi i jakiś grabber po USB ale alternatywnie można byłoby zrobić dekoder CVBS na RGB z filtrem dolnoprzepustowym i układem S&H i użyć wbudowanego przetwornika ADC.


    RPi jest spoko, ale 199zł w nettigo.. Mój budżet to 300 zł + 50 zł na transport.

  • #35 10 Sty 2017 14:47
    Piotrus_999
    Poziom 39  

    czy to będzie zero czy trzy to nie ma znaczenia, bo na razie jeszcze nie przeczytałeś z tego co widzę grama dokumentacji.. Jest soft od BM i dokumentacja - trochę trzeba tylko w sieci pogrzebać.

    Gortu napisał:
    bo ma bugi ;) Ale czytając o bugach również w ADV7280 zaczynam rozumieć że to standard niestety..
    Nie skupiaj się tym. Bardziej Cie będą bolały bugi w Twoim programie.

  • #36 10 Sty 2017 19:35
    deus.ex.machina
    Poziom 31  

    @Gortu

    Ciężko mi się czyta kolegę - zakładam ze polski nie jest językiem kolegi - może łatwiej będzie się połapać bez polskiego (ewentualnie załączać obie wersje to jakoś można będzie obejść ograniczenia automatycznej translacji).

    Video jest dość proste - problemem jest takie przemyślenie strategi przetwarzania sygnału by efektywnie przetwarzać sygnał przy pomocy ograniczonych zasobów - RPi jest o tyle dobre ze masz aż nadto zasobów by w różny sposób rozwiązać problem konwersji video na wyświetlacz.

  • #37 10 Sty 2017 20:19
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    @Gortu
    Video jest dość proste - problemem jest takie przemyślenie strategi przetwarzania sygnału by efektywnie przetwarzać sygnał przy pomocy ograniczonych zasobów - RPi jest o tyle dobre ze masz aż nadto zasobów by w różny sposób rozwiązać problem konwersji video na wyświetlacz.


    Nie jestem pewien RPi, to nie jest mała maszynka co się dobrze kręci, to Linux, włączanie i wyłączanie DMA przez rzeczy w stylu "echo > /proc/dma/enable/1", i tym podobne. Chyba zdecyduję się na STM32F4 z 0.5 MB ramu. Dla NTSC jest zegar pixel portu 27 MHz, będą na porcie dane: Cb,Y,Cr,Y,Cb,Y,Cr,Y, itd. Co dwa takty zegaru mam jeden Cx,Y na jeden pixel NTSC. Normalnie NTSC to 13 MHz ale że potrzeba dwóch wartości YUV na każdy pixel to jest to podwojenie taktowania. Więc mam 16 bitów na pixel. Ale – tryb interlaced! – tylko połowa linii. Więc liczba bajtów na kompletną ramkę: 2 * 480 / 2 * 720 = 345.6 kB. Dla PAL: 2 * 576 / 2 * 720 = 414.72 kB. Pomimo 16 bitów na piksel mam mniej niż 0.5 MB danych. Na matrycy LED będę wyświetlał tylko ramki parzyste, będzie mniejszy FPS, ale wszystko będzie spójne. Skalowanie zrobię przez pomijanie pikseli i linii, to że wejście jest interlaced po prostu załatwia za mnie pominięcie połowy linii które i tak bym pominął. Najwyraźniej będę miał wybór czy pomijać piksele na poziomie DMA czy przy sterowaniu matrycą LED, po prostu poprzez duże kroki dwóch zagnieżdżonych pętli FOR. Zajmie to mało czasu procesora, w sumie 16*32 wykonania zagnieżdżonej pętli. Teraz tylko znaleźć łatwy sposób żeby sprawdzić jak wygląda takie skalowanie przez pomijanie..

  • #38 11 Sty 2017 02:09
    deus.ex.machina
    Poziom 31  

    RPi się kreci ale nie potrzebujesz go kręcić bo używasz kompletnie innego podejścia do swojego problemu - na RPi możesz uruchomić ffmpeg czy gstreamer i korzystając z Linux skupić się na akwizycji sygnału oraz jego przeskalowaniu i utworzeniu w pamięć RAM tablicy 32x16x3 którą możesz wysłać po SPI przy pomocy DMA do twojego wyświetlacza.

    27Mhz jest tak dla PAL jak i NTSC, próbkowanie luminacji odbywa się z prędkością 13.5MHz a chrominancje próbkuje się 2x wolniej (stad jak już pisałem masz maksymalnie 720 pikseli w linii dla Y i 360 pikseli dla Cb i Cr.
    W twoim wypadku nie ma potrzeby próbkować sygnału z taka prędkością - ponieważ two wyświetlacz ma tylko 32 piksele to spokojnie możesz zmniejszyć już na wejściu ilość próbek do np 64 czy nawet 32 - spokojnie możesz podać sygnał RGB czy YCbCr przez filtr dolnoprzepustowy na wejście przetwornika AD - od biedy mógłbyś zastosować jakiś układ S&H (nawet na 4066) i próbkować te 3 sygnały przy pomocy jednego ADC.

  • #39 13 Sty 2017 16:47
    Gortu
    Poziom 5  

    Newsy – czemu nikt nie napisał że STM32 ma interfejs kamery DCMI? Piny idealnie pasują do wyjścia ADV7280. Jest też tryb "embedded synchro", bardzo ważny, bo ADV jest kompatybilny z ITU 656 i ich używa . Oprócz poczytania użyłem też CubeMX, zamierzam kupić F767 z 512 kB ramu:

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

    Także jest 8-bit embedded synchro, to czego potrzebuję – do podłączenia 8 pinów data i jeden Pixel Clock. Wspierana częstotliwość tego zegara to 54 MHz – tyle będzie na wyjściu ADV gdy włączę interlace -> progressive, dwa razy więcej linii w każdej (już nie pół-) ramce. Choć i tak użyję interlace i 27 MHz, bo chcę pomijać linie.

    512 kB starczy na pół-ramkę PAL 415 kB. Pamięc jest w różnych modułach, ale jest ciągła:

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

    Może trochę martwi to "specific AHB slave of the CPU" – tak jakbym nie mógł za jednym DMA wypełnić 415 kB bloku pamięci.

    Najważniejsze jest: znaleźć kogoś kto potwierdzi, że użył video-decoder IC, nie ważne jakiego (TI, ADI), byle ITU656, i że zadziałało to z STM32 przez DCMI. Bo martwi mnie ta wzmianka w referencyjnych docach ("codes" to ta osadzona synchronizacja, kody SAV i EAV):

    "Camera modules can have 8 such codes (in interleaved mode). For this reason, the interleaved mode is not supported by the camera interface (otherwise, every other half- frame would be discarded)."

    Ten "interleaved mode" brzmi jak interlace!, piszą o pół-ramkach. I tak chcę pomijać co drugą więc może się uda.. Ale gdyby ktoś potwierdził to od razu inaczej..

    Zastanawiam się też jak zorganizować transfery DMA, żeby móc najlepiej na bieżąco skalować do 32x16 (są instrukcje DSP – może coś ciekawego się wymyśli), ludzie piszą że spoko są przerwania half-transfer, że będę mógł zrobić double-buffer, ale nie wiem jakby to dokładnie miało być.

  • #41 13 Sty 2017 22:44
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    na RPi możesz uruchomić ffmpeg czy gstreamer i korzystając z Linux skupić się na akwizycji sygnału oraz jego przeskalowaniu i utworzeniu w pamięć RAM tablicy 32x16x3 którą możesz wysłać po SPI przy pomocy DMA do twojego wyświetlacza.


    Ale nie podłączę przez MIPI, ktoś potwierdził że trzeba by napisać własny sterownik – moduł kernela – bo ten w RPi jest pod ich moduł kamery. Choć radził mi żebym tak zrobił a nie DCMI. Jest jeszcze cena RPi – F767 w Farnell 97 zł z 512 kB RAM 216 MHz. RPi dwa razy droższe. Potwierdził też to że tylko Toshiba robi te 2 mostki MIPI.
    Dodano po 5 [godziny] 50 [minuty]:
    Znalazłem w internecie świetny projekt, dokończony, rozwijany (2013-2016), z plikami .sch / .brd i z kodem: ambilight . Jest niestety po niemiecku.

    Autorowi udało się podłączyć video dekoder Texas Instruments TVP5150AM1 PBS32 z STM32F4, z portem DCMI. Niestety wykorzystał prawdopodobnie trik dostępny w tym układzie TI: output czystego 8-Bit 4:2:2 YUV z oddzielnym sygnałem synchronizacji (a nie ITU656 z osadzonymi SAV/EAV). Ten ADV7280 którego chcę użyć tego nie potrafi. Wadą układu TI jest wspieranie tylko composite i S-Video – bez komponentu YPbPr. Jakość composite jest tragiczna, S-Video całkiem dobra, komponentu jeszcze lepsza i umożliwia łatwiejsze podłączenie SCART które ma komponent RGB, dlatego ja chcę komponent. Nie wiem co zrobię bo ten TVP5150 też ma 32 piny i jest na stronie gotowa dobrze zrobiona PCB, która wygląda dla mnie strasznie, ale może się podmęczę i przerobię na ADV.

  • #42 14 Sty 2017 01:30
    deus.ex.machina
    Poziom 31  

    Ja się poddaje... piszesz o jakości CVBS ale twój wyświetlacz będzie mógł wyświetlić w najlepszym razie 100 razy mnie informacji...
    Powodzenia.

  • #43 14 Sty 2017 01:31
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    Ja się poddaje... piszesz o jakości CVBS ale twój wyświetlacz będzie mógł wyświetlić w najlepszym razie 100 razy mnie informacji...
    Powodzenia.


    Pisałem już że chodzi o nie traktowanie tego jak ścieków bo to ma tworzyć klimat.. Podobnie jak ambilight.. Dobrze myśleć że chodzi brzytwa kontroler, algorytm, połączenie. Byś "został" hehe zaskoczę na koniec co chcę na tym wyświetlić :)

  • #44 14 Sty 2017 11:45
    Piotrus_999
    Poziom 39  

    Gortu napisał:
    Pisałem już że chodzi o nie traktowanie tego jak ścieków bo to ma tworzyć klimat.. Podobnie jak ambilight.. Dobrze myśleć że chodzi brzytwa kontroler, algorytm, połączenie.


    Brzytwa algorytm to nie użycie armaty do ustrzelenia królików na polu (oczywiście jak zaczniesz walić w polankę to ubijesz ich do diabła).

    Wystarczy jak odczytasz co 22 bajt (dma wyzwalany timerem) w co 32 linii. Sygnały synchronizacyjne masz - tak że Ci się nic nie rozjedzie.

    Masz ok 350 taktów zegara na sprawdzenie numeru linii i odpalenie dma.

    Dodano po 19 [minuty]:

    PS Możesz tez czytać całą linię po rozpoczęciu czytania kolejnej masz czas na obrobienie tej pierwszej. Tak że potrzebujesz tylko bufor na 2 linie

  • #45 14 Sty 2017 13:14
    deus.ex.machina
    Poziom 31  

    To nie kwestia ścieku ale uśredniania informacji - po prostu twój wysiwetlacz ma określone parametry i niezrozumiały jest upór dlaczego próbujesz przetwarzać kilkaset razy więcej danych niż możesz wyświetlić.
    Jak zrobić decymacje linii już napisałem - w pamięć tworzysz bufor o długości jednej linii i o większej głębokości bitowej niż rozdzielczość (np 16 bitów i 64 piksele) i dodajesz kolejne linie wstępnie zmniejszone już do 64 pikseli (np w proponowanym przez ciebie uC TI była sprzętowa funkcja przetwornika AD Average która sprzętowo uśredniała kolejne próbki - problemem było to ze ADC miał czas próbkowania 1uS wiec musiałbyś zastosować na jego wejściu filtr analogowy LP w przybliżeniu 1.5uS (czyli ok 750kHz).
    Tak uzyskane line dodajesz do siebie w buforze akumulacyjnym i co np 16 linii przesuwasz zawartość bufora o 4 bity w dol a później obcinasz dolne 8 bitów i kopiujesz do nowego bufora tym razem już obrazowego.

    Generalnie uważam ze nie przemyślałeś tego co chcesz zrobić i jak chcesz to zrobić - zasada jest przy ograniczonych zasobach zmniejszanie ilości informacji zanim jeszcze zaczniesz ja przetwarzać - gdybyś sprytnie pomyślał to wystarczyłby ci sam uC wsparty odrobina taniej analogówki (przy czym musiałbyś mieć zewnętrzny dekoder PAL CVBS który na wyjściu dalby ci sygnały komponentowe (czy RGB czy YXZ ma już mniejsze znaczenie).

    Do tego wydaje mi się ze dochodzi tu bariera językowa (może mi się wydaje ale cały czas mam wrażenie automatycznej translacji która w wypadku języka polskiego nie działa).

  • #46 14 Sty 2017 16:53
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    To nie kwestia ścieku ale uśredniania informacji - po prostu twój wysiwetlacz ma określone parametry i niezrozumiały jest upór dlaczego próbujesz przetwarzać kilkaset razy więcej danych niż możesz wyświetlić.


    Tutaj są 3 obrazki na których się opieram – composite wygląda bardzo źle, s-video zaskakująco dobrze, moim zdaniem lepiej niż komponent, ale to raczej jakaś cecha PSX:

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

    Chyba zrobię projekt etapami i zacznę od TVP5150. S-Video jest tak dobre że mogłoby to by być nawet docelowe połączenie – ale chodzi o SCART, chcę aby była możliwości podłączania magnetowidów, które prawdopodobnie mają często tylko 2x SCART – tak ma mój sprzed 12 lat. Podobnego wieku klasyczny (w tym tworzeniu atmosfery ma znaczenie że sprzęt jest klasyczny) odtwarzacz DVD (taki z divx itp.) ma wszystkie 3 połączenia.

    deus.ex.machina napisał:
    Generalnie uważam ze nie przemyślałeś tego co chcesz zrobić i jak chcesz to zrobić - zasada jest przy ograniczonych zasobach zmniejszanie ilości informacji zanim jeszcze zaczniesz ja przetwarzać - gdybyś sprytnie pomyślał to wystarczyłby ci sam uC wsparty odrobina taniej analogówki (przy czym musiałbyś mieć zewnętrzny dekoder PAL CVBS który na wyjściu dalby ci sygnały komponentowe (czy RGB czy YXZ ma już mniejsze znaczenie).


    Szukam od miesiąca i wczoraj uświadomiłem sobie że jestem dosłownie wyczerpany. Ten projekt ambilight zanalazłem cudem, 5 godzin dziennie na Google, i w końcu postanowiłem zrobić prostackie zapytanie "stm32 dcmi texas instruments", i po przejściu wielu chińskich i nic nie wartych indeksujących/kopiujących stron (będąc na skraju rezygnacji) wyłowiłem niemieckie forum.. Dobrze, że w niedzielę zamawiam STM32 i będę mógł już tylko spokojnie ćwiczyć DMA itp., np. to co napisałeś. Później zamówię PCB. Taki miałem styl pracy, po kolei przerabiałem różne uC i IC, trafiłem nawet na wspomnianą analogówkę szukając uC od Analog Devices, ale to poza moim zasięgiem.

    deus.ex.machina napisał:
    Do tego wydaje mi się ze dochodzi tu bariera językowa (może mi się wydaje ale cały czas mam wrażenie automatycznej translacji która w wypadku języka polskiego nie działa).


    Za dużo angielskiego u mnie (to dobry przykład – myśląc po polsku mówi się "Za dużo u mnie angielskiego", nie przestawiając orzeczeń itp.). Może warto nad tym popracować.

  • #47 15 Sty 2017 02:21
    deus.ex.machina
    Poziom 31  

    Gortu napisał:

    Tutaj są 3 obrazki na których się opieram – composite wygląda bardzo źle, s-video zaskakująco dobrze, moim zdaniem lepiej niż komponent, ale to raczej jakaś cecha PSX:
    Spoiler:

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



    No i ? tak będzie wyglądał obraz na twoim wyświetlaczu:
    CVBS
    ADV/7181C/LQFP - Czy 80 megahercowy kontroler ARM Cortex obsłuży dekoder video?
    i RGB
    ADV/7181C/LQFP - Czy 80 megahercowy kontroler ARM Cortex obsłuży dekoder video?

    Naprawdę uważasz ze jest tam jakaś różnica uzasadniająca niepotrzebne komplikowanie układu - poza tym video musisz przetwarzać z sygnałów komponentowych wiec CVBS i tak musi być przekonwertowany.

    Gortu napisał:

    Chyba zrobię projekt etapami i zacznę od TVP5150. S-Video jest tak dobre że mogłoby to by być nawet docelowe połączenie – ale chodzi o SCART, chcę aby była możliwości podłączania magnetowidów, które prawdopodobnie mają często tylko 2x SCART – tak ma mój sprzed 12 lat. Podobnego wieku klasyczny (w tym tworzeniu atmosfery ma znaczenie że sprzęt jest klasyczny) odtwarzacz DVD (taki z divx itp.) ma wszystkie 3 połączenia.


    Dlatego proponuje CVBS do którego musisz mieć dekoder koloru oraz przetwarzanie sygnału komponentowego.

    Gortu napisał:

    Szukam od miesiąca i wczoraj uświadomiłem sobie że jestem dosłownie wyczerpany. Ten projekt ambilight zanalazłem cudem, 5 godzin dziennie na Google, i w końcu postanowiłem zrobić prostackie zapytanie "stm32 dcmi texas instruments", i po przejściu wielu chińskich i nic nie wartych indeksujących/kopiujących stron (będąc na skraju rezygnacji) wyłowiłem niemieckie forum.. Dobrze, że w niedzielę zamawiam STM32 i będę mógł już tylko spokojnie ćwiczyć DMA itp., np. to co napisałeś. Później zamówię PCB. Taki miałem styl pracy, po kolei przerabiałem różne uC i IC, trafiłem nawet na wspomnianą analogówkę szukając uC od Analog Devices, ale to poza moim zasięgiem.


    Moim skromnym zdaniem przetwarzanie analogowe sygnału video będzie niezbędne chyba ze twój cyfrowy dekoder miałby wbudowany układ rescalujący... wtedy byłaby szansa zaprogramować go by od razu stworzy format jakiego potrzebujesz.

    Gortu napisał:

    Za dużo angielskiego u mnie (to dobry przykład – myśląc po polsku mówi się "Za dużo u mnie angielskiego", nie przestawiając orzeczeń itp.). Może warto nad tym popracować.

    Proponowałem byś pisał po angielsku bo być może będzie łatwiej zaskoczyć.

  • #48 15 Sty 2017 14:45
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    No i ? tak będzie wyglądał obraz na twoim wyświetlaczu:
    CVBS
    ADV/7181C/LQFP - Czy 80 megahercowy kontroler ARM Cortex obsłuży dekoder video?
    i RGB
    ADV/7181C/LQFP - Czy 80 megahercowy kontroler ARM Cortex obsłuży dekoder video?

    Naprawdę uważasz ze jest tam jakaś różnica uzasadniająca niepotrzebne komplikowanie układu - poza tym video musisz przetwarzać z sygnałów komponentowych wiec CVBS i tak musi być przekonwertowany.


    Jest spora różnica między tymi obrazkami, choć co ciekawe powiedziałbym że na korzyść CVBS :) Moim zdaniem to uzasadnia dążenie do lepszego podłączenia. Chyba normalnie skalowałeś, bicubic czy podobne skalowanie. Efekt bardzo motywujący w porównaniu do tego, które ktoś mi podrzucił na Stack Exchange (pierwsza zaakceptowana odpowiedź). Ciekawe czy instrukcje DSP pomogą mi lepiej przeskalować, choćby tylko w poziomie.

    deus.ex.machina napisał:
    Moim skromnym zdaniem przetwarzanie analogowe sygnału video będzie niezbędne chyba ze twój cyfrowy dekoder miałby wbudowany układ rescalujący... wtedy byłaby szansa zaprogramować go by od razu stworzy format jakiego potrzebujesz.


    Był jeden taki układ, TVP5154. Niestety wycofany z magazynu w Farnell. W proponowanych zastosowaniach pisano o "Large-Format Video Wall Displays". Jest to generalnie cacko, prawdopodobnie dobrze skaluje, co myślę wynika z tego zastosowania i z opisu tej funkcji jako "polymorphic", ale 128 pinów, więc i tak nie mógłbym go użyć.

  • #50 15 Sty 2017 18:39
    deus.ex.machina
    Poziom 31  

    Gortu napisał:

    Jest spora różnica między tymi obrazkami, choć co ciekawe powiedziałbym że na korzyść CVBS :) Moim zdaniem to uzasadnia dążenie do lepszego podłączenia. Chyba normalnie skalowałeś, bicubic czy podobne skalowanie. Efekt bardzo motywujący w porównaniu do tego, które ktoś mi podrzucił na Stack Exchange (pierwsza zaakceptowana odpowiedź). Ciekawe czy instrukcje DSP pomogą mi lepiej przeskalować, choćby tylko w poziomie.


    Spora? Jeśli jest to marginalna i wynikająca z tego ze źródła miały inny rozmiar.
    Co do algorytmu zastosowałem najprostszy bilinear bo na taki może będziesz miał szanse (zasoby uC).

    Gortu napisał:

    Był jeden taki układ, TVP5154. Niestety wycofany z magazynu w Farnell. W proponowanych zastosowaniach pisano o "Large-Format Video Wall Displays". Jest to generalnie cacko, prawdopodobnie dobrze skaluje, co myślę wynika z tego zastosowania i z opisu tej funkcji jako "polymorphic", ale 128 pinów, więc i tak nie mógłbym go użyć.


    Pewnie chodzi o filtr polifazowy który jest standardem od dłuższego czasu w tego typu torach sygnałowych.
    Wszystko powyższe jest jednak wtórne w porównaniu do tego jakie są zdolności twojego docelowego wyświetlacza.
    Jeszcze raz napisze - nie rozumiem dlaczego chcesz zainwestować w układ akwizycji a oszczędzasz na uC i jego zasobach - gdybyś kupił RPi Zero za 5$ do tego podłączył sobie po USB https://linuxtv.org/wiki/index.php/Easycap (7$) to mógłbyś sobie kombinować z różnymi algorytmami konwersji i poprawiania źródła by jak najlepiej wyglądało na twoim docelowym wyświetlaczu.

  • #51 15 Sty 2017 19:36
    Gortu
    Poziom 5  

    deus.ex.machina napisał:
    gdybyś kupił RPi Zero za 5$ do tego podłączył sobie po USB https://linuxtv.org/wiki/index.php/Easycap (7$) to mógłbyś sobie kombinować z różnymi algorytmami konwersji i poprawiania źródła by jak najlepiej wyglądało na twoim docelowym wyświetlaczu.


    RPi zero się nie nadaje, RPi 1 ma szybkość pinów tylko 22 MHz . Z STM mam możliwość nawet 54 MHz, co może okazać się potrzebne (po włączeniu interlaced -> progressive na wyjściu ADV7280 jest właśnie 54 MHz, uzupełnia brakującą połowę linii ale nie łączy przeciwnych klatek w jedną; co jest z resztą dla mnie problemem bo uzupełnia linie algorytmem interpolującym, czyli tworzy sztuczne linie). RPi wywodzi się z wysokopoziomowej zabawki, z czasem zrobili z tego sensowny "uC".

    PS. A pewnie chodziło o grabber na USB. To nie moja bajka w tym projekcie.

  • #52 15 Sty 2017 19:39
    Piotrus_999
    Poziom 39  

    Gortu napisał:
    RPi wywodzi się z wysokopoziomowej zabawki, z czasem zrobili z tego sensowny "uC".
    Robi się coraz ciekawiej. Zobaczymy kiedy (i czy w ogóle, a coraz bardziej zaczynam w to wątpić, czytając kolejne posty Kolegi) uda się tę 32x16 matryczkę uruchomić.

  • #53 15 Sty 2017 20:27
    deus.ex.machina
    Poziom 31  

    Gortu napisał:


    RPi zero się nie nadaje, RPi 1 ma szybkość pinów tylko 22 MHz . Z STM mam możliwość nawet 54 MHz, co może okazać się potrzebne (po włączeniu interlaced -> progressive na wyjściu ADV7280 jest właśnie 54 MHz, uzupełnia brakującą połowę linii ale nie łączy przeciwnych klatek w jedną; co jest z resztą dla mnie problemem bo uzupełnia linie algorytmem interpolującym, czyli tworzy sztuczne linie). RPi wywodzi się z wysokopoziomowej zabawki, z czasem zrobili z tego sensowny "uC".

    PS. A pewnie chodziło o grabber na USB. To nie moja bajka w tym projekcie.


    Jeszcze raz napisze i mam nadzieje ze się nie obrazisz - robiąc to na RPi i EASYCAP masz szanse zrobić działające urządzenie i wyświetlić na swoim ekranie wejście video a także pliki video z karty czy z sieci.
    Jeśli zaś chcesz stracić czas, pieniądze i rozczarować się nie zbliżając się nawet w ułamku do czegoś co zapala choćby pojedynczy piksel to rób to właśnie tak jak piszesz.
    Ja po prostu chciałbym żebyś odniósł sukces z jak najmniejszym ryzykiem.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME