[STM32F4] - Jak skonfigurować DMA do przesyłania danych z DCMI do SRAM?

Witam.

Piszę właśnie program, którego zadaniem jest pobranie 1 klatki (zrobienie zdjęcia) z kamery MT9D111 (nota katalogowa: http://www.dragonwake.com/download/camera/MT9D111/mt9d111_rev5.pdf ) Klatki z kamery będzie pobierał mikrokontroler STM32F429, taktowany częstotliwością 180MHz.

Wzoruję się na informacjach zawartych na stronie: http://www.stm32.eu/node/307

Napisałem podstawowe funkcje, konfigurujące:

- PORTY GPIO, wykorzystane do komunikacji z kamerą:



- RCC (dołączenie sygnałów taktujących do peryferii)



- układ interfejsu kamery DCMI oraz DMA:




- układ przerwań NVIC



- oraz układ I2C do wysyłania ustawień do kamery:


Później, w programie głównym, wywołuje powyższe funkcje konfigurujące:




Następnie, sprawdzam, czy kamera jest podłączona i inicjalizuję kamerę:



Jeżeli chodzi o funkcję inicjalizującą kamerę i inne funkcje związane z kamerą - są one w osobnym pliku i przedstawiają się tak:





Teraz, gdybym chciał wykonać zdjęcie, wywołuję w pętli głównej funkcję wykonaj_foto():




Czyli w tym momencie, po wywołaniu funkcji wykonaj_foto(), układ DMA powinien wysłać dane do RAMU - do tablicy, zdefiniowanej wcześniej w programie:



do której DMA powinien wysyłać dane z DCMI, jak zostało skonfigurowane w 3 funkcji w poście (czyli DCMI_Config() ):



Tablica ma rozmiar 9600, ponieważ będą przesyłane obrazy o rozdzielczości (tak ustaliłem) 160 x 120 pikseli, w formacie 565RGB (czyli po 2B na piksel). Wynika z tego, że potrzebuję 160*120*2 = 38 400 bajtów w tablicy. Każda komórka tablicy ma 4B, więc potrzebuję 38 400 / 4 - 9600 komórek typu uint32.

Teraz chciałbym zapytać, co robię źle... Program, po wgraniu do mikrokontrolera nie działa. Efektem wywołania funkcji robiącej zdjęcie powinna być zapełniona tablica bufor_RAM_danych_obrazka, jednak tak nie jest. Czym to może być spowodowane?

Czy jest może źle układ DMA skonfigurowany? - mam wątpliwości w miejscach:

Sam napisałeś 38400 / 4 to czemu zapisujesz do DMA 38400, a nie 9600?
No i to:
DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;
też bym ustawił na DMA_MemoryDataSize_Word.

Pozdrawiam

Dodano po 3 [minuty]:

No i tak jak masz teraz ustawione DMA w trybie Normal to ta funkcja wykonaj_foto zadziała tylko raz, później będziesz musiał na nowo konfigurować DMA. Lepiej przestaw je w opcję circular.

A.T. napisał:

Sam napisałeś 38400 / 4 to czemu zapisujesz do DMA 38400, a nie 9600?

Poprawiłem.

A.T. napisał:

DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;
też bym ustawił na DMA_MemoryDataSize_Word.

Chciałbym, aby dane w RAMIE były zapisane jako struktury 8 bitowe - łatwiej później będzie to przetwarzać.

Dodano po 3 [sekundy]:

A czy taka konfiguracja przerwań od układu DCMI jest poprawna?

To nie jest konfiguracja tylko funkcja obsługi przerwania. Ta pętla while czekająca na koniec odbioru wygląda nie najlepiej w funkcji przerwania. Na początek spróbuj bez przerwań czy w ogóle działa.

Niestety, ale nie działa. Program zatrzymuje się na:

w funkcji

Dodano po 19 [minuty]:

2 rzecz. Przykład ze strony http://www.stm32.eu/node/307/page/0/3 zakłada, że częstotliwość taktowania mikrokontrolera jest równa 168MHz. Wtedy sygnał taktujący kamerę, po podzieleniu przez 3, wynosi XCLK = 56MHz. W moim przypadku częstotliwość taktowania wynosi 180MHz i dzieląc ją przez 3, otrzymuję 60MHz. Czy ta zmiana zegara wiąże się ze zmianami wartości wpisywanych do rejestrów kamery? Na stronie http://www.stm32.eu/node/310 jest napisane, że "Oprócz tego do podłączenia pozostał jeszcze jeden sygnał: sygnał zegara taktującego który trzeba podać do modułu.. Zazwyczaj częstotliwość zegara w przypadku różnego typu modułów zawiera się w granicach 6...80 MHz." Więc mieści się w tym przedziale...

Chodzi mi o fragment:

Kamery zwykle mają wewnętrzny PLL. Częstotliwość sygnału XCLK i wartości wpisywane do rejestrów kamery muszą być odpowiednio dobrane.

A rejestry Ci się konfigurują? Bo jak nie ma sygnału zegarowego XCLK albo jest niepoprawny to nawet rejestrów przez I2C nie da się skonfigurować.
Zgadza się w kamerze jest PLL, w datasheet masz wzór gdzie dobierasz 3 wartości i wpisujesz to tych dwóch rejestrów:

Dzisiaj wszystko jeszcze raz uruchomiłem i o dziwo zaczęły przychodzić dane z kamery, a program się nie zawiesza.

Dodałem w programie takie polecenia:



Najpierw jest zerowana tablica, do której trafią dane z kamery. Następnie kamera jest uruchamiana i jest robione zdjęcie. W efekcie w tablicy bufor_RAM_danych_obrazka otrzymuję wartości, które przy pomocy funkcji USART_puts() wysyłam przez terminal.

Otrzymuję następujące dane, które - jako log z terminala - zamieszczam w załączniku.


Załącznik:

Ten bufor zadeklarowałeś wcześniej o rozmiarze 9600, to skąd bierzesz tam jakieś 19200? Rozumiem, że nie masz wyświetlacza żeby zobaczyć co zwraca kamera. To spróbuj dodać nagłówek bmp do twoich danych i zobacz czy to co dostajesz to jest jakiś obraz.

A.T. napisał:

Ten bufor zadeklarowałeś wcześniej o rozmiarze 9600, to skąd bierzesz tam jakieś 19200? R

Zmieniłem rozdzielczość obrazu na większą.

A.T. napisał:

To spróbuj dodać nagłówek bmp do twoich danych i zobacz czy to co dostajesz to jest jakiś obraz.

W Internecie znalazłem program enkodera.




Nie wiem tylko za bardzo, w jaki sposób mogę przekazać moje dane do tej funkcji przetwarzającej do postaci BMP...

Hmm nie rozumiem problemu, wystarczy, że wywołasz tę funkcję z odpowiednimi argumentami:


Jako pierwszy argument podajesz wskaźnik do Twojego bufora z surowymi danymi czyli bufor_RAM_danych_obrazka, a jako przed ostatni wskaźnik do Twojego nowego bufora gdzie zostanie przepisany Twój obrazek i dodatkowo jeszcze dodany nagłówek bmp. Musisz jednak uważać, żeby zmieścić się w RAMie procka.

Rozumiem. Dziękuję za pomoc.

Poczyniłem kilka zmian w programie. Utworzyłem drugą tablice - pierwsza to ta, która przyjmuje dane z kamery (bufor_RAM_danych_obrazka), a druga jest tablicą wyjściową z przekonwertowanym plikiem (p_bufor_RAM_pliku).

W wcześniejszych definicjach tablic i określaniu danych do przesłania popełniłem błąd - nie wziąłem pod uwagę tego, że każdy piksel to 2B. Więc przy rozdzielczości 320 * 240, liczba danych wynosi: 76800 * 2B = 153600B = 150kB. Wynika z tego, że 2 tablice (dane z kamery i dane przekonwertowane) w wbudowanej pamięci RAM się nie zmieszczą (STMF429 ma 256kB RAMU).

Muszę zatem zmniejszyć rozdzielczość do np. QCIF = 176 x 144 (szerokość = 176, wysokość = 144). Dane o obrazie będą wtedy zajmowały 50688 bajtów i dwie tablice się zmieszczą.

Pomyślałem też nad zmianą typów tablic z:


na



Czyli po podstawieniu za szerokość i wysokość konkretnych liczb mamy:



Zmiany wymusiły modyfikacje w konfiguracji DMA:




W pętli głównej planuję umieścić takie wywołanie funkcji:



Po wywołaniu funkcji dostanę tablicę bajtów p_bufor_RAM_pliku , w której jest zdjęcie z kamery wraz z nagłówkiem BMP. Teraz wystarczy wysłać dane do komputera i ten ciąg liczb 8 bitowych zapisać w postaci pliku BMP.

Chciałbym zapytać, czy powyższy tok pisania programu jest prawidłowy?

Dobrze kombinujesz, jednak źle zmieniłeś wartość danych jakie ma przesłać DMA. Tam podajesz ilość 4bajtowych paczek. Czyli dla Twojego nowego formatu będzie to: 176*144*2/4=12672, i tą wartość wpisujesz do DMA. Reszta wydaje mi si poprawna. Jedyne co, to przyglądnij się dokładnie ustawieniom formatu wyjściowego obrazu kamery. Nie może być ustawiona opcja "Swap even and odd bytes". Jeśli jest to uzyskasz obraz z zamienionymi kolorami bodajże R z B.

Aby otrzymać rozdzielczość 176 x 144, ustawiam rejestry w taki sposób:




Po wywołaniu funkcji robiącej zdjęcie oraz konwertującej do postaci BMP, otrzymuję następujący ciąg bajtów (załącznik) - każdy bajt jest przedstawiony przy pomocy tekstu (0-255), a poszczególne bajty są oddzielone od siebie przecinkami.

Zastanawiam się, w jaki sposób mógłbym zapisać teraz plik BMP. Czy wszystkie bajty zamienić na postać zero-jedynkową (bin) i zapisać pod rozszerzeniem *bmp?

Zamieniłem otrzymane dane z kamery na postać binarną. Niestety, ale przeglądarka grafiki Windows informuje o uszkodzeniu pliku... Czym to może być spowodowane?

rezontor napisał:

Czym to może być spowodowane?

Brakiem nagłówka dla BMP?

Dydelmax napisał:

rezontor napisał:

Czym to może być spowodowane?

Brakiem nagłówka dla BMP?

Naglówek jest automatycznie dodawany w funkcji Kodowanie_z_bufor_RAM_danych_na_BMP_do_RAM_pliku, którą wywołuję.

Jakoś nie widzę tego nagłówka... (może po prostu nie mogę go znaleźć - sugeruję się tym: http://pl.wikipedia.org/wiki/Windows_Bitmap):

Dla porównania nagłówek pliku BMP (176x144) wypełnionego białymi pikselami:

Popełniłem błąd przy wywoływaniu funkcji konwertującej.

Teraz otrzymuję taki plik, który nadal wydaje się być uszkodzony:

Przeszczepiłem (na chybił trafił) kilka bajtów z innego pliku BMP. Wynikiem przeszczepu jest to "coś" poniżej, co udało mi się otworzyć programem PhotoFiltre i zapisać jako PNG.

Tak wygląda nagłówek zmodyfikowanego pliku:

Nie znam się na strukturze plików BMP, więc nie wiem czemu plik wygląda tak a nie inaczej. Może paleta kolorów w pliku jest źle skonstruowana?
EDIT: Bez modyfikacji nagłówka PhotoFiltre również odczytuje ten plik, pokazując to samo co wrzuciłem powyżej.
EDIT2: Dane w pliku wyglądają na losowe śmieci. Wkleiłem fragment innego obrazka do tego pliku w hexedytorze i PhotoFiltre wyświetlił ten fragment poprawnie.

Podobny obraz otrzymuję dla poprzedniego pliku, który został poprawiony: Wygląda to na całkowicie losowe wartości.

rezontor napisał:

Wygląda to na całkowicie losowe wartości.

Całkowicie losowe one jednak nie są. Pionowe linie w pliku powyżej przebiegają tak: linia z tylko zielonym kolorem (lub jego brakiem), linia z czerwonym i/lub niebieskim kolorem (lub ich brakiem). Wygląda to tak: G, R+B, G, R+B, G, R+B itd.
EDIT: Końcówka pliku wygląda na uciętą. Po doklejeniu szumu do końca pliku poprzez dopisanie kolejnych bajtów (skutkujące zwiększeniem rozmiaru pliku), czarny pas na górze pliku zmienia się w doklejoną treść, w tym przypadku szum:

Dodatkowo, po uzupełnieniu końcówki plik można bezproblemowo otworzyć w innych programach (dodaję go w załączniku).

Aktualnie najważniejsze pliki programu wyglądają następująco:

main.c:




stm32f4xx_it.c:



konfigPeryf.c:



kamera.c:



BMP_enkoder.c



usart.c:

Rozumiem, że z kamery oczekujesz obrazu w formacie 565. Jeżeli będzie to BMP 2-bajtowa, to dobrze by było jednak nagłówek skopiować z tego co wytwarza zastosowana procedura tworzenia struktury BMP. Z przykładów i sztucznego dodawania "końcówki" wynika, że dekoder oczekuje formatu 24bit.

Sprawdziłem, jaką wartość zwracała funkcja


zgodnie z opisem konwertera (http://www.stm32.eu/node/346), funkcja powinna zwracać wartość inną niż zero - w moim przypadku zwracała zero, a to oznacza, że bufor wyjściowy jest za mały.

Zwiększyłem więc bufor wyjściowy do wartości [76032+100]:



Po tym zwiększeniu, funkcja zaczęła zwracać wartość 76086. Oznacza to, że tyle bajtów jest w buforze wyjściowym, po konwersji. Wykorzystałem ten fakt w pętli wysyłającej dane do komputera:




Pliki są wysyłane do komputera w postaci:

66;77;54;99;0;0;0;0;0;0;54; ... itd

Napisałem program w JAVIE, który odczytuje te dane dzieląc je wg separatora ";" i zapisując w tablicy int (po przekształceniu z tekstu na liczbę):


Następnie jest wywoływana funkcja zapisująca plik:


któa wygląda tak:



Efektem działania funkcji jest plik bmp. Okazało się, że po tych modyfikacjach, pliki bmp są PRAWIDŁOWO zapisywane. Można je otworzyć przy pomocy systemowego programu do otwierania zdjęć. Problem jest z tym, że to, co jest na tych zdjęciach, jest całkowicie nieczytelne. Wykonałem 2 klatki przy różnych ustawieniach kamery - obrazek pierwszy powstał w zaciemnionym miejscu, a w przypadku obrazka drugiego - kamera patrzyła w kierunku światła. Mimo tych różnic w oświetleniu i położeniu obiektywu, zdjęcia są niemal identyczne (załącznik). Czym to może być spowodowane?

Tutaj jeszcze zamieszczam rozkład pinów, połączonych z kamerą:



---
Dodam, że gdy zmieniłem częstotliwość XCLK (na wyższą - podział 180MHz przez 2 a nie przez 3), otrzymałem zupełnie inne obrazy (załącznik; zdjęcia z 2 perspektyw).

Jeżeli kamera zwraca obraz w formacie 565 to on nie może być zapisany do postaci 24bitowej ot tak sobie. Procedura p. Szymaniaka nie konwertuje obrazu z 565 (16bit) do 888 (24bit). Co prawda pojawia się parametr liczby bajtów na piksel, ale tylko po to żeby go przepisać do nagłówka bitmapy

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.

Dodano po 1 [minuty]:

A i którą wersję ustawienia bloku PLL masz odkomentowaną?