Skocz do zawartości

arasu

Użytkownicy
  • Zawartość

    12
  • 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. Czesc, udalo mi sie ostatnio napisac na blue pillu prosty voice recorder, ale przy odtwarzaniu nagrania slyszalem mase stukow (mimo to glos jest calkiem rozpoznawalny). Myslalem ze to moze byc problem z zasilaniem czy cos, ale zrzucilem sobie nagranie na program ala audacity i podejrzenie o stuki padlo na SPI. Jezeli chodzi o kod to uzywam ADC z czestotliwoscia 16kHz i wypelniam bufor o rozmiarze 512. Jak bufor jest pelny robie zapis do karty SD za pomoca biblioteki FATFS( ktorej nie jestem pewien czy uzywam poprawnie), wszystko wygenerowane w CUBEMX i zbudowane na plytce stykowej. x = ~32ms ; y = ~64ms | 512/16kHz = 0.032 s = 32 ms Nagrałem dzwiek fali sinus z glosnikow i zauwazylem ze te zaklocenia troche oddaja to co sie dzieje u mnie w kodzie, tam gdzie jest 1 na SS wyglada na to ze to jest moment gdy robie f_write do SD, a tam gdzie jest 2, dzieje sie znow f_write z kolejnym pelnym buforem + f_sync, ktory jak rozumiem robi flush danych (danych zapisanych wczesniej za pomoca f_write() ) do karty. I teraz pytanko o FATFS. Z tego co probowalem wyczytac z dokumentacji (http://elm-chan.org/fsw/ff/doc/write.html), for i wydebugowac, ta biblioteka tworzy w RAM mcu takie wirtualne odzwierciedlenie tego co jest w pliku na karcie SD w postaci struktury FILE, i teraz jak robie f_write(bufor), to to sie nie przeklada na fizyczny zapis danych do karty za pomoca SPI, tylko na przeniesienie mojego bufora do bufora struktury FILE (czyli kopia z RAM do RAM), a fizyczny zapis do SD nastepuje dopiero po wywolaniu funkcji f_sync(). Wtedy to co jest w FILE.data[] leci po SPI do karty. Dobrze to rozumiem? Czy moze f_sync() uzywac co 10 albo 100 zapis zamiast co 2? Z analizy obrazka z drugiej strony by wynikalo ze jezeli to zeczywiscie SPI tam tak miesza, to f_write() jednak dokonuje zapisu po SPI do karty SD, tylko wtedy nie rozumiem czemu w 2 dzieje sie taki meksyk, f_sync() nie powinno miec nic do wypchniecia i zaklocenia nie powinny tam trwac dwa razy to co sie dzieje w 1. Ostatecznie pytanko, czy da sie te zaklocenia ogolnie jakos wyeliminowac sprzetowo? Piąteczka
  2. Ja bym dorzucil HAL_ADC_Start_IT(&hadc1); na koniec przerwania ADC, jak to nic nie da to bym sprawdzal dalej przez debuger co sie dzieje na rejestrach ADC. Ewentualnie sprawdzilbym jeszcze co robi ta flaga hadc1.Init.EOCSelection = ADC_EOC_SINGLE_CONV; z F4 ostatnio malo co sie bawilem, takze nie pamientam co za ficzery ma tamtejszy ADC.
  3. Dzieki za odpowiedz, okazalo sie ze debuger w STM Cube ide nie zatrzymuje timerow i wartosci rejestru docelowego DMA nie jest aktualna na zlapanym breakpoint. Druga sprawa, okazalo sie ze przy podlaczeniu DMA z ADC przerwanie HAL_ADC_ConvCpltCallback juz nie bedzie obslugiwac zakonczenia pojedynczej konwersji, a zakonczenie wypelniania calego bufora docelowego. Ale pojawilo sie u mnie kolejne pytanie z DMA, chcialbym zeby moj docelowy bufor byl 8bitowy, dlatego ADC chce miec z przesunieciem danych do lewej strony [ dddd dddd dddd xxxx], dokumentacja sugeruje ze tak sie nie da, ale moze ja czegos nie doczytalem albo sa jakies sposoby na to? Chcialbym zeby DMA juz przygotowalo mi odrazu gotowy bufor do wyslania przez SPI, bez potrzeby procesowania go przez uC.
  4. Czesc, Od kilku tygodni probuje napisac na stm32f103 rejestrator glosu z zapisem na karte SD. Chce do tego uzyc ADC z triggerem od TIM3, zeby probkowac z odpowiednia czestotliwoscia, i DMA(potrzebuje sie tego nauczyc pod katem obslugi kamerki CMOS). Brudna robote z generowaniem kodu wykonal za mnie Cube IDE. Poza tym stworzylem dwa bufory na dane, tak zeby nimi zonglowac pomiedzy ADC i DMA uint8_t buf[2][BUFF_SIZE]; uint8_t buf[2][BUFF_SIZE]; Teraz w main odpalam DMA razem z ADC i mowie gdzie maja wszystkie dane ladowac i ile tego ma tam byc ( tam wyzej BUFF_SIZE ma 512 byte) HAL_ADC_Start_DMA(&hadc1, (uint8_t*)buf, 1024); Teraz mam 3 callbacki, ktore sprawdzam debugerem i tutaj dzieje sie cos czego nie rozumiem. void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc){ void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc){ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim){ Tutaj jeszcze musze powiedziec, poza pierwszym timerem TIM3, ktory uzywam do odpalanie konwersji ADC, uzywam tez osobnego TIM4 do sprawdzania ile mam zrobionych konwersji dla danego okresu czasu. Ustawilem TIM3 na 8khz i TIM4 na 100hz, co przy przepelnieniu TIM4 powinno dac (albo moze chcialbym zeby dalo) 80 konwersji ADC, czyli 80 wartosci w buf[0], ale tak niestety nie jest. Przy ustawieniu breakpoint na HAL_ADC_ConvCpltCallback i zlapaniu tam programu drugi raz mam juz zapelnione obie tablice buf[0] i buf[1], co mnie dziwi bo myslalem ze DMA bedzie czekac na kazda konwersje ADC i po kazdej z tych konwersji bedzie kopiowac pojedyncza wartosc do wskazanej tablicy. Czy jest cos zle w tym co pokazalem, czy moze seria F1 nie jest zdolna do tego co bym chcial? Widzialem w poradnikach do serii F4 dla ADC pole DMA Continuous Requests, dla F1 tego niestety nie widze i zastanawia mnie czy to nie jest ten moj brakujacy puzzel. Zalaczam screeny z konfiguracja cubemx. Pozdrawiam
  5. 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).
  6. 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?
  7. 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 ?
  8. 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.
  9. 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
  10. 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
  11. 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?
  12. 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...