[LPC1765] - [LPCXpresso] Powolne wywoływanie przerwań, wymiana na STM32F4 ?

Od kilku dni zabawiam się kamerką OV7670, próbuję pobrać z niej obraz w formacie RGB565 i o mało ambitnej rozdzielczości QCIF(bo taki zmieści się w całości w RAM). Program, który napisałem ma za zadanie w przerwaniu pobrać obraz do pamięci, zatrzymać przerwanie i zapisać zawartość do pliku bmp. Oto mój kod :

Jest to druga wersja programu, gdzie procesor ma sprawdzać sygnały synchronizacji. Poprzednio (odkomentowane części), próbowałem na "pałę" odliczyć 144*176 pikseli.

Kamerę inicjuję tak :


Po uruchomieniu, na terminal dostaję

Cytat:

Otw. pliku 0
Init OV7670 1
System Clock 120

i program się nie kończy. W pierwszej wersji program kończył sie, ale wynikowy plik "camera2.bmp" zawierał garść losowych zielonych kropek na czarnym tle.

Z moich obserwacji wynika, że procesor nie nadąża z przerwaniami od sygnału PCLK, pomimo pomniejszenia go do ok. 894kHz. Chyba, że popełniłem jakiś rażący błąd w kodzie, którego nie widzę.

Pomimo wszystko, myśląc przyszłościowo, do mikrokontrolera należało by podłączyć zewnętrzną pamięć RAM, by uzyskać obraz sensowniejszej rozdzielczości. LPC1765 nie ma wyprowadzonej szyny adresowej. Myślę, że wykorzystanie do tego I/O to nie trafiony pomysł. Zastanawiam się na zmianą kalibru, i wymianie procesora na STM32F407, który ma wbudowany układ peryferyjny DCI. W dobrej cenie jest płytka STM32F4 discovery. Czy koledzy mogli by mi doradzić coś w tej sprawie, czy warto zainteresować się tym układem? Jestem raczej amatorem (i jako amator mogę nie podołać), ale chciałbym się dowiedzieć jak fachowo realizuje się takie rzeczy.

trwgQ26xxx napisał:

..., ale chciałbym się dowiedzieć jak fachowo realizuje się takie rzeczy.

Rozwiązaniem jest FPGA... będzie taniej. Wyjdziesz na tym też zdecydowanie lepiej niż z uC. I spokojnie zmieści się tam soft-procesor z dostępnym kompilatorem C/C++.

trwgQ26xxx napisał:

//Who fucking cares?

Tak samo widać przejmujesz się maksymalną częstotliwością układu...

4\/3!!

Dziękuję za odpowiedzi.
tymon_x

Cytat:

Rozwiązaniem jest FPGA... będzie taniej. Wyjdziesz na tym też zdecydowanie lepiej niż z uC. I spokojnie zmieści się tam soft-procesor z dostępnym kompilatorem C/C++.

Rozumiem masz na myśli układ pokroju np. tego : XC3S200, do którego podłączył bym sobie RAM, jakiś konfigurator, np. EPCS4SI8N (?), tą kamerkę. Wtedy zupełnie zrezygnował bym z mikrokontrolera i miałbym zaimplementować MicroBlaze na tym FPGA ? Przeglądnąłem kurs z EP z 2006r oraz temat na elektrodzie "Kompedium wiedzy na temat CPLD/FPGA" i obawiam się, że na dzień dzisiejszy mnie to przerasta <wstyd>. Z mikrokontrolerami miałem już wcześniej do czynienia, natomiast FPGA to dla mnie zupełna nowość.

Freddie Chopin

Cytat:

Tak samo widać przejmujesz się maksymalną częstotliwością układu...

Och, przepraszam. Ten komentarz dotyczy funkcji get_fattime() . Co do nad taktowania to zrobiłem to tymczasowo dla sprawdzenia czy to coś pomoże. Oczywiście zdaję sobie sprawę, że w nocie jest wyraźnie napisane, że tylko LPC1769 i LPC1759 może pracować przy 120MHz, inne tylko do 100MHz.

Wracając do sedna sprawy - problem jaki chcę rozwiązać przedstawia się tak : Mam dwa urządzenia A(umownie odbiornik) i B(umownie nadajnik), sercem których jest LPC1765. Oba urządzenia mają podłączone kilka czujników na magistralach I2C, 1-Wire i SPI. Ponadto urządzenie A ma dwa wyświetlacze od SX65, natomiast B ma podłączoną kamerkę OV7670. A i B komunikują się ze sobą za pomocą modułów Bluetooth, wymieniając się odczytami z czujników. Z tą częścią nie mam problemów. Problem powstał, kiedy właśnie podłączyłem kamerę.

