Skocz do zawartości

arasu

Użytkownicy
  • Zawartość

    8
  • Rejestracja

  • Ostatnio

Reputacja

1 Neutralna

O arasu

  • Ranga
    2/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Warszawa
  • Języki programowania
    C, Java, Python
  • Zainteresowania
    mikrokontrolery, modele RC
  • Zawód
    web application developer
  1. Dzięki atMegaTona za odpowiedź. Aktualnie mcu zajmuje się tylko i wyłącznie zapisem całej ramki do ramu a następnie wysłaniem jej do PC. Nic więcej się nie dzieje, także nie ma żadnych przerwań które by robiły tu problemy. Zajme się teraz konfiguracją zegara w rejestrach, może to coś pomoże. Dodatkowo myśle że dodam do kodu logike, dzięki której PC będzie odpytywał STM o konkretne ramki i potwierdzał otrzymanie prawidłowej ramki aż do uzyskania całkowitego obrazu. Na tą chwilę mam ustawiony obraz z paskami do debugowania i widać że coś jest nie halo bo pixele dla konkretnego pasa się zmieniają (te czarne paski poprzeczne to brakujące linie, które nie dotarły z stm do pc).
  2. Cześć, po ponad półrocznej przerwie kontynuuje zmagania z z kamerką OV7675 z użyciem płytki Nucleo z stm32f446RE. DCMI ani DMA jeszcze nie udało mi się uruchomić ale na swój AVR'owy sposób jestem w stanie UARTem (baud 2M) przesłać w grayscale wartości pixeli z stm32 do apki w Python na moim PC. Po wygenerowaniu obraz jest akceptowalny, ale daleko mu do tego co widziałem na youtube, gdzie obraz nie dość że był czysty to jeszcze przsyłany na żywo( u mnie wygenerowanie zdjęcia przy 5 sekundach to jest dość szybko ^^). Problem wygląda tak: przesyłane dane a dokładniej linijki ( pixele przesyłam rzędami: [dane][index linijki] ) są często zlepkiem dwóch linijek, przez to rozmiar linijki często jest dwukrotnie większy niż to jest dla prawidłowego pakietu. Wydaje mi się że problem jest po stronie Pythona/Windowsa, który nie radzi sobie z taką ilością danych i gdy się gubi to skleja mi pakiety, chociaż dokumentacja PySerial mówi o obsłudze jeszcze większych baudrate. Podczas przeszukiwania internetu natknąłem się też na informacje że czasem taktowanie kamerki zegarem z MCU może powodować problemy i potrzebne jest ustawianie rejestrów w kamerce w celu przeskalowania zegara co powoduje jej poprawne działanie. Może miał ktoś podobny problem? Co myślicie?
  3. 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 ?
  4. 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.
  5. 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
  6. 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
  7. 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?
  8. 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...