Brak odpowiedzi I2C z kamerki CMOS PO3030K na ARM Philips 2144

Witam
Mam następujący problem. Zakupiłem sobie kamerke CMOS PO3030K w maritex. To jej parametry:
http://www.maritex.com.pl/offer.php?bnr=3&nr=9435&pid=8384&lang=PL
Podłączyłem to do procesora ARM Philipsa 2144. W kamerce tej za pomocą interfejsu I2C ustawia sie parametry kamerki poprzez zapis odpowiednich wartości do odpowiednich rejestrów. Podłączyłem więc do sprzętowego I2C w procesorze i nic. Po wysłaniu adresu kamerki nie mam żadnej odpowiedzi (potwierdzenia) od kamerki, że otrzymała dane.
Mam wzwiązku z tym pytanie, czy ktos bawił sie juz kiedys ta kamerka i czy mial jakies problemy z nia, niekoniecznie z obsługą I2C (jakiekolwiek problemy)?
Programu i schematu nie dołączam gdyż narazie wydaje mi się zbędny. Chciałem sie dowiedzieć czy ktoś wogóle cos takiego uruchamial.

Witam, aktualnie zajmuję się tą kamerką. Do IIC wykorzystuje TWI z at91sam7s256, sama komunikacja działa u mnie bez problemów. Natomiast pojawił się u mnie problem z zapisem do dwóch rejestrów, w tym którego najbardziej potrzebuje - ISP control (chce ustawić format piksela na 565) . Wysyłając paramtery do kamery mam podłączone tylko IIC, jakieś problemy miałem więc odłączyłem spartana (jego będe używał do reszty). Po wygenerowaniu MCLK 25MHz kamerka elegancko zaczyna wypluwać dane. Na razie tyle moge o niej powiedzieć. Mam na ten projekt jeszcze 2 tygodnie więc coś jeszcze niebawem o niej napiszę.

Czesc
Ja później w projektcie z tą kamerką PO3030K napisałem programową obsługe magistrali I2C dla ARMa. Przy tej programowej obsłudze skomunikowałem się z tą kamerką ale podobnie jak u Ciebie nie można było zapisywać do wielu bardzo ważnych rejestrów. U mnie też po wygenerowaniu MCLK 24 MHz kamerka wyrzucała coś na magistrali równoległej. Owszem dane zawierały w sobie sekwencje 4 bajtów startowych i końcowych ale ważne dane po tych bajtach startowych nie zmieniały się w pełnym zakresie swoich możliwości przy całkowitym zasłonięciu obiektu i przyświeceniu na obiektyw lampką o bardzo jasnym świetle. Więc moja interpretacja była taka, że coś jest nie tak. Czy u Ciebie te dane mają sensowne odzwierciedlenie do rzeczywistego rejestrowanego obrazu?? Mi osobiście niestety nie udało sie uruchomic tej kamerki, ale życze powodzenia. Czy sprzęt sam robiłeś do tego??

Za parę dni zabieram się również do walki z tą kamerką...
Podłączam ją do ARM ST912. dobrze wiedzieć ze nie jestem sam

Myślę że mogę wam pomóc...
Sprawa wygląda tak ze dokumentacja dostępna na stronie producenta jest "zła", stara i nieaktualna.
Od znajomych wiem, którzy też mieli problemy z rejestrami, że podobno nowa dokumentacja jest "w miarę porządku".

Jeśli jesteście zainteresowani to mam dostępna dokumentację z 2007 roku.

Ja jestem zainteresowany tą dokumentacją. Byłbym wdzięczny za podesłanie na meila.

jedrek_1981, Aktualnie jeszcze nic nie probowałem jakoś konkretnie odbierać, póki co podglądałem na oscyloskopie i to w dodatku analogowym :/ W weekend na nocke nad nią przysiąde i zdam relacje. Do kamery mam tylko płytkę z wlutowanym konektorem i stablilizatorem i wyprowadzonymi liniami na standardowe piny. Płytkę robił kolega (frezowana).

W niedalekich planach mam podłączenie jej do spartana3E i użyciu ddramu jako buforu ramki.

