Arduino OV7670 i2c brak komunikacji

[arasu]

Cześć,

bawię się od dłuższego czasu "arducam". Mam surowy moduł OV7670 bez ramu i walcze z nim na arduino nano. Już wcześniej udało mi się za pomocą samej atmegi 328 wyciągnąć z tej kamerki obraz, ale wtedy powiedzmy że nie wnikałem w ustawianie rejestrów kamerki, ściągnałem gotowca, dopasowałem do swojego uC, wgrałem i jakoś to działało. Teraz chciałem podejść do tematu troche ambitniej i ogarnąć sobie ustawienia kamerki( zmiana rozdzielczości, naświetlenia itd), no i zacząłem bawić się interfejsem SCCB kamerki. No i pojawiły się kłopoty.

Do komunikacji od strony arduino użyłem biblioteki Wire i skopiowałem kawałek kodu z githuba ArduCAM do odczytywania pojedynczego rejestru. No nie działało mi to, więc podpiąłem analizator stanów logicznych, i sie okazało że jedno z drugim za bardzo rozmawiać nie chce. Ogólnie sygnały wyglądaja dziwnie, w pewnych momentach zegar i2c ma częstotliwość 8mhz.

Kamerka wystawia sygnały na szynie danych i VSYNC, HS czy PCLK, ale przy zakrywaniu obiektywu to co pojawia się na D[0:7] nie różni się niczym od tego co jest przy odkrytym obiektywie, i przez to zastanawiam się czy ta kamerka nie jest uszkodzona (mimo że sygnały z niej jakieś wychodzą). Przyznam się, że zapomniałem się że kamerka operuje na 3,3V i podałem zegar bezpośrednio z pinu arduino na pin OV7670

Podrzucam szkic i zrzut z analizatora dla odczytu rejestru 0x12. Ma ktoś jakieś doświadczenia w tym temacie? Co o tym myślicie?

 

Pzdr

i2c_test.rar

[deshipu]

A czego dokładnie używałeś jak "działało"? Może sprawdź jeszcze raz z tym, to przynajmniej będziesz wiedział czy jest uszkodzona.

Generalnie takie kamerki mają osobno interfejs i2c do zmiany rejestrów, a osobny równoległy do odczytywania obrazu.

[marek1707]

To może zacznijmy od tego: czy rozumiesz rysunek który pokazałeś? Bo samo podpięcie analizatora i wysłanie przebiegów na Forum jeszcze nie rozwiązuje problemu, prawda? Tak więc opisz własnymi słowami co tam jest a co wg Ciebie powinno być. Ja widzę pewne osobliwe rzeczy, ale nie wiem co masz na I2C i co konkretnie miało się zadziać. Ciekaw jestem Twoich wniosków.

EDIT: Żeby ułatwić: zapis 8-bitowego rejestru I2C adresowanego 8-bitowym adresem wewnętrznym wygląda następująco:

• START
• Wysłanie 7-bitowego, "sprzętowego" adresu modułu na I2C + bit R/W=0 zakończone aktywnym ACKiem z zaadresowanego modułu
• Wysłanie bajtu adresu rejestru w module
• Wysłanie bajtu danych
• STOP

To musi być jedna transakcja ujęta w nawiasy zdarzeń START/STOP, które Twój analizator - jak rozumiem - oznacza kolorowymi kropkami. A teraz odnieś to do swojego wykresu, pobaw się w "znajdź różnice" i zastanów w którym miejscu spaprałeś kod i jak bardzo źle wołasz funkcje bilbioteki wire.

Edytowano Lipiec 4, 2019 przez marek1707

[arasu]

Wrzucam w załączniku wersje przebiegów jakich się spodziewam na szynie danych.

@deshipu sprawdzę na pewno jak tylko uda mi się odkopać tamten stary układ na atmega328 ^^

@marek1707 co do START/STOP to wiele źródeł w sieci powiela ten schemat: start - adres - rejestr - stop - dane, szkic skopiowałem z githuba ArduCAM więc przyjąłem to jako pewnik, ale zajrzałem do manuala atmegi i tam rzeczywiście stop jest na końcu. Zaraz sprawdze czy poprawiony szkic zmieni stan rzeczy.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

23 minuty temu, arasu napisał:

wiele źródeł w sieci powiela ten schemat: start - adres - rejestr - stop - dane

Trzeba mieć swój rozum, bo idę o zakład, że sieci znajdziesz dowolną głupotę. A ta, nawet powielona milion razy nie nabiera sensu. Jeśli rozumiesz protokół I2C to sam wiesz, że ten schemat nie ma prawa zadziałać. A jeśli nie rozumiesz tylko piszesz kod w oparciu o to co tam akurat znalazłeś w śmietniku, to tracisz czas. Radzę korzystać wyłącznie ze "źródeł pierwotnych". Mam na myśli specyfikację I2C i datasheet chipu kamerki. W jednym piszą co magistarala umie a w drugim jak to zaimplementowano w konkretnym scalaku.

