Skocz do zawartości

arasu

Użytkownicy
  • Zawartość

    6
  • Rejestracja

  • Ostatnio

Reputacja

1 Neutralna

O arasu

  • Ranga
    2/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Warszawa
  • Języki programowania
    C, Java
  • Zainteresowania
    mikrokontrolery, modele RC
  • Zawód
    Java developer
  1. 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 ?
  2. 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.
  3. 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
  4. Przestawienie jednej zworki na plytce z 00 na 10 pozwoliło na odzyskanie połączenia pomiędzy płytką i ST Link utility( wcześniej przy programowaniu nie musiałem ich przestawiać). Z kodem było wszystko w porządku, nie trzeba nic zmieniać w pliku .cfg, kod wygenerowany przez Cube Mx działa poprawnie. Po wgraniu kodu trzeba wrócić do ustawienia 00 na zworkach i podłączyć płytke przez USB, komputer wtedy rozpoznał płytke i zainstalował co trzeba. Teraz moge wysyłać komendy do płytki przez Putty po kablu USB Temat do zamknięcia
  5. Hej, próbowałem wgrać driver do komunikacji PC<->STM f103c8 przez usb. Projekt wygenerowałem w CubeMX (windows 7) zgodnie z tym poradnikiem: Z tym wyjątkiem, że nie zmieniałem ustawień w pliku .cfg (w filmie 8:16). Przy kompilacji projektu natknąłem się na problem z tworzeniem pliku .hex zamiast .bin w folderze debug projektu. W tym celu w ustawieniach swojego IDE (Eclipse for STM32), w C/C++ Builder>Settings zakładka Build Steps, rubryka post build steps -> Command zamieniłem linijke: arm-none-eabi-objcopy -O ihex "${BuildArtifactFileBaseName}.elf" "${BuildArtifactFileBaseName}.hex" && arm-none-eabi-size "${BuildArtifactFileName}" na arm-none-eabi-objcopy -O binary "${BuildArtifactFileBaseName}.elf" "${BuildArtifactFileBaseName}.bin"; arm-none-eabi-size "${BuildArtifactFileName}" w celu otrzymania pliku .bin do wgrania na płytke. Kod wgrałem przez ST-link utility. Po podłączeniu płytki do komputera przez kabel USB, w menedżerze pojawia mi się jedynie 'device unknown' (wgrywałem virtual com port driver zgodnie z zaleceniami poradnika na Forbot). Ponadto nie moge teraz zmienić programu na płytce ST Link utility nie może się z nią połączyć. Zastanawiam się czy nie jest to związane ze wspomnianymi wyżej ustawieniami w pliku .cfg ( widnieje tam parametr connect under reset, co by mi sugerowało, że to może być to). Moje gorące pytanie do Was - co mogłem zrobić źle?
  6. siemanko, ja również miałbym pytanie odnośnie zestawu arduino uno plus, czy zestaw zawiera tą plastikową skrzynkę( jest widoczna na zdjęciach ale nie widnieje na liście poniżej, a bardzo by się przydała ;D)?
×
×
  • Utwórz nowe...