j3di, no napewno nie jesteśmy sami. U mnie na uczelni tą kamerką zajmują się jeszcze dwie osoby (pracownicy naukowi). Będe musiał popytać ich o szczegóły. Oczywiście z tego też dam relacje
Też jestem bardzo zainteresowany nową wersją dokumentacji, prosiłbym na maila.

Czego używacie do obsługi danych z kamery ?

No ok, można powiedzieć że odpaliłem kamerke. Wyświetlam thresholda z całej ramki (640x480) na monitorze, jakieś jeszcze minimalne błędy w synchronizacji mam ale ogólnie działa. Jak ktoś będzie potrzebował pomocy - chętnie pomogę.

j3di, cały czas czekamy na dokumentacje

Witam

Dokumentacje udostepnilem pod adresem:
http://morpheo.w.inds.pl/PO3030K(Rev_1)_CDS_V1_3.pdf
Plik okolo 2,2MB

Może sie zdażyć ze serwer bedzie nie dzialal... czasami tak bywa.

Mam tez pytanie do "mafjozoo", dokladnie chodzi o sterowanie...
1. czy do komunikacji prz I2C potrzeba podawać zegar MCLK ? czy bez tez powinien sie komunikowac?
2. jak wyglada zapis i odczyt rejestrow przez I2C
tzn sekwencja odczytu rejestru.. (Start, (jakies potiwerdzneie??, ADRES jakies potwierdzenie ;lub brak??? itd)
i sekwencja zapisu...

3. jak rozwiązales synchronizacje, czy dla kazdego sygnalu PCLK, HSYNC, VSYNC. uzywasz np. external interrupt i odpowiednio
dla przy wystapieniu VSYNC wlaczasz INT dla HSYNC, i dalej przy wystapieniu HSYNC wlaczasz INT dla PCLK, a przy PCLK odbierasz dane? czy jakos inaczej to rozwiazales?

j3di napisał:

1. czy do komunikacji prz I2C potrzeba podawać zegar MCLK ? czy bez tez powinien sie komunikowac?

Nie trzeba. Wystarczy samo I2C podłączyć.

j3di napisał:

2. jak wyglada zapis i odczyt rejestrow przez I2C
tzn sekwencja odczytu rejestru.. (Start, (jakies potiwerdzneie??, ADRES jakies potwierdzenie ;lub brak??? itd)
i sekwencja zapisu...

Dokładnie tak jak w dokumentacji, w sumie wszystkie podane tryby działają - pojedyńcze zapisy i odczyty jak i wielokrotne.

Pojedyńczy zapis - start, write, adres slave'a (0x6E), adres rejestru, stop
Pojedyńczy odczyt - start, read, adres slave'a (0x6E), adres rejestru, stop

j3di napisał:

3. jak rozwiązales synchronizacje, czy dla kazdego sygnalu PCLK, HSYNC, VSYNC. uzywasz np. external interrupt i odpowiednio
dla przy wystapieniu VSYNC wlaczasz INT dla HSYNC, i dalej przy wystapieniu HSYNC wlaczasz INT dla PCLK, a przy PCLK odbierasz dane? czy jakos inaczej to rozwiazales?

Z tego co piszesz widze, że masz zamiar zrobić to na mikrokontrolerze a ja sobie na szybko napisałem design na fpga. Szczerze powiem, że nie zastanawiałem się jak to zrobić na uC. Jeżeli zamierzasz zrobić to na wspomnianym przez Ciebie STR912 musisz zastanowić się napewno co chcesz robić - nawet threshold z ramki ci sie nie zmieści do ramu, do flashu chyba nie ma sensu, za szybko go sobie zajeździsz. Mipsów teoretycznie powinno ci wystarczyć. Ja ogólnie zrobiłem to tak:

Moduł oparty o opadające zbocze PCLK wrzuca mi w zależności od tego czy to wartościowa informacja (HSYNC i VSYNC w górze) na bierząco robionego thresholda do bufora linii. Na opadającym HSYNC bufor lini wpisuje w odpowiednie miejsce w syntezowanej pamięci 640x480 (dosyć nietypowa szerokość). Do tego oczywiście trzeba było dorzucić liczniki pilnujące aktualnego miejsca w pamięci. Drugi moduł pobiera przez bufor linię z ramu i wyświetla na monitorze.

U ciebie proponowałbym zwolnić trochę PCLK, z tego co pamiętam może mieć nawet MCK*1/128, wpiąć je jako external interrupt i w hadlerze przerwania badać hsync i vsync już jako zwykłe wejścia. Radziłbym zapisywać tylko fragment obrazu i to najlepiej sprogowany i po odebraniu go przesłać go pc'ta i wyświetlić jako bitmape. Hadlera przerwania też musiałbyś mieć dosyć sprawnie napisanego żebyś się zmieścił przed następnym PCLK. Innych pomysłów na razie nie mam.

Dzięki za dokumentacje

Hmm...
Chce to rozwiazac troche inaczej..
Nie mam potrzeby zapisaywania calej ramki! (btw. Mam ram 2MB dolączony).
Wpadlem na pomysl zeby dane slac odrazu do wyswietlacza!. SPI
Mam wyświetlacz od S65... 136x172 (16bit - taki sam format jak kamerka RGB565) i potrzebuje tylko thresholda wysylac.
Rozdzielczosc wyswietlaczmi nie przeszkadza bo to jest tylko orientacyjna wizualizacja.

Myslalem o takim roziwazaniu o jakim piszesz, ale stwierdzilem ze wtedy mimo iż nie bedą przesyłane "znaczace" dane to external interrupt z PCLK i tak bedzie niepotrzebnie sie aktywowal, a tych niepotrzebnych pikseli jakbyniebylo troche jest.

Dzisiaj mam chwile czasu to moze cos powalcze -> dam znac jak to chodzi.

Dzieki za pomoc!!!
Pozdrawiam

Dodano po 5 [godziny] 22 [minuty]:

Jeszcze pytanie skad wziales taki adres SLAVA?


OK.
Udało mi sie rozwiązac wszystkie problemy z I2C - wszsytko dziala jak nalezy. (Wymagane bylo male opoznienie przed odczytem odbieranego bajtu)
Wlasnie pracuje nad nowym pomyslem jak przyspieszyc obsluge odczytu danych obrazu.

Witam,
Ostatnio zakupiłem sobie ten moduł kamery i planuje go uruchomic na uC.
Ponieważ, nie zabierałem się jeszcze do pisania kodu chciałbym się spytać kogoś o poprawne podpięcie jej do uC, żeby już na wstępie nie uszkodzić tego maleństwa. Przeczytałem dokumentacje, dlatego chciałem się tylko upewnic czy dobrze myśle, mianowicie:
a) 100n między AVDD i AGND
b) 100n między HVDD i DGND
c) 100n miedzy DVDD i DGND
d) 1.5k miedzy SDA, SCL a zasilaniem uC
e) AGND połączone z DGND i połączone z masą uC
f) na AVDD i DVDD 1.8V
g) na HVDD 1.8~3.3V
Reszta wyprowadzen bezpośrednio do uC(używam uC na 3.3V)???
Czy coś jeszcze należy tutaj mieć na względzie czy wystarczy to do dobrego podpięcia tego modułu???
Porównałem te dokumentacje('05 '07) tak na szybko i napewno błąd był w rejestrze TGcontrol4(0x20) Czy jakieś jeszcze ważne rejestry były źle w dokumentacji z '05???
Nurtuje mnie jeszcze jedno odnośnie tych rejestrów, czemu nie ma ich wszystkich opisanych w wykazie(Register Table), tylko niektórych brakuje, że niby są 'Reserved'???
Z góry dziękuje za odpowiedż,
Pozdrawiam,
BearBeer

Witam,
Chciałbym się spytac, czy miałby ktoś jakiś przykładowy kod do tej kamerki? Chodzi mi głównie o sprawę przerwań zewnętrznych(HSYNC,PCLK,VSYNC), gdyż chcę ja podłączyc do uC(atmega) i chciałbym napisac do tego w miarę wydajny kod
Dziękuje za odpowiedź,
BB

Witam,
mam prośbę, czy mógłby ktoś tą aktualną dokumentację kamerki wrzucić na forum?
Pozdrawiam