Transmisja miała by wyglądać tak, że najwyższy priorytet ma transmisja odczytów z czujników, natomiast "co jakiś czas" miała by być przesyłana jedna linia obrazu. Obraz jaki chciałbym odbierać z urządzenia B to QVGA w formacie RGB565, gdyż później, montując już wszystko na gotowych płytkach (na razie A i B "istnieją" na płytkach stykowych) procesor w A wymienił bym na LPC1788, dokładając do niego wyświetlacz TFT 320*240. Co do uaktualniania obrazu, zadowoliło by mnie odświeżanie z prędkością klatka/30sekund.

Rozumiem, że nie warto nawet próbować siłować się z tą kamerą przy użyciu Cortexa-M4, tylko od razu zacząć zgłębiać temat FPGA ? Czy ten układ, który podałem na początku tematu będzie odpowiedni do tego zadania?

trwgQ26xxx napisał:

Dziękuję za odpowiedzi.
tymon_x

Cytat:

Rozwiązaniem jest FPGA... będzie taniej. Wyjdziesz na tym też zdecydowanie lepiej niż z uC. I spokojnie zmieści się tam soft-procesor z dostępnym kompilatorem C/C++.

Rozumiem masz na myśli układ pokroju np. tego : XC3S200, do którego podłączył bym sobie RAM, jakiś konfigurator, np. EPCS4SI8N (?), tą kamerkę. Wtedy zupełnie zrezygnował bym z mikrokontrolera i miałbym zaimplementować MicroBlaze na tym FPGA ? Przeglądnąłem kurs z EP z 2006r oraz temat na elektrodzie "Kompedium wiedzy na temat CPLD/FPGA" i obawiam się, że na dzień dzisiejszy mnie to przerasta <wstyd>. Z mikrokontrolerami miałem już wcześniej do czynienia, natomiast FPGA to dla mnie zupełna nowość.

Owca cała, wilk syty:
FPGA Lattice LFE2-6E-6TN144C
SDRAM 32MB - M52S32321A-6BIG

Produkty Lattice są bardzo łatwe w użyciu, najbardziej przyjazna firma dla użytkowników, a zbudowanie projektu w FPGA nie wymaga praktycznie żadnej wiadomości z tego zakresu, idealne for dummies. Masz tam darmowe środowisko Lattice Diamond Design Software, wykreowanie czegokolwiek może być na przykładzie klikania, przeciągania bloczków i rysowania, nie trzeba nawet znać żadnego HDL do FPGA, żeby odpalić darmowy soft-procesor jak ten: LatticeMico32 Open. Zaprojektujesz taki "mikrokontroler" jaki będziesz chciał, jest tam pokaźna paczka modułów i wszystko przez metodologię drag & drop i klikania w paru miejscach. Znajdziesz duży zasób materiałów jak zacząć, parę chwil i już możesz kompilować programy w C dla Mico32. Na opencores.org znajdziesz dodatkowe moduły napisane już w HDL.

MicroBlaze jest dla PLD-snobów Troszkę jego licencja kosztuje.

Rozważ kiedyś tą alternatywę, sam składam teraz kamerę w rozdzielczości HD: [FPGA] - Kamera HD do systemu obróbki obrazu

Tutaj masz ciekawy temat: uC [LM32] ze sterownikiem ISI i LCD TFT na FPGA. Dużo pytań.

tymon_x

WOW Zapoznałem się z tym, co mi podesłałeś i jestem pozytywnie zaskoczony. Nigdy nie spodziewałbym się, że to może być w ogóle proste. W takim razie daję sobie spokój z Cortexem-M4, i będę robił to na LFE2-6E. Za jakiś czas (miesiąc ?) postaram się poinformować jak mi idzie/co mi z tego wyszło, bo muszę dopiero zamówić układy, a płytkę zlecić do wykonania w zakładzie(płytki pod BGA nie da się wykonać metodą chałupniczą). Serdecznie dziękuję Ci za nakierowanie mnie na to rozwiązanie.

No cóż, a więc jak rozwiązałem swój problem ?

Próbowałem początkowo jeszcze bawić się z OV7670, ale podczas eksperymentów uległa ona uszkodzeniu (?, brak przebiegu na PCLK i brak komunikacji po SCCB). Zabiło ją ESD, albo włączające się przy przeprogramowaniu (po resecie) wewnętrzne pull-upy do 3V3.

Wziąłem zatem zwykłą cz-b kamerę z wyjściem CHINCH, pamięć SRAM, przetwornik ADS830(dużo na wyrost), nudny i oklepany układ LM1881 oraz układ CPLD XC9572XL. Tak powstał digitalizer - układ w "pętli" próbkuje sygnał z kamery i umieszcza go w pamięci. Następnie, gdy mikrokontroler chce pobrać dane z tej pamięci, próbkowanie jest zatrzymywane i może pobierać z pamięci pojedyncze bajty dowolnie wolno.

W przyszłości na pewno powrócę do tego zagadnienia, nie wiem czy wykorzystując jeszcze FPGA, ale jedno jest pewne - w trosce o własne nerwy wezmę inny moduł kamery - np. TCM8230.