A odnosząc się do Twojego opisu: Po START zawsze jest bajt adresu (z bitem kierunku i ACK/NAK z zaadresowanego modułu) więc to co powypisywałeś to jakieś wyobrażenia nie mające nic wspólnego z rzeczywistością. Przykro mi. I2C to nie jest rocket science, ale nie jest to też SPI, gdzie żadne reguły znaczenia przesyłanych bitów nie obowiązują. Tu trzeba zachować kilka prostych zasad i jeśli od strony sprzętu magistrala jest postawiona poprawnie, zadziała na pewno. Do roboty.

----------------------------------------------------------------------------

EDIT: Żebyś miał co czytać do poduszki:

http://www4.cs.umanitoba.ca/~jacky/Teaching/Courses/74.795-LocalVision/ReadingList/ov-sccb.pdf

https://www.voti.nl/docs/OV7670.pdf

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Edytowano Lipiec 4, 2019 przez marek1707

[arasu]

Wracam już po lekturze 🙂 Dalej jednak nie wiem czemu przebieg, który podesłałem w poprzednim poście  miałby być totalnie zły ( poza tym STOP/START, którego tam nie powinno być, zaraz po wysłaniu pierwszego bajtu). Zastanawia mnie też jak powinienem użyć biblioteki Wire, skoro robię to nieprawidłowo.

Tak odnośnie jeszcze podlinkowanych źródeł przez @marek1707 ( za które bardzo dziękuję 🙂 ),  jak  opis samego protokołu i2c był fajny i przejrzysty, tak dokumentacja SCCB jest dla mnie strasznie ciężka do strawienia (mało tam ścisłości jak dla mnie).

Dla przykładu opis odczytu. Podane tam jest że odczyt musi być rozpoczęty cyklem "dwufazowego zapisu" ( to jest ok), po czym następuje cykl "dwufazowego odczytu". I tu pojawia się problem, bo jak przy cyklu zapisu zakładam, że oba bajty są wysyłane przez mastera (Fig. 14) to dla odczytu totalnie nie wiem co tam robi bajt z adresem czyli faza 1 (Fig. 15). Kto wysyła ten ID adres, master czy slave? Jaką powinien mieć wartość? Czy cykl odczytu jest po sekwencji STOP/START, która miałaby nastąpić po dwufazowym cyklu zapisu ?

[marek1707]

Wszystko jest zgodnie z regułami. Wzmiankowany odczyt dajmy na to robisz jak ustawa nakazuje, czyli tak:

• START
• Zapis bajtu adresu modułu z bitem RW=0 (czyli dalsze bajty będą szły od mastera do slave'a) koniecznie potwierdzony bitem ACK=0 ze slave'a - to oznacza, że zaadresowany moduł jest na szynie i żyje. Nawet jeśli nie chciało Ci się napisać kodu obsługującego błędy na I2C (a może być ich sporo różnych), to przynajmniej tutaj tutaj musisz sprawdzić kod błedu oddawany przez funkcję wysłania bajtu adresu, bo dzięki temu wiesz czy nie piszesz "na Berdyczów".
• Zapis bajtu numeru rejestru w module, także potwierdzony bitem ACK=0 przez slave'a (slave mudi potwierdzać odebranie każdego bajtu).
• Teraz są dwie możliwości. Albo robisz (rzadziej) sekwencję zdarzeń "STOP - START" albo (najczęściej) wykonujesz tzw. REPEATED_START czyli specjalne zdarzenie początku nowej ramki bez kończenia poprzedniej. Obie te ścieżki i tak powodują, że automaty I2C wszystkich podłączonych slave'ów (bo przecież wszyscy na bieżąco śledzą stan magistrali) jako ostatnie widzą START a to wymusza na nich potraktowanie najbliższego bajtu jako adresu modułu.
• Zapis bajtu adresu modułu z bitem RW=1 (czyli dalsze bajty będą szły od zaadresowanego slave'a do mastera) jak zwykle koniecznie potwierdzony bitem ACK ze slave'a - to oznacza, że zaadresowany moduł jest na szynie i żyje
• Odczyt bajtu, który jest zawartością wskazanego rejestru w module zakończony wygenerowaniem przez mastera NAK (czyli bit ACK=1). W czasie ":wysysania" bajtów ze slave'a to master musi potwierdzać odebrane bajty i potwierdza każdy przez ACK=0 oprócz ostatniego. Jeśli więcej bajtów nie chce, odpowwiada właśnie NAKiem. Tutaj mamy tylko jeden bajt więc NAK jest od razu w pierwszym odczytanym bajcie.
• STOP

No to tyle. czy to jakoś wyjaśnia mroki?

A co do biblioteki to poczytaj dokumentację i popatrz na kody działających programów. Protokół I2C jest dość ściśle określony a wire jest dość popularne i wiadomo jak i kiedy wołać poszczególne funkcje by działało. Nawet trywialne przykłady wbudowane w IDE  Arduino są pomocne. Znajdź katalog gdzie masz zainstalowaną wire.cpp i obejrzyj ten plik. Popatrz jak zrobili np. requestFrom, bo to właśnie jest adresowany odczyt. Wire jest posadzona na standardowej dla AVRów bibliotece twi.h więc tam się kieruj by zobaczyć operacje niskopoziomowe czyli te od START do STOP. Adresowany odczyt jest czymś więcej - już chyba zdążyłeś się zorientować i dlatego jest implementowany na wyższej warstwie.