Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[STM32F4] - Układ DMA: DCMI -> SRAM

rezontor 04 Sty 2015 14:06 5718 60
  • #31
    rezontor
    Poziom 15  
    A.T. napisał:
    A i którą wersję ustawienia bloku PLL masz odkomentowaną?


    mam to ustawione:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    przy czym

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Dodano po 4 [minuty]:

    kemot55 napisał:
    Procedura p. Szymaniaka nie konwertuje obrazu z 565 (16bit) do 888 (24bit).


    myślałem, że taka konwersja zachodzi zgodnie z opisem biblioteki:

    "Prezentowane procedury zapisują kolor każdego piksela (a jednocześnie jego jasność) przy pomocy 3 bajtów. Każdy z bajtów określa intensywność jednej z podstawowych składowych koloru: BGR. Pierwszy bajt określa intensywność składowej niebieskiej (B), drugi składowej zielonej (G) a trzeci składowej czerwonej (R).. (...) Konwersja wykonywana jest w dwóch pętlach 'i' i 'j'. Dane każdej linii do konwersji pobierane są od ostatniej do pierwszej. Po przekształceniu z RGB565 na BGR888 dane pikseli zapisywane są do bufora wyjściowego. Jeśli bufor wyjściowy okaże się za mały na konwertowany plik .BMP, główna procedura zwróci 0, każda inna wartość będzie oznaczać sukces konwersji." http://www.stm32.eu/node/346
  • PCBway
  • Pomocny post
    #32
    kemot55
    Poziom 30  
    OK. Przejrzałem dokładniej i jednak jest tam konwersja. Dziwnie napisany jest ten kod, ale pewnie działa.
    A możesz załączyć to co jest w buforze po zrobieniu zdjęcia bez konwersji na BMP? Najlepiej zrób kamerą zdjęcie czarno-białych kilku pasków. Dobrze by było żebyś załączył też oryginał (zdjęcie np. z telefonu tej samej "paskowej" sceny)
  • PCBway
  • #33
    rezontor
    Poziom 15  
    kemot55 napisał:
    A możesz załączyć to co jest w buforze po zrobieniu zdjęcia bez konwersji na BMP? Najlepiej zrób kamerą zdjęcie czarno-białych kilku pasków. Dobrze by było żebyś załączył też oryginał (zdjęcie np. z telefonu tej samej "paskowej" sceny)


    W załączniku wysyłam:

    --
    * dane z terminala: bajty obrazka poddanego konwersji (z_enkoderem.log)
    * gotowy obrazek poddany konwersji, który powstał na podstawie powyższych danych z terminala - przy pomocy podanego wcześniej programu javy (z_enkoderem.bmp)
    --

    * dane z terminala: bajty obrazka niepoddanego konwersji (bez_enkodera.log)
    * gotowy obrazek niepoddany konwersji, który powstał na podstawie powyższych danych z terminala (bez_enkodera.bmp)
    --

    * obrazek testowy pasów, wykonany telefonem (paski.jpg)
  • #34
    Dydelmax
    Poziom 36  
    Jak na moje oko, to coś za dużo zer jest w tych logach. W plikach *.bmp pod hexedytorem wygląda to tak, jakby w całym obrazku było tylko kilka kolorów pikseli lub tylko kilka poziomów ich nasycenia (w pliku z_enkoderem.bmp - wartości HEX 00, 20 i 40, bez_enkodera.bmp - HEX 00, 20, 40, 01, 02, 08, 21, 41, 80, 60). Znów końcówka pliku (bez_enkodera.bmp) jest ucięta - po jej doklejeniu plik otwiera się normalnie w innych programach. Dodatkowo przekleiłem nagłówek z pliku z_enkoderem.bmp. Do końcówki pliku bez_enkodera.bmp dokleiłem tym razem ciąg HEX: 01 02 03 ... FF pooddzielany losowo rozmieszczonymi ciągami 00 00 00 00 00 ... 00. Plik w załączniku.

    EDIT: Odnośnie plików z postu poniżej:
    - maksymalnie 16 kolorów (jasno.bmp),
    - niemal całkowity brak zielonej składowej, za wyjątkiem kilku pikseli niemal na samym dole, około 10 pikseli od środka obrazu (jasno.bmp),
    - tylko 4 kolory (ciemno.bmp); czarny #000000, czerwony #200000, zielony #002000, niebieski #000040.
  • #35
    rezontor
    Poziom 15  
    A.T. napisał:
    Jeśli potrafisz to zmierz zegar xclk. Jeśli nie, to zamień go na jakiś zdecydowanie niższy do 20MHz, a PLL w kamerze ustaw tak, aby zegar pclk nie przekraczał 30MHz. Najlepiej, żeby był z zewnętrznego generatora.


    Nie mam oscyloskopu, mogącego mierzyć tak wysokie f.

    Zmniejszyłem częstotliwość XCLK na 36MHz:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    a najnowsze ustawienia PPL kamery wyglądają tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod



    W załączniku wysyłam efekt robienia zdjęć (z enkoderem) ciemnej rzeczy i pod światło. Dalej jest to samo, z minimalną różnicą..
  • #36
    rezontor
    Poziom 15  
    Może źle konfiguruję układy DCMI / DMA? Lub nieprawidłowo wysyłam instrukcje konfigurujące kamerę przez I2C? Bo nie mam pojęcia, w czym może być problem - na wszelki wypadek wylutowałem z płytki STM32F429 DISCOVERY wyświetlacz i inne rzeczy, które mogą obciążać linie. Sprawdziłem połączenia i zaekranowałem przewody. Niestety, ale nic to nie dało...
  • #37
    kemot55
    Poziom 30  
    Bardzo dużo zer. Tak jakby odczyt był szybszy niż dostarczanie danych.
    A w jaki sposób masz połączoną kamerę z procesorem? Czy to przypadkiem nie wisi na długich "drutach"? Bo jeżeli tak to może masz oscylacje na linii zegara. Na wszelki wypadek zapnij na linii zegara kilka pF do masy. Na marginesie: mniej więcej 10cm przewodu wprowadza 10ns czasu opóźnienia.
  • #38
    rezontor
    Poziom 15  
    kemot55 napisał:
    A w jaki sposób masz połączoną kamerę z procesorem? Czy to przypadkiem nie wisi na długich "drutach"?


    Przewody mam takie, jak tu, na zdjęciu: http://www.stm32.eu/node/307

    kemot55 napisał:
    Bo jeżeli tak to może masz oscylacje na linii zegara. Na wszelki wypadek zapnij na linii zegara kilka pF do masy.


    Dołączyłem już wcześniej 10pF do masy, jednak nic to nie pomogło...
  • Pomocny post
    #39
    TvWidget
    Poziom 33  
    1. W jakim formacie oczekujesz danych ? Jeśli ma być to YUV to przy zasłoniętym obiektywie powinieneś otrzymać ciąg wartości zbliżonych do 0x00, 0x80, 0x00, 0x80, 0x00 ....
    2. Czy sygnały HS i VS mają odpowiednią polaryzację i częstotliwość ?
    3. Jaką częstotliwość w rzeczywistości ma sygnał PCLK i jaki zegar masz ustawiony dla DCMI ?
    4. Czy ilość fizycznie wczytanych danych dla pojedynczej ramki zgadza się z teoretyczną ilością wynikającą z rozdzielczości ustawionej w przetworniku ?
  • #40
    rezontor
    Poziom 15  
    TvWidget napisał:
    1. W jakim formacie oczekujesz danych ? Jeśli ma być to YUV to przy zasłoniętym obiektywie powinieneś otrzymać ciąg wartości zbliżonych do 0x00, 0x80, 0x00, 0x80, 0x00 ....


    Przy zasłoniętym obiektywie otrzymuje obrazy, podobne do poprzednich... czyli porozrzucane bez ładu piksele

    TvWidget napisał:
    Jaką częstotliwość w rzeczywistości ma sygnał PCLK


    Gdy jutro będę miał dostęp do właściwego oscyloskopu / częstotliwościomierza - sprawdzę.
    TvWidget napisał:
    . Czy ilość fizycznie wczytanych danych dla pojedynczej ramki zgadza się z teoretyczną ilością wynikającą z rozdzielczości ustawionej w przetworniku ?


    Według obliczeń, mikrokontroler powinien pobrać: szerokość_obrazu*wysokość_obrazu*liczba_bajtów_na_piksel = 176*144*2=50688 bajtów. Ponieważ DMA pobiera paczki 4 - bajtowe:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    to parametr określający liczbę danych do pobrania:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    ustawiłem na 12672.

    TvWidget napisał:
    2. Czy sygnały HS i VS mają odpowiednią polaryzację i częstotliwość ?
    TvWidget napisał:
    jaki zegar masz ustawiony dla DCMI ?


    W załączniku zamieszczam cały program, komunikujący STM32F429 z kamerą. Działanie programu sprowadza się do wykonania zdjęcia, jego konwersji i wysłania go przez USART. Może nie dostrzegam już pewnych pomyłek, które mogą być banalne... Bardzo prosiłbym o ocenę.
  • Pomocny post
    #41
    TvWidget
    Poziom 33  
    rezontor napisał:
    Przy zasłoniętym obiektywie otrzymuje obrazy, podobne do poprzednich... czyli porozrzucane bez ładu piksele

    Nie pytałem się jakie obrazy otrzymujesz tylko jaki format danych ustawiłeś w przetworniku.

    rezontor napisał:
    Według obliczeń, mikrokontroler powinien pobrać ...
    .
    Nie pytałem się ile danych chcesz pobrać tylko ile danych uP fizycznie wczytuje w czasie jednej ramki do pamięci.
  • #42
    rezontor
    Poziom 15  
    TvWidget napisał:
    Nie pytałem się jakie obrazy otrzymujesz tylko jaki format danych ustawiłeś w przetworniku.


    W bibliotece, z której korzystam, są takie domyślne ustawienia:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    czyli:
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • #43
    TvWidget
    Poziom 33  
    Dla DCMI można ustawić zapis tylko jednej ramki. Włącz to i zobacz ile danych fizycznie odbiera uP.
    Jeśli na tym etapie coś się myli to nie ma sensu rozważać jakie dane się wczytują.
  • #44
    rezontor
    Poziom 15  
    TvWidget napisał:
    Dla DCMI można ustawić zapis tylko jednej ramki. Włącz to i zobacz ile danych fizycznie odbiera uP.


    Ta opcja jest u mnie włączona w konfiguracji:
    Kod: c
    Zaloguj się, aby zobaczyć kod



    TvWidget napisał:
    zobacz ile danych fizycznie odbiera uP.


    W jaki sposób mógłbym to sprawdzić?
  • #45
    TvWidget
    Poziom 33  
    Masz ustawione już "DCMI_CaptureMode_SnapShot" i DCMI_SynchroMode_Hardware
    Proces wczytywania zatrzyma się więc automatycznie po zakończeniu ramki.
    Zwiększ testowo ilość danych dla DMA. Złap obrazek i odczytaj wskaźnik zapisu.
    Możesz też zapisać pamięć np. wartościami 0x55 i zobaczyć jaką ich część zmienił uP.
  • #46
    rezontor
    Poziom 15  
    TvWidget napisał:
    Masz ustawione już "DCMI_CaptureMode_SnapShot" i DCMI_SynchroMode_Hardware
    Proces wczytywania zatrzyma się więc automatycznie po zakończeniu ramki.
    Zwiększ testowo ilość danych dla DMA. Złap obrazek i odczytaj wskaźnik zapisu.
    Możesz też zapisać pamięć np. wartościami 0x55 i zobaczyć jaką ich część zmienił uP.




    Zmieniłem rozmiar bufora- dodałem dodatkowych 500 bajtów:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    ZMieniłem rozmiar przesyłania DMA:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Oznacza to, że DMA ma przesłać dodatkowo 500*4 bajtów (powinno wystąpić przepełnienie i nadpisanie innych obszarów pamięci, jeżeli rzeczywiście było ich tyle)

    W pętli głównej uzupełniam tablice odbiorczą - bufor odbiorczy - jedynkami:

    Kod: c
    Zaloguj się, aby zobaczyć kod



    Następnie wywołuję funkcję uruchamiającą kamerę i robiącą zdjęcie. Później drukuję zawartość wszystkich komórek z tablicy bufora odbiorczego:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    W terminalu otrzymuję dane z kamery. W pewnym momencie otrzymuję już same jedynki - oznacza to, że te bajty nie były modyfikowane przez DMA. Gdy policzyłem, ile tych jedynek w rzeczywistości jest - wyszło 500. Czyli okazuje się, że do tej tablicy trafia o 500 bajtów mniej danych - czyli tyle, ile trzeba... Log pokazujący całą sytuację jest w załączniku (jest to zawartość bufora odbiorczego bufor_RAM_danych_obrazka, z którego dane powinny później zostać przekonwertowane w enkoderze BMP..
  • Pomocny post
    #47
    atom1477
    Poziom 43  
    A ja już chyba wiem co jest nie tak. Prawie mi się udało rozkodować obrazek.

    EDIT. Jednak nie tak prosto jest. Kolorów mi się nie udało zdekodować.
    Nie mniej jednak jestem na 99% pewny o co tutaj chodzi.
    Te pierwsze obrazki (8bitowe, co miały po 76kB), po "małej" (4 godziny konwertowania :D) zabawie z danymi wskazują że to jest format YCbCr.
    Wprawdzie ustawiasz format RGB, ale nie bardzo rozumiem co to ustawienie daje (ustawiasz to w jakiejś funkcji, a to trzeba wysłać do kamery po I2C).
    I miałem ustawione YCrCb (uruchamiałem kamerę nie mając do niej datasheeta) i dopiero po zrobieniu zdjęć kilku plansz testowych załapałem o co chodzi.
    Dlatego chciałem żebyś Ty też wykonał takie zdjęcia.
    Twoja kamera zwraca po 4B na dwa pixele.
    Ale błędnie założyliśmy że to jest format RGB565 (1 pixel: 2B).
    W YCbCr też mamy 4B na dwa pixele, ale inaczej zapisane:
    Dwa razy Y (w uproszczeniu: jasność).
    I Cb i Cr: wspólne dla obu pixeli (składowe różnicowe kolorów, oko ma mniejszą rozdzielczość dla kolorów więc taka kompresja nie powoduje utraty jakości).
    Zapisane jest to tak:
    Cb Y Cr Y
    Potem była ta konwersja na 8 bitów (dlatego obrazek zajmował 76kB zamiast 50kB). Oczywiście konwersja błędna bo YCbCb tak nie można konwertować.
    Ale na szczęście podczas tej konwersji konwerter jedynie dopełniał zerami więc się to dało odwrócić.
    Po odwróceniu tej błędnej konwersji uzyskałem wartości wyglądające na poprawne bo widać że występują przeplatające się ze sobą wartości Y i Cb/Cr.
    Ładnie to widać bo Cb/Cr oscyluje wokoło 128, i po tym właśnie łatwo rozpoznać ten format:
    [STM32F4] - Układ DMA: DCMI -> SRAM
    Widać w kolumnach, na przemian wartości średnie i małe.
    Średnie to CrCb, małe Y.
    Obrazek Obraz4 miał być ciemny, no i jest (wartości Y są małe).
    CrCb oscyluje wokoło 128, co też jest typowe dla ciemnych obrazków (w ciemnych obrazkach głębia kolorów jest mała).
    Jednak nie udało mi się tego jeszcze poprawnie zdekodować aby to wyświetlić i wrzucić na forum. Jest kilka wersji formatu różniących się współczynnikami i pewnie stąd problem.
    Najprościej po prostu w kamerze przestawić format na RGB.
    Jak się nie da, to jest jeszcze szansa na prostą konwersję bo układ DCMI w procku ma zdaje się sprzętowy konwerter YCrCy-->RGB.
    Ale trzeba go oczywiście włączyć. Teraz coś nie mogę tego znaleźć. Może to w innym procku było.
    Żeby się upewnić że problem właśnie w formacie to możesz zrobić jeszcze kilka zdjęć.
    Jednolitego tła w kolorach, R, G i B. Przy dobrym świetle.
    I najlepiej odczytaj bufor prosto z RAMu (bez wykorzystania tej biblioteki co to zapisuje jako BMP).
  • #48
    A.T.
    Poziom 20  
    Ja bym się głównie przyglądnął zegarowi xclk. Powtórzę, ale jeśli masz to podaj go z innego źródła niż ten z procesora. Mnie się go nie udało wykorzystać i objawy miałem całkiem podobne. Na drugim miejscu przeglądnąłbym sygnały sterujące DCMI, czyli HSYNC, VSYNC - czy czasem tam coś dodatkowo nie wisi na tych pinach procesora i nie wymusza jakiegoś stanu. Pewnie korzystasz z stm32f429 Disco. Pamiętam, że tam trzeba było chyba wylutować lcd, aby wykorzystać DCMI, a może coś jeszcze...

    Dodano po 2 [minuty]:

    Aha no i tak jak ktoś wcześniej wspominał sprawdź ile danych odebrało DMA. Odczytaj rejestr NTDR. To powinno wykluczyć sygnały sterujące DCMI.

    Dodano po 4 [minuty]:

    Nie zmieniłeś ustawienia swap odd nad even bytes. Tak jak masz teraz to będziesz miał pomieszane kolory, musisz wyłączyć tę opcję. Nie jest to oczywiście główny problem bo jakieś kontury powinieneś widzieć. A powiedz jeszcze czy jak zasłonisz całkowicie obiektyw to obraz robi się czarny i co jak zwrócisz kamerę do jasnego światła?
  • #49
    TvWidget
    Poziom 33  
    Jeśli ilość przesłanych bajtów się zgada to z sygnałami PCLK, HS i VS raczej wszytko jest OK.
    Możesz mieć jedynie odwróconą polaryzację PCLK.
    Obejrzyj surowe dane jakie przesyła kamera i sprawdź czy wszystkie bity się zmieniają.
    Nie jest wykluczone, że popełniłeś jakiś błąd w podłączeniu szyny danych lub konfiguracji pinów.
  • #50
    rezontor
    Poziom 15  
    atom1477 napisał:
    A ja już chyba wiem co jest nie tak. Prawie mi się udało rozkodować obrazek.

    EDIT. Jednak nie tak prosto jest. Kolorów mi się nie udało zdekodować.
    Nie mniej jednak jestem na 99% pewny o co tutaj chodzi.
    Te pierwsze obrazki (8bitowe, co miały po 76kB), po "małej" (4 godziny konwertowania :D) zabawie z danymi wskazują że to jest format YCbCr.


    Bardzo dziękuję za fatygę :)

    atom1477 napisał:
    Wprawdzie ustawiasz format RGB, ale nie bardzo rozumiem co to ustawienie daje (ustawiasz to w jakiejś funkcji, a to trzeba wysłać do kamery po I2C).



    Wpisuję te wartości do struktury, która jest przekazywana do funkcji


    Kod: c
    Zaloguj się, aby zobaczyć kod


    która zapisuje dane, wywołując MT9D111_WriteReg.

    atom1477 napisał:
    Dlatego chciałem żebyś Ty też wykonał takie zdjęcia.


    Postaram się takie zdjęcia wykonać.
    A.T. napisał:
    Ja bym się głównie przyglądnął zegarowi xclk.


    Podłączyłem wyprowadzenie oscyloskopu. Sygnał ma prawidłową częstotliwość, jednak jest problem z jego kształtem (sinusoida) oraz amplitudą (0 - 1V). Wynika to pewnie z tego, że sonda oscyloskopu ma jakąś pojemność i działa jako filtr dolnoprzepustowy


    A.T. napisał:
    Powtórzę, ale jeśli masz to podaj go z innego źródła niż ten z procesora.


    Niestety, ale nie dysponuję tak wysoką częstotliwością... przynajmniej w obecnym czasie.

    A.T. napisał:
    Na drugim miejscu przeglądnąłbym sygnały sterujące DCMI, czyli HSYNC, VSYNC - czy czasem tam coś dodatkowo nie wisi na tych pinach procesora i nie wymusza jakiegoś stanu. Pewnie korzystasz z stm32f429 Disco. Pamiętam, że tam trzeba było chyba wylutować lcd, aby wykorzystać DCMI, a może coś jeszcze...


    Prawda - korzystam z tego zestawu. Wylutowałem wyświetlacz LCD, R60 i C35 - elementy, które obciążały linie. jednak nic to nie zmieniło.
    '
    A.T. napisał:
    Aha no i tak jak ktoś wcześniej wspominał sprawdź ile danych odebrało DMA. Odczytaj rejestr NTDR. To powinno wykluczyć sygnały sterujące DCMI.


    Liczba danych odebranych jest prawidłowa:

    rezontor napisał:
    TvWidget napisał:
    Masz ustawione już "DCMI_CaptureMode_SnapShot" i DCMI_SynchroMode_Hardware
    Proces wczytywania zatrzyma się więc automatycznie po zakończeniu ramki.
    Zwiększ testowo ilość danych dla DMA. Złap obrazek i odczytaj wskaźnik zapisu.
    Możesz też zapisać pamięć np. wartościami 0x55 i zobaczyć jaką ich część zmienił uP.




    Zmieniłem rozmiar bufora- dodałem dodatkowych 500 bajtów:

    Kod C - [rozwiń]
    uint8_t bufor_RAM_danych_obrazka[SZEROKOSC_OBRAZKA*WYSOKOSC_OBRAZKA*BAJTOW_NA_PIKSEL+500];



    ZMieniłem rozmiar przesyłania DMA:

    Kod C - [rozwiń]

    DMA_InitStructure.DMA_BufferSize = 12672+500;



    Oznacza to, że DMA ma przesłać dodatkowo 500*4 bajtów (powinno wystąpić przepełnienie i nadpisanie innych obszarów pamięci, jeżeli rzeczywiście było ich tyle)

    W pętli głównej uzupełniam tablice odbiorczą - bufor odbiorczy - jedynkami:

    Kod C - [rozwiń]
    for (i = 0; i< SZEROKOSC_OBRAZKA * WYSOKOSC_OBRAZKA * BAJTOW_NA_PIKSEL + 500; i++) {
    bufor_RAM_danych_obrazka[i] = 1;
    }




    Następnie wywołuję funkcję uruchamiającą kamerę i robiącą zdjęcie. Później drukuję zawartość wszystkich komórek z tablicy bufora odbiorczego:

    Kod C - [rozwiń]
    for (i = 0; i< SZEROKOSC_OBRAZKA * WYSOKOSC_OBRAZKA * BAJTOW_NA_PIKSEL + 500; i++) {
    snprintf(textToWrite, sizeof textToWrite, "%i;", (unsigned int)bufor_RAM_danych_obrazka[i]);
    USART_puts(USART2, textToWrite);
    }



    W terminalu otrzymuję dane z kamery. W pewnym momencie otrzymuję już same jedynki - oznacza to, że te bajty nie były modyfikowane przez DMA. Gdy policzyłem, ile tych jedynek w rzeczywistości jest - wyszło 500. Czyli okazuje się, że do tej tablicy trafia o 500 bajtów mniej danych - czyli tyle, ile trzeba... Log pokazujący całą sytuację jest w załączniku (jest to zawartość bufora odbiorczego bufor_RAM_danych_obrazka, z którego dane powinny później zostać przekonwertowane w enkoderze BMP..
  • #51
    A.T.
    Poziom 20  
    Spróbuj wygenerować taki sygnał przy pomocy timera wbudowanego w stma. Wykorzystaj tryb PWM, ustaw nie za wysoki zegar np. 12MHz i dzięki PLL sensora zrób z niego 24MHz. A dodatkowo do uzyskania rozdzielczości 176*144 radzę wykorzystać decymator wbudowany w kamerę. Tak jak zrobiłeś teraz, ustawiasz tylko samą rozdzielczość, w ogóle nie ustawiasz reszty ważnych parametrów takich jak V_BLANKING, H_BLANKING itd., które także należy dostosować przy zmianie rozdzielczości. To także może być powód.
  • #52
    rezontor
    Poziom 15  
    W załączniku zamieszczam archiwum z 2 katalogami:

    - Bez konwersji - logi z danymi surowymi
    -Z konwersją - logi z danymi przekonwertowanymi + zdjęcia utworzone na podstawie tych logów (bmp)

    Zgodnie z obietnicą, każdy katalog ma dane z 5 sytuacji:
    - red: zdjęcie zrobione dla czerwonego ekranu
    -blue: zdjęcie zrobione dla niebieskiego ekranu
    -green: zdjęcie zrobione dla zielonego ekranu
    -ciemno: zdjęcie zrobione po zasłonięciu obiektywu, gdy jest ciemno
    -jasno: zdjęcie zrobione po zbliżeniu obiektywu do świecącej żarówki
  • #53
    rezontor
    Poziom 15  
    A.T. napisał:
    A dodatkowo do uzyskania rozdzielczości 176*144 radzę wykorzystać decymator wbudowany w kamerę. Tak jak zrobiłeś teraz, ustawiasz tylko samą rozdzielczość, w ogóle nie ustawiasz reszty ważnych parametrów takich jak V_BLANKING, H_BLANKING itd., które także należy dostosować przy zmianie rozdzielczości. To także może być powód.


    Może są gdzieś do pobrania prawidłowe konfiguracje kamery?
  • #54
    atom1477
    Poziom 43  
    No niestety te pliki ze zrzutami z kamery są złe. Są w nich prawie same zera.
    Obraz z kamery to powinny być w większości krzaki. Nawet jak obraz jest czarny albo biały (bo z 1 bit szumu na pewno tam będzie).
    Jak są prawie same 0 to znaczy że coś nie tak tam się dzieje. Może DMA robi jakieś Dummy transfery.
  • #55
    rezontor
    Poziom 15  
    Ale najdziwniejsze jest to, że gdy matryca zostanie mocno naświetlona (plik jasno_konw.bmp z załącznika), to obraz nie jest czarny, jak w innych przypadkach:
    [STM32F4] - Układ DMA: DCMI -> SRAM

    tylko kolorowy:
    [STM32F4] - Układ DMA: DCMI -> SRAM

    Dodam, że program jest nadal ten sam, co kilka postów wcześniej, w paczce Kamera_stm32.zip)
  • #56
    atom1477
    Poziom 43  
    Jednak wygląda to na format RGB.
    Tylko kamera ma małą jasność.
    A bity są pozamieniane.
    Tutaj to widać:
    [STM32F4] - Układ DMA: DCMI -> SRAM
    RGB1 to obrazek z bitów jak by je złożyć tak jak są.
    Poniżej te 3 rzędy obrazków po 6 obrazków to poszczególne składowe.
    Widać że bity są nie po kolei.
    Można się domyśleć że najstarszym bitem czerwonym powinien być bit 5. Bo się on najmniej zmienia. Najwięcej się zmienia bit 6 więc to pewnie najmłodszy.
    Więc kolejność pewnie powinna być taka: 54376.
    W zielonym podobnie ale jest 1 bit więcej i jest przesunięcie o 1 bit w lewo.
    Przy niebieskim wygląda na to jakby brakowało jednego bitu.
    Jak się ręcznie poustawia kolejność bitów to obrazek robi się czytelny.
    To jest ten obrazek oznaczony jako RGB2. Nie ustawiałem tam tylko koloru niebieskiego bo się obrazek wtedy znacznie pogarsza (pewnie przez ten jeden brakujący bit).
  • #57
    A.T.
    Poziom 20  
    To o czym napisał atom1477 to właśnie to o czym piszę już może od paru postów, ale autorowi nie chce się tego poprawić. No cóż.

    Dodano po 3 [minuty]:

    Poszukaj sobie w Internecie sterowników dla linuxa pod nazwą EX3691. To jest ten sam sensor co MT9D111. Wykorzystaj ich konfigurację i spróbuj zegar z timera.
  • #58
    atom1477
    Poziom 43  
    No tak właśnie też pomyślałem chwilę po napisaniu posta. Wcześniej zdawało mi się że autor już to poprawił.
    Zaraz sprawdzę co się stanie jak to poprawię za niego :D

    EDIT. No, po tej poprawce nic nie trzeba więcej kombinować z bitami.
    Obrazek od razu jest prawidłowy:
    [STM32F4] - Układ DMA: DCMI -> SRAM

    Tylko trochę ciemny jak na świecenie żarówką prosto w obiektyw.
  • #59
    rezontor
    Poziom 15  
    atom1477 napisał:
    EDIT. No, po tej poprawce nic nie trzeba więcej kombinować z bitami.
    Obrazek od razu jest prawidłowy:
    Tylko trochę ciemny jak na świecenie żarówką prosto w obiektyw.


    Starałem się skierować kamerę w kierunku żarówki - być może zadziałała automatyczna korekcja jasności. Ten niebieski kolor może być kloszem lampki, w kierunku której skierowałem kamerę.

    A.T. napisał:
    To o czym napisał atom1477 to właśnie to o czym piszę już może od paru postów, ale autorowi nie chce się tego poprawić. No cóż.

    Dodano po 3 [minuty]:

    Poszukaj sobie w Internecie sterowników dla linuxa pod nazwą EX3691. To jest ten sam sensor co MT9D111. Wykorzystaj ich konfigurację i spróbuj zegar z timera.


    Jestem w czasie modyfikacji. Najpierw stworzę, na podstawie sterowników dla linux-a, nową konfigurację kamery. Gdy nowa konfiguracja nie pomoże, ustawię timer, który będzie pracował w roli generatora sygnału xclk.

    Znalazłem coś takiego: http://dev.openaos.org/browser/trunk/avx6/lin...vers/media/video/omap/sensor_ex3691.c?rev=198

    oraz takiego:

    http://www.8051projects.net/lofiversion/t5463...nit-code-for-2mpix-camera-module-mt9d111.html

    Spróbuję , na podstawie tych konfiguracji, stworzyć własną, dopasowaną do wcześniej podanej rozdzielczości. Ustawię też rzeczy, o których wspominał m.in. A.T.

    Dziękuję wszystkim za dotychczasową pomoc :) .
  • #60
    rezontor
    Poziom 15  
    Witam,

    poprawiając taktowanie kamery i jej nastawy, otrzymuję aktualnie takie obrazki jak w załączniku. Nie są nadal poprawne - gdzie może jeszcze tkwić problem?