Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Moduł kamery OV7670, uruchomienie, testy z Arduino

TechEkspert 19 Aug 2018 10:08 10218 25
Computer Controls
  • Moduł kamery OV7670, uruchomienie, testy z Arduino
    Stosując moduł kamery OV7670 możemy w naszym projekcie przetwarzać obraz o rozdzielczości 640x480. Rozdzielczość VGA może wydawać się obecnie śmiesznie mała, jednak niskim kosztem możemy wzbogacić nasz projekt o możliwość przetwarzania obrazu z kamery. Wspomniana rozdzielczość 640x480 dla np. modułu Arduino nano może okazać się zaskakująco duża w porównaniu do zasobów mikrokontrolera. Wiedza z eksperymentów z kamerą niskiej rozdzielczości może przydać się przy próbach z droższymi modułami o wyższej rozdzielczości. W przypadku nowszych modułów kamer warto zajrzeć do projektu ArduCAM.

    Próbowałem przebrnąć przez konfigurację rejestrów, jednak muszę przyznać, że to zadanie pokonało mnie czasowo. Ilość zależności między rejestrami jest spora, opisy niektórych opcji dość enigmatyczne. Praca z rejestrami to dobre pole do eksperymentów i można sporo wycisnąć z modułu kamery, jednak wymaga to czasu. Udało mi się potwierdzić działanie następujących rejestrów:
    -Zapis pod adres 0x12 wartości 0x80 resetuje wartości w rejestrach do domyślnych.
    -Rejestr 0x0C umożliwia włączenie skalowania obrazu (bit 3), natomiast zapis odpowiednich wartości do rejestru 0x12 pozwala na ustawienie rozdzielczości QCIF, CIF, VGA oraz włączenie trybu przesyłania danych o kolejnych pikselach jako RGB (np. RGB565). Kamera może wysyłać dane w formacie YUV/YCbCr (4:2:2) gdzie kolejne bajty nie są wartościami 1:1 kolejnych pikseli link (tak jak jest to np. w trybie RGB).
    -Zapis do rejestru 0x15 wartości 0x20 spowoduje generowanie sygnału PCLK tylko wtedy gdy są wysyłane dane pikseli.
    -Rejestry 0x11 i 0x6B pozwalają na ustawienie dzielników i PLL dla sygnału zegarowego.
    -Rejestr 0x1B pozwala na wprowadzanie opóźnienia w wysyłaniu danych, co czasem może przydać się przy przetwarzaniu danych

    Ponieważ pokonała mnie własnoręczna konfiguracja rejestrów, skorzystałem z gotowego kodu:
    https://github.com/indrekluuk/LiveOV7670
    który pozwala na wyświetlanie obrazu z kamery na wyświetlaczu 128x160 TFT SPI.

    Podgląd na żywo z OV7670 na TFT 128x128 ILI9163.

    Na filmie poniżej efekt działania podglądu na żywo z kamery, który pozwolił stwierdzić prawidłowe działanie modułu kamery, oraz ustawić ostrość obiektywu:


    Moduł wykorzystuje dużą ilość linii sygnałowych, gdyby dane o obrazie były przekazywane np. magistralą szeregową SPI, ilość wykorzystanych linii byłaby mniejsza, natomiast sprzętowa obsługa SPI może ułatwić pobieranie danych.

    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Uruchomienie zgodnie z opisem autora:
    -pobranie plików z github
    -skopiowanie "src/lib/LiveOV7670Library" i "src/lib/Adafruit_GFX_Library" do Arduino folder "libraries"
    -otwarcie "src/LiveOV7670/LiveOV7670.ino" w Arduino IDE i skompilowanie oraz wgranie do płytki Arduino

    Aby uniknąć stosowania konwerterów poziomów logicznych, wykorzystałem Arduino mini pro z rezonatorem 16MHz jednak zasilone napięciem 3.3V. Zgodnie z notą ATmega328 mikrokontroler przy napięciu 3.3V nie powinien być taktowany częstotliwością 16MHz (np. powinna być to wersja Arduino mini pro 3.3V 8MHz), jednak na potrzeby testu taki zestaw upraszczał połączenia i działał prawidłowo.

    Autor zastosował wyświetlacz TFT 128x160, podczas testów podłączyłem wyświetlacz TFT 128x128 ze sterownikiem IL9163.
    W wyświetlanym obrazie zamieniony był kolor czerwony z niebieskim. Do celów testowych, sprawdzenia czy moduł kamery działa, oraz ustawienia ostrości - zamienione kolory nie są problemem. Jeżeli chcecie uzyskać właściwe kolory zmieniając kolejność z RGB z BRG można np. na szybko w pliku Adafruit_ST7735_mod.cpp zmienić wartość w rejestrze MADCTL:
    Code: c
    Log in, to see the code

    na
    Code: c
    Log in, to see the code


    Według dokumentacji kamery OV7670 moduł zasilany jest napięciem 3.3V, przy podłączaniu do Arduino 5V należy zadbać o konwersję poziomów napięć. Moduł posiada wyprowadzenia SIO_C, SIO_D będące magistralą SCCB o działaniu zbliżonym do I2C, magistrala szeregowa wykorzystywaną w konfiguracji kamery. Moduł odpowiada na magistrali I2C pod adresem 0x21. Wejścia RESET (stan wysoki praca kamery) i PWDOWN (stan niski praca normalna). Wejście sygnału zegarowego XCLK, oraz wyjście PCLK do synchronicznego pobierania danych z równoległej 8bitowej magistrali D7-D0. Wyjścia HREF i VSYNC synchronizujące pobieranie danych z magistrali równoległej (odpowiednia konfiguracja umożliwia zrezygnowanie z sygnału HREF - sygnał linii, wykorzystując wyłącznie VSYNC - synchronizacja ramki).

    Podstawą uruchomienia modułu jest odpowiednia konfiguracja rejestrów magistralą SCCB. Linie interfejsu SCCB należy podciągnąć do + zasilania rezystorami 4.7-10kom. Istotne aby moduł kamery posiadał stabilne zasilanie 3.3V. Aby magistrala działała poprawnie należy podać sygnał zegarowy na wejście XCLK, wg. noty aplikacyjnej częstotliwość sygnału wejściowego powinna wynosić 10-48MHz (eksperymentalnie sprawdziłem, że przy częstotliwości wejściowej na XCLK=4MHz interfejs SCCB odpowiada prawidłowo). Testowany kod generował częstotliwość taktującą XCLK=8MHz. Częstotliwość sygnału PCLK taktującego zmiany danych na liniach D7-D0 (dane należy zczytywać na zboczu narastającym) zależy od ustawionych dzielników i PLL. W przypadku testowanego kodu, na PCLK otrzymujemy zegar o częstotliwości 2MHz.

    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Odstęp czasowy między impulsami VSYNC (odstęp między ramkami) to 100ms czyli mamy ~10FPS:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Odstęp między impulsami HREF (jedna linia) to około 800us:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Czas transmisji jednej linii z OV7670 to ~156us, transmisji towarzyszy stan wysoki na linii HREF oraz sygnał zegarowy na linii PCLK:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Między kolejnymi transmisjami linii OV7670, dane przesyłane są do wyświetlacza TFT po magistrali SPI, towarzyszy temu sygnał zegarowy na linii SCK, transmisja trwa ~484us:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Samo wyświetlanie obrazu z kamery na wyświetlaczu jest mało praktyczne, chyba że prześlemy dane cyfrowe na większą odległość transmisją przewodową lub bezprzewodową. Ciekawszym zastosowaniem byłoby zapisanie danych z modułu kamery na kartę SD uzyskując fotopułapkę lub kamerę timelaps np. do obserwacji przyrody. Rozdzielczość plików zapisanych przez taką kamerę będzie dość beznadziejna, ale za to całość byłaby dość tania i miałaby wartość eksperymentalną.

    Zapis obrazu z OV7670 na karcie SD

    Na stronie link znajdziemy pomysł na sposób zapisania danych z kamery na karcie SD. Okazuje się, że autor wybrał rozdzielczość 320x240 niższą niż maksymalna 640x480. Dodatkowo wybrał format odczytu danych z kamery YUV i zapisuje na kartę tylko dane o luminancji czego efektem będzie czarnobiały obraz. Na koniec aby uzyskać plik BMP pliki przetwarza skryptem python. Mało efektowne i wygodne, dlaczego zapis kolorowego (RGB565) pliku BMP na karcie SD sprawia problemy? Otóż zapis danych do wyświetlacza TFT był sekwencyjny i nie wymagał potwierdzeń i dodatkowych operacji, natomiast na karcie SD obsługujemy system plików. Niezbyt wydajna biblioteka Arduino obsługująca karty SD, oraz zmienne zachowanie karty SD utrudnia szybkie i sekwencyjne zapisywanie danych z kamery do pliku na karcie. Ograniczenie rozdzielczości z 640x480 do 320x240 wynika z pozostałej pamięci na zmienne po zaimportowaniu biblioteki obsługi kart SD. Jedna linia 320px mieści się w pozostałej pamięci, natomiast z 640px 16b kolor jest już problem.

    Podsumowanie
    Moduł OV7670 jest tani i pozwala na wiele eksperymentów z odczytem obrazu i jego przetwarzaniem. Spore ograniczenia modułu mogą zniechęcać mniej wytrwałe osoby. Można spróbować zbudować tanie, proste, małe urządzenia do eksperymentów z timelaps/fotopułapka do obserwacji przyrody. Aby swobodnie eksperymentować z przetwarzaniem danych z kamery można wybrać:
    -platformę, która ma wystarczającą ilość RAM aby zmieścić całą ramkę z obrazem (lub w wersji oszczędnościowej pojedynczą linię)
    -moduł kamery posiadający bufor pamięci FIFO do której zostaną zapisane dane obrazu, natomiast odczyt może zostać wykonany z dowolną szybkością
    -moduł kamery wysyłający dane obrazu magistralą szeregową (mniejsza ilość przewodów łączących)
    -moduł z dobrą dokumentacją, bibliotekami/api/przykładami do konfiguracji, aby nie walczyć z uzyskaniem pierwszej klatki obrazu z kamery
    -platformę z odpowiednio szybkimi interfejsami, oraz zasobami obliczeniowymi aby odpowiednio szybko przetwarzać dane

    Niskopoziomowe eksperymenty z próbami przechwycenia obrazu VGA 640x480 pozwalają docenić aparaty fotograficzne i kamery wbudowane w nasze smartfony, oraz samodzielne aparaty i kamery 4K :)

    Cool? Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    TechEkspert
    Editor
    Offline 
    W moich materiałach znajdziecie testy i prezentacje sprzętu elektronicznego, modułów, sprzętu pomiarowego, eksperymenty. Interesuje mnie elektronika cyfrowa, cyfrowe przetwarzanie sygnałów, transmisje cyfrowe przewodowe i bezprzewodowe, kryptografia, IT a szczególnie LAN/WAN i systemy przechowywania i przetwarzania danych.
    Has specialization in: elektronika, mikrokontrolery, rozwiązania it
    TechEkspert wrote 3790 posts with rating 3208, helped 12 times. Been with us since 2014 year.
  • Computer Controls
  • #2
    Mscichu
    Level 17  
    Swojego czasu testowałem OV7670 z ATMega8A która służyła tylko jako wysterowanie nowej ramki LCD na sterowniku SSD1963 i wystartowanie kamerki. Śmigało elegancko z rozdzielczością maksymalną 640x480 nie było żadnych przycięć ale jak sam napisałeś nie było tutaj zastosowania innego jak super tani elektroniczny wizjer do drzwi. Szukałem też jakiegoś serializera aby puścić obraz po skrętce UTP ale zaprzestałem tego projektu.

    Natomiast wróciłem do sprawy z kamerkami tylko w innej formie, którą w sumie polecam każdemu. ESP32 + OV2640 (bez żadnego bufora) i można streamować do sieci jako podgląd, chociaż przy rozdzielczości 800x600 przycina tak jak w Twoim nagraniu gdy obraz zmienia się szybko (format jpeg). Zrobiłem też zapis na serwer zewnętrzny w sieci LAN może działać jako foto-pułapka. Link do projektu z którego korzystałem: https://github.com/igrr/esp32-cam-demo

    Swoją drogą omnivision olewa typowe pytania techniczne. Zapytałem o oficjalny datasheet lub podpowiedź jak w OV2640 uruchomić funkcję STROBE (w innych modułach jest dostępny rejestr a tutaj nie znalazłem żadnych danych) i odpisali, że nie mają czasu zająć się tą sprawą...
  • #3
    TechEkspert
    Editor
    @Mscichu jeżeli miałbyś ochotę i czas to zapraszam do przedstawienia swoich osiągnięć w DIY lub Artykułach.

    Jaki zegar na PCLK użyłeś przy OV7670 + SSD1963 w trybie 640x480?

    W OV2640 widzę niepokojąco podobny interfejs sprzętowy jak w OV7670, czy w kwestii konfiguracji rejestrów też jest taka zabawa jak w OV7670?

    OV2640 posiada w sobie "kodek" jpeg?

    Widzę że są dwie wersje:
    bez dodatkowych modułów:
    https://botland.com.pl/kamery-do-arduino-i-ra...ry-arducam-ov2640-2mpx-1600x1200px-60fps.html
    https://botland.com.pl/kamery-do-arduino-i-ra...200px-60fps-z-obiektywem-hx-27227-m12x05.html
    oraz z dodatkowym układem na płytce:
    https://botland.com.pl/kamery-do-arduino-i-ra...1200px-60fps-spi-modul-kamery-do-arduino.html
    który komunikuje się szeregowo.
    Jest też wersja z ESP8266:
    https://botland.com.pl/kamery-do-arduino-i-ra...a-arducam-ov2640-2mpx-modul-wifi-esp8266.html
  • #4
    Mscichu
    Level 17  
    Co do projektu na OV7670 to stary projekt i zostały mi tylko szczątki. Ze schematu jednej z pierwszych wersji widzę, że na XCLK miałem wejście z zewnętrznego generatora i zamawiałem różne od 8 przez 16, 20 i 24MHz (jeszcze mam w szufladkach;) ) i z tego co pamiętam to działo na 24MHz. Wyjście z kamerki podałem na przerzutnik SN74HC109D który najpierw uruchamiał pierwszą bramkę SNJ54AC573W, a następnie następną (kodowanie RGB565) i przy drugim takcie zegara uruchamiał wyjście bufora oraz zapis kolejnego pixela na ekranie LCD (szyna 16bit). Dodatkowo po pełnej ramce gdy pojawiał się sygnał na VSYNC który był odczytywany z uC wysyłałem do SSD1963 położenie następnego pixela na 0.0 i tak w kółko.
    To było na początku 2014r. i mam spory bałagan, szczególnie z projektami testowymi więc nie ma co pokazywać. Jak ktoś będzie chętny i będzie chciał przejrzeć ten "worek" odnośnie OV7670 to mogę wrzucić tylko będę musiał pousuwać biblioteki od Kardasia.
    Z kolei jeżeli chodzi o projekt na OV2640 i ESP32 to jest to projekt na zlecenie i nie mogę ujawniać dokumentacji, chociaż służę pomocą.

    Jeżeli chodzi o rejestry na OV2640 to nawet do nich się nie zabierałem. Projekt na którym się wzorowałem już był poustawiany i nie wgryzałem się w same rejestry. Jedyne co zrobiłem to obracałem obrazem i tutaj jest niespodzianka bo po obróceniu obrazu o 180st zaczyna łapać zielony odcień. Nie na jednej bo testowałem już chyba z 10szt. i nie tylko u mnie bo na necie też mają problemy. OV2640 ma wbudowany kodek JPEG, dlatego wykorzystałem akurat tę kamerkę, jednak można pobrać obraz niekodowany w standardowych formatach.

    Co do wyboru OV2640 to dla mnie zależało aby jak najbardziej ograniczyć koszty przyszłej produkcji więc zamawiałem z chin same kamerki bez płytek (coś jak ten pierwszy link w którym masz również zasilanie czujnika i logiki kamery). ArduCam byłby najprostszym rozwiązaniem ale jest różnica 20pln za kamerę, a 140pln;)
    Ta wersja z ESP8266 i ta wersja po 140zł mają wbudowany procesor który najpierw łapie ramkę, a potem puszcza szeregowo i do zdjęć się będzie nadawać ale nie do filmów. Na ESP32 bez żadnych pośrednich procesorów jedną ramkę 800x600 łapię w 200-300ms. Jak ktoś chce złapać 1600x800 to trzeba zwiększyć kodowanie i obraz wygląda dość tragicznie, ale jest taka możliwość. Trzeba by dodać RAM'u do ESP32 ;)
  • #5
    TechEkspert
    Editor
    Ciekawe eksperymenty.
    Czyli do strumieniowania na ESP32 odczytywane są z OV2640 ramki "raw", a później kompresowane i wysyłane po TCP?

    Gdy OV2640 wysyła ramkę skompresowaną, to wysyła jakiś znacznik końca danych? (być może rozmiar po kompresji może być różny i zależny od treści ?).

    Czy dane jpg z OV2640 można wykorzystać do strumieniowania np. w mjpg?
  • #6
    Mscichu
    Level 17  
    Możesz odebrać jako RAW albo już skompresowane, przy czym możesz sam szybko wybrać jakość kompresji. Kamera zawsze po skończonej ramce czy to jest RAW czy JPEG zmienia sygnał na VSYNC, a samą kompresją zajmuje się już procesor wbudowany w moduł kamery. Oczywiście pliki JPEG pomimo tej samej rozdzielczości mogą mieć różne wielkości (u mnie od 30 do 60kb).
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Na ESP32 można też wykorzystać wbudowaną pamięć jako dysk twardy aby zapisać zdjęcie i odczytać w innym czasie. W standardowym ESP-WROOM32 mamy 4mb flash z czego przynajmniej połowę można zużyć na system plików (to około 50 zdjęć).
    Co do odtwarzania MJPEG to jest już nawet taka funkcja która w kółko wysyła i odświeża stronę. Próbowałem zapisać i zapisuje jako film - nieskończenie długi ;) Ogólnie tematyka ciekawa, chociaż wgryźć się aby wszystko zacząć samemu od zera byłoby ciężko.
  • #7
    TechEkspert
    Editor
    Sprytne z tym wykorzystaniem VSYNC do poinformowania o końcu skompresowanych danych jpg. Rozumiem, że w tym przypadku HREF nie niesie żadnej informacji?

    Co jest w stanie odtworzyć ten "film" w postaci zapisanej odświeżającej się strony?

    Przykład tych kamer pokazuje, że niby znikome rozdzielczości, ale aby to łatwo obsłużyć powstają bardzo złożone platformy wykorzystujące FPGA:
    https://botland.com.pl/arducam-kamery-do-ardu...-v2-dla-arduino-modul-kamery-ov2640-2mpx.html

    Znalazłem jeszcze jeden moduł wspierający kompresję:
    https://botland.com.pl/kamery-do-arduino-i-ra...x-640x480px-30fps-z-obiektywem-hq-m12x05.html
  • Computer Controls
  • #8
    Mscichu
    Level 17  
    Odtwarzałem tym co miałem na kompie, pewnie był to VLC lub dziobas. Postaram się jutro coś nagrać i sprawdzę dokładnie co i jak. Co do informacji o końcu za[isu JPEG to widzę w kodzie, że jest porównanie odebranego buforu do SIZE_MAX ale SIZE_MAX nie znalazłem nigdzie w kodzie, nawet jak używam grep. HREF przy jpeg wydaje się być nieużywane.

    Tą kamerkę też widziałem ale musiałem wszystko miniaturyzować więc u mnie wybór padł na kamerki OV :)
  • #9
    Mscichu
    Level 17  
    Trochę mi zajęło aby zebrać wszystko do kupy (a w szczególności aby wygrzebać działający program do ESP).

    Po zaprogramowaniu ESP32 w linii komend dostajemy wiadomość o poprawnym uruchomieniu kamery oraz podłączeniu do sieci, co potwierdza przydzielenie IP i podanie przez ESP32 linków do podglądu:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Po skopiowaniu adresu i wklejeniu do przeglądarki dostajemy zdjęcie oraz informacje o połączeniu i czasu odczytu ramki:
    Moduł kamery OV7670, uruchomienie, testy z ArduinoModuł kamery OV7670, uruchomienie, testy z Arduino

    Gdy skopiujemy link ze streamem to dostajemy dość dobry obraz (niestety nagrywany zewnętrznym programem bo nie pamiętam już dokładnie jak zapisywałem/odtwarzałem). Film robiony pod światło ponieważ nie mam gdzie skierować kamery. Ogólny bałagan i projekty których nie mogę pokazywać. Chcę tylko pokazać jak wygląda ruch w samej kamerze:

    Oraz prędkość generowania klatek w streamingu:
    Moduł kamery OV7670, uruchomienie, testy z Arduino

    Teraz parę ciekawostek które przychodzą mi na myśl i które przerabiałem:
    1. Można podłączyć kartę SD i szybko zapisywać zdjęcia do pamięci przy podłączeniu SDIO
    2. Zapis do wbudowanej pamięci flash zajmuje wieczność bo ok 3s.
    3. Wysłanie zapisanego zdjęcia (wewnętrzny flash) na zewnętrzny serwer zajmuje mniej niż 1s
    4. Kamera OV2640 ma wbudowany pin sterujący diodą flash, jednak nie ma żadnych opisów jak nią terować. Można natomiast odczytać z rejestru urządzenia pod adresem 0x2F natężenie światła i terować np pinem ESP32
    5. Kamera ov2640 ma 2 rejestry - Gdy do komórki 0xFF zapiszemy 1 lub 0. Rejestry są opisane w DS dość dokładnie.
  • #10
    TechEkspert
    Editor
    Bardzo ciekawy efekt przy wykorzystaniu tanich podzespołów. Przy uporządkowaniu i poszerzeniu materiału można spokojnie umieścić jako samodzielny artykuł lub projekt w DIY.
  • #11
    Mscichu
    Level 17  
    ESP32 ogólnie jest bardzo ciekawym produktem. Całkiem niedawno uruchamiałem jako MP3 dekoder. Sama biblioteka działa jako odtwarzacz internetowego radia ale można uruchomić aby odtwarzał z zewnętrznej karty SD. Link do projektu: https://github.com/MrBuddyCasino/ESP32_MP3_Decoder

    Co do pisania artykułu to faktycznie byłby ciekawy jednak ja nie mam smykałki do opisów. Każdy zawsze mi mówił, że nie potrafię opisać tego co chcę ;) Ale jak by komuś potrzeba było pomocy to chętnie pomogę.
  • #12
    TechEkspert
    Editor
    Sprawne pisanie to kwestia wprawy, z komentarzy można się bardzo dużo nauczyć, tak jak właśnie w przypadku tego materiału.

    Testowałem radio internetowe na ESP32, bez zewnętrznego DAC efekt średni, ale przy tak małych kosztach eksperyment ciekawy. Jakość dźwięku bez DAC pewnie można określić jako zbliżona do małych trzeszczących radyjek FM.

    ESP32 to ciekawy produkt i przy mniejszych seriach ESP8266 traci sens?
  • #13
    Mscichu
    Level 17  
    Według mnie ESP8266 nadaje się do prostych rzeczy przy seryjnych produkcjach ponieważ dalej jest tańszy od ESP32 więc nie ma sensu przy sterowaniu np przekaźnikiem przepłacać. Dla hobbysty lepiej zakupić ESP32 ponieważ za kilka złotych więcej mamy dużo większą wydajność, możliwości i większą ilość pinów. Dodatkowym atutem przemawiającym za używanie ESP32 przez amatorów jest wykorzystanie jednego rdzenia tylko dla wifi w arduino więc wifi nie będzie się zacinać i rwać. Tutaj chciałbym tylko dodać, że pisząc program jak np wspomniane radio internetowe można włączyć lub wyłączyć dostęp do dwóch rdzeni (dekodowanie MP3 wykorzystuje oba rdzenie, inaczej nie chce działać), tak więc mamy naprawdę mocny moduł za niewielkie pieniądze.
  • #14
    brewka87
    Level 13  
    Witam. Odświeżę temat. Kilka lat temu wykorzystałem kamerę o rozdzielczości 640x480 do bezpośredniego wysterowania wyświetlacza o tej samej rozdzielczości. Podobnie jak kolega Mscichu zbudowałem układ który przekształcał dane 8-bitowe na 16-bitowe dla wyświetlacza. do ustawienia rejestrów kamery wykorzystałem Attiny2313. Całość charakteryzowała się bardzo małą latencją, ponieważ obraz w zasadzie był wyświetlany na bieżąco bez żadnego buforowania pojedynczych ramek obrazu. Opóżnienie wynosiło jeden piksel. Kamera wysyłała obraz w standardzie RGB565, dwa bajty na jeden piksel, które były buforowane w dwóch zatrzaskach, przy następnym pikselu zawartość zatrzasków była przepisywana do wyświetlacza. Ja jednak zrobiłem mały overclocking kamery i zamiast na 24MHz puściłem ją na 48 albo 52MHz i jeszcze się wyrabiała. Miałem to wykorzystać do budowy mikroskopu cyfrowego, po zmianie optyki kamery na coś solidniejszego. Takiej szybkości kamera-->wyświetlacz nie widziałem nawet w nowych telefonach, a minęło już chyba z 6 lat od tamtego czasu. Pamiętam, że najwolniejszy z tego wszystkiego był sam wyświetlacz. Dorobiłem do tego układu konwerter z RGB TTL do LVDS i podłączyłem większy wyświetlacz, który mimo dodatkowej konwersji wyświetlał z jeszcze mniejszym smużeniem. Zbudowałem układ który nie wykorzystywał żadnego procesora do obróbki obrazu, bo chciałem sprawdzić czy tak się da ;) Efekty przerosły moje oczekiwania. Parę dni temu chciałem wrócić do tego "projektu" do budowy wizjera elektronicznego do drzwi ale chciałbym mieć możliwość przechwycenia pojedynczej ramki obrazu. ESP32 powinien się do tego nadać idealnie, a podgląd byłby "na żywo" z pominięciem ESP32.Jesli ktoś jest zainteresowany zapraszam do wymiany doświadczeń.
  • #15
    Mscichu
    Level 17  
    Na ESP32 są gotowe projekty na kamerę OV2640. Streaming przez ESP na jakiś LCD da radę ale z tego co widziałem to laguje. Już lepiej podłączyć ESP do wifi i mieć podgląd na telefonie. Wszystko znajdziesz pod hasłem ESP32 OV2640
  • #16
    brewka87
    Level 13  
    Mscichu wrote:
    Na ESP32 są gotowe projekty na kamerę OV2640. Streaming przez ESP na jakiś LCD da radę ale z tego co widziałem to laguje. Już lepiej podłączyć ESP do wifi i mieć podgląd na telefonie. Wszystko znajdziesz pod hasłem ESP32 OV2640

    Tak, zgadza się. Interesowałem się tymi modułami. Chodzi o to, ze jak sam zauważyłes bardzo to laguje, a przy tym co osiągnąłem kilka lat temu (podobne rozwiązanie do Twojego) to jest tragedia. Wysterowując wyświetlacz bezpośrednio (no prawie) z kamery uzyskałem idealnie płynny obraz z praktycznie niezauważalnym opóźnieniem, czego nie mozna powiedziec o modułach ESP32-CAM. Brakowało mi jedynie możliwości przechwycenia pojedynczej ramki obrazu aby zrobić zdjęcie. Pomyślałem aby ESP32 podłączyć równolegle do mojego układu. Te tanie moduły opierają się chyba na kompresji JPEG , a ja potrzebuje zrobić to tak aby kamera wysyłała RGB565, wtedy podgląd szedłby poprzez moj układ, a ESP byłby tylko do zapisywania zdjęć. Poza tym lubię kombinować :) Zrobiliśmy chyba podobne układy, idea taka sama, tylko ciut inne rozwiązanie układowe. Chciałbym do tego wrócić, bo mam tych kamer chyba ze 20 jak nie więcej.

    Aktualizacja:
    Osobie chętnej pomóc w temacie jestem gotowy podarować komplet: kamera POA030 + złącze Kyocera + wyświetlacz UMSH-8377 + taśma + złącze zif 40.
  • #17
    Mscichu
    Level 17  
    Na chwilę obecną nie pomogę przy pracy ale mogę podpowiedzieć. Kamera OV2640 ma możliwość być wysterowana jak OV7670, czyli z wyjściem RGB565. Procesor, np ESP może tylko nasłuchiwać na linii i w razie potrzeby przełączyć kamerę na zapis JPEG, zrobić szybki zapis i ponownie zmienić na przesył RGB565. Można wtedy robić np. zdjęcia większej rozdzielczości.



    Ja z kolei mam inny dylemat. Chcialbym przesłać taki sygnał wideo na większą odległość i pomyślałem o użyciu układów Serdes ale nigdy z takimi nie miałem do czynienia. Orientuje się może czy takim układem jak PTN3700 z wyjściem LVDS mogę przesłać sygnał skrętką UTP CAT5 na odległość 20-30m? Według wyliczeń potrzeba ok 150mbit/s dla RGB565 rozdzielczości 640x480 i 30kl/s.
  • #18
    brewka87
    Level 13  
    Dzięki za podpowiedź ale chciałbym użyc do tego projektu kamery z układem Pixelplus POA030R, bo tych posiadam kilkadziesiąt sztuk. Mam tez starszą wersję PPV401C z układem PO6030K w ilosci kilkunastu sztuk. Jest na czym eksperymentowac a i rozebrać kamerę, zeby dołozyc lepszą optykę mając takie ilości mi nie szkoda - podczas eksperymentów uszkodziłem kilka egzemplarzy, bo tasiemki delikatne a zawsze jest pokusa aby coś poprawić. Dysponuję także kilkudziesięcioma wyswietlaczami UMSH8377 dlatego zależy mi aby to wykorzystać.
    Nie znam układu o ktorym piszesz, ale także chciałem przesyłać obraz z tej kamery na dalsze odległości i podobnie jak Ty szukałem układu SERDES i chyba Texas miał coś w ofercie, co mogłoby działac ale nie wiem czy na takie odległości. Na kilkunastu centymetrach ładnie działał transmiter LVDS DS90C383 ale on potrzebował z tego co pamiętam 4 par danych plus jedna para zegar, a mi zalezało takze na skrętce, bo tania i łatwo dostępna. Moze jakby wykorzystać kabel HDMI (pary różnicowe) poszłoby na więcej? Mam jeszcze gdzieś stare płytki (pająki prototypowe) i chyba sam potestuję. Transmiter potrzebował na wejściu sygnału RGB888 ( 8 bitów na kolor), sygnału zegara PLCK oraz synchronizacji pionowej i poziomej, ale ja wysterowałem go sygnałem RGB565 zostawiając najmłodsze bity niepodłączone (albo sciągnięte do masy, nie pamiętam dokładnie). Mogłem użyć wersji 18-bitowej DS90C363 ale akurat nie miałem go pod ręką. Zmontowałem takze odbiornik na DS90C384 i wszystko działało na biurku. Niewątpliwą zaletą tych układów jest wygodniejsza w aplikacji obudowa w porównaniu do BGA (płytki trawiłem osobiście). Za kilka dni będe na działce, przywiozę wszystko do domu i eksperymenty ruszą na nowo ;)

    A jednak z układem DS90C383/384 tez nie przejdzie, bo w kablu HDMI są tylko 4 pary różnicowe (pewnie nawet o tym pomyślałem kilka lat temu i zrezygnowałem, a teraz skleroza), ale wspomniany 18-bitowy DS90C363/364 potrzebuje jedynie 3 pary danych + zegar, czyli 8 przewodów...
  • #19
    DJ.TRoX
    Level 17  
    Od kilku godzin mam wątpliwą przyjemność z modułem OV7670 i kompletnie się poddaję. Sytuacja wygląda tak, że poganiam moduł zegarem 16MHz. Ustawiłem I2CWrite( 0x42, 0x11, 0x1F) czyli prescaler=32 oraz I2CWrite( 0x42, 0x3E, 0b10010) czyli dodatkowy dzielnik zegara=4. Moje PixelCLK=62.5kHz działa i jest super. Chciałbym zmusić to do pracy z maksymalną rozdzielczością czyli 640x40. Zgodnie z dokumentacją można zrobić 15 klatek w tej rozdzielczości kiedy jesteśmy w trybie YUV. Z moim zegarem mając 2Byte/pixel powinienem mieć 1 klatkę na 10s. Co bym nie robił Vs przychodzi co 3.2s czyli w trybie znacznie mniejszej rozdzielczości. Jedyny rejestr, który mówi o rozdzielczości to 0x12(COM7) i logika podpowiada, że powinien być ustawiony 0 dla YUV lub 0b100 dla RGB. Jakieś pomysły?
  • #20
    TechEkspert
    Editor
    Również pokonało mnie konfigurowanie rejestrów w OV7670 i wykorzystałem https://github.com/indrekluuk/LiveOV7670

    COM7 0x12 domyślnie 0x00
    http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html
    Bit[7]:
    0: Nothing
    1: Reset all the registers to default values

    Bit[5]:
    0: Nothing
    1: Use CIF format

    Bit[4]:
    0: Nothing
    1: Use QVGA format

    Bit[3]:
    0: Nothing
    1: Use QCIF format

    Bit[1]:
    0: Disable color bar
    1: Enable color bar

    Bit[2, 0]:
    00: YUV
    01: RGB
    10: Bayer raw
    11: Processed bayer raw
  • #22
    DJ.TRoX
    Level 17  
    Jednak nie ogarniam tej kamery. Jest tak, że podniosłem XCLK do 8MHz co u wszystkich działa - u mnie też. Chcę mieć obrazki 640x480, ustawiłem prescaler na 32 więc jedna klatka do kilka ładnych sekund. Przykładowe konfiguracje z VGA są dla trybów YUV oraz RAW Bayr RGB. Oba odpadają bo nie mam w procesorze tyle pamięci i koniecznie muszę skorzystać z RGB555 lub RGB565. Moja konfiguracja wygląda tak:

    Code:

    I2CWrite( 0x42, 0x11, 0x1F);   Wait_ms(100);   // CLKRC 1F --> presc=32
    I2CWrite( 0x42, 0x12, 0b100);   Wait_ms(100);   // rgb mode

    I2CWrite( 0x42, 0x0C, 0x00);   Wait_ms(100);
    I2CWrite( 0x42, 0x3E, 0x00);   Wait_ms(100);
    I2CWrite( 0x42, 0x70, 0x3A);   Wait_ms(100);
    I2CWrite( 0x42, 0x71, 0x35);   Wait_ms(100);
    I2CWrite( 0x42, 0x72, 0x11);   Wait_ms(100);
    I2CWrite( 0x42, 0x73, 0xF0);   Wait_ms(100);
    I2CWrite( 0x42, 0xA2, 0x02);   Wait_ms(100);

    I2CWrite( 0x42, 0x40, 1<<4);   Wait_ms(100);   // com15 RGB565
    //I2CWrite( 0x42, 0x40, 0b11<<4);   Wait_ms(100);   // com15 RGB555

    I2CWrite( 0x42, 0x1E, 1<<4);   Wait_ms(100);   // mirror
    I2CWrite( 0x42, 0x15, 0x20);   Wait_ms(100);   // plck only with active pixels


    Sytuacja wygląda tak, że niby działa ale obraz jest czarno-biały. Wartości składowych niby się różnią ale bardzo nieznacznie. Obraz jest czytelny w bardzo wąskim przedziale oświetlenia zupełnie jak by AWB nie działał.
  • #23
    TechEkspert
    Editor
    Było to dość dawno i pamiętam pewien problem który nie zbadałem do końca, być może też na niego natrafiłeś,
    zbyt niska wartość xclk (preskaler chyba nie miał na to wpływu) utrudniała pracę I2C,
    może warto odczytać zapisane rejestry i sprawdzić czy zapisy odbywają się poprawnie?

    Kolejność konfiguracji rejestrów też zdawała się mieć znaczenie, jednak tak jak piszę było to dawno i mogę się mylić.
  • #24
    DJ.TRoX
    Level 17  
    Dzięki za zainteresowanie tematem. Z zegarem zjeżdżałem do 40kHz, w ramach testu, przebiegi wyglądały normalnie ale ich zawartość już nie. 8MHz to raptem 20% poniżej katalogowego minimum. Zamówiłem tych kamer kilka i wszystkie zachowują się identycznie. Obawiam się, że uruchomiłem tryb którego nikt nie testował. Oczywiście z czasem dojdę do jakiejś konkluzji, bardziej martwi mnie to, że ten czas zostanie zakwalifikowany do nauki i doskonalenia własnego a nie realizacji projektu. Życie...
  • #25
    Mscichu
    Level 17  
    Może trafiłeś tak jak ja kiedyś nie na OV7670, a 7671?
  • #26
    DJ.TRoX
    Level 17  
    Na module napisano 7670. Mam dwie sztuki i o ile zachowują się trochę inaczej od siebie to obie zwracają kolor zbliżony do cmentarnych czarno-białych fotografii. Średnia z kolorów jako 8bit b&w wygląda znośnie i muszę na tym poprzestać bo tryb YUV jest jedynie z kodowaniem na 4 bajtach a zwyczajnie nie mam na to miejsca w ramie a na przeliczanie z RGB nie mam mocy obliczeniowej. Ciekawi mnie czy w trybie YUV kolor byłby poprawny i na pewno to sprawdzę jak złapię chwilę czasu.