Skocz do zawartości

Wloczykij555

Użytkownicy
  • Zawartość

    16
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

Wloczykij555 zajął 1. miejsce w rankingu.
Data osiągnięcia: 28 maja.

Treści użytkownika Wloczykij555 zdobyły tego dnia najwięcej polubień!

Reputacja

5 Neutralna

O Wloczykij555

  • Ranga
    2/10

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. @szymonw @H1M4W4R1 Dzięki za odpowiedzi, faktycznie mam przekreślone usb przy wyborze UART6. Co do szybkości transmisji to nie jest mi ona potrzebna bo buduję sobie raptem dalmierz wielofunkcyjny więc czasu na pomiar jest bardzo dużo Luna to może trochę overkill dla takiej pierdoły ale zależało mi na punktowym pomiarze i jakimkolwiek sensownym zasięgu. Co więcej, UARTA już ogarnąłem i spiąłem pomiar z wyświetlaczem więc jest git.
  2. Dobra, chyba ogarnąłem ale nie do końca wiem dlaczego Zmieniłem UART6 na UART1 i wygląda na to, że działa. Płytkę (BlackPill) zasilam na razie z kablem USB z ładowarki a w dokumentacji wyczytałem, że piny RX i TX z UART6 są jakoś "podpięte" pod linie danych interfejsu USB. Niestety na USB się na ten moment nie znam i nie wiem czy taki konflikt ma prawo mieć miejsce skoro usb używam tylko jako zasilania więc może ktoś w temacie zechce coś na ten temat powiedzieć.
  3. Usiłuję pożenić TF-Lunę z F401CCU6 po UART i już niestety kończą mi się pomysły. W fabrycznej konfiguracji czujnik nadaje ramkę za ramką z częstotliwością 100Hz. Format ramki jak poniżej. Na Arduino działa bez zarzutu - zarówno odbieranie danych jak i zmiana ustawień poprzez wysyłanie komend (np. zmiana częstotliwości) a na STM32 nie mogę odebrać nawet jednego bajtu (wysyłanie chyba działa ale nie mam jak tego zweryfikować). Wklejam obecny kod programu przy czym próbowałem różnych podejść (z DMA włącznie). Debuggerem wyśledziłem, że funkcja UAR_Receive wywala po prostu
  4. @Elvis Czyli jednak mogłem doczytać do Twoje tutoriale do końca, oszczędziłbym sobie straconych nerwów
  5. @_LM_ Uff, działa wyśmienicie ale zajęło mi to dwa długie wieczory... Okazuje się, że CubeIDE generuje inicjalizację peryferiów w niewłaściwej kolejności (przynajmniej, jeżeli chodzi o DMA). Kod wygenerowany przez program: /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_SPI1_Init(); MX_DMA_Init(); MX_TIM2_Init(); Powinno być: /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_DMA_Init(); MX_SPI1_Init(); MX_TIM2_Init(); Czyli DMA musi być przed inicjalizacją SPI. W przeciwnym razie, DMA nie będzie przekazywać danych do bu
  6. O widzisz, muszę temat zgłębić Też właśnie wpadłem na taki pomysł, jak nic innego nie pomoże to pójdę w tym kierunku ;)
  7. Kombinuję nad przyśpieszeniem pracy wyświetlacza (opartego na sterowniku ST7735S) a konkretnie funkcji "czyszczenia" ekranu poprzez wypełnienie jednolitym kolorem. Punktem wyjścia były metody przedstawione w kursach dotyczących STM32L4 (czyli wysyłanie dwubajtowego koloru "na dwa razy") ale udało mi się to trochę usprawnić, poprzez deinicjalizację i ponowną inicjalizację SPI ze zmienioną długością ramki (8 -> 16 bitów). Choć działa to 2x szybciej to wciąż jest bieda bo muszę dla każdego piksela osobno wywoływać HAL_SPI_Transmit(). LCD_Set_Window(0, 0, 160, 128); //Ustawi
  8. Takie głupie pytanie - mógłby mi ktoś nieco dokładniej wyjaśnić jaka jest rola funkcji: HAL_ADC_PollForConversion Chodzi o to, że w programie celowo ją sobie wykomentowałem i pomiar... nadal działa (oczywiście mierząc tylko pojedynczy kanał). Czy nie jest tak, że ma ona faktycznie zastosowanie dopiero przy kilku mierzonych kanałach aby oddzielić od siebie pomiary?
  9. Mam mały problem kodem konfiguracji timera generowanym przez CubeMX (przy czym przerabiam kurs na F103RB) Otóż program nie generuje mi funkcji: HAL_NVIC_EnableIRQ(TIM2_IRQn); mimo, że ustawiam przerwanie od timera oraz jego priorytet. Przy ustawianiu przerwań z GPIO nie ma tego problemu a tutaj muszę tą funkcję ręcznie wklejać. Nie jest to może duży problem, raczej niedogodność ale czy zna ktoś przyczynę? Może czegoś nie ustawiam do końca?
  10. Mam pytanie odnośnie baud rate w transmisji asynchronicznej, na które nie znalazłem dotychczas odpowiedzi a które nie daje mi spokoju. Skąd urządzenie odbiorcze zna baud rate, z jakim powinien się komunikować? Czy np. czujniki i inne peryferia mają ustaloną przez producenta, sztywną wartość którą należy skonfigurować na MCU czy może przed rozpoczęciem transmisji kontroler informuje adresata, z jaką prędkością będzie nadawał? W przypadku Arduinowego monitora transmisji szeregowej ręcznie wybieramy z jakim baud ratem mają być odczytywane dane ale jak to wygląda w przypadku zwykłych urz
  11. Po ~2 latach od zakupu zestawu zabieram się w końcu za kurs xD Mam tylko pytanie - czy są duże różnice w programowaniu F103RB oraz L4? Te drugie płytki nie są obecnie dostępne w sprzedaży ale w kursie im poświęconym są ciekawe poruszone ciekawe tematy, które chciałbym sobie zrealizować (elementy poboczne oczywiście posiadam). Innymi słowy - czy dam radę zrealizować kurs L4 na płytce F103RB?
  12. Dzięki! Nowa wiedza wpadła Ok, chyba mam odpowiedź a brzmi ona - ten czujnik po prostu ssie Dodałem delay() na końcu programu oraz wydłużyłem odstęp czasowy pomiędzy pomiarami i zaczęło trybić. Wygląda na to, że przy tak krótkich czasach załączania i wyłączania ten czujnik się po prostu nie wyrabiał. Na marginesie, LCD też do takich pomiarów się nie nadaje, bo przy szybkich zmianach wartości robi się nieczytelny (zbyt duża bezwładność pikseli). Poniżej finalny kod. Dziękuję za odzew #define trig 5 #define echo 6 #include <LiquidCrystal.h> LiquidCrystal lcd
  13. Niestety delay(30) nie pomógł. Co do zmiennych, to pierwotnie wszystkie były typu int i działo się dokładnie to samo. Chciałem uzyskać pomiar z dokładnością do 2 miejsc po przecinku więc przemianowałem wszystko na float. Co ciekawe, również wynik z pulsein też musi być float bo inaczej po podzieleniu przez 58 zaokrągla mi końcowy wynik funkcji ("odo") do liczby całkowitej (nawet jeśli tą ostatnią zmienną zadeklarowałem jako float). Ogólnie wszystko wydaje się być ok, wartości na LCD są wyświetlane w oczekiwanym formacie, tyle że są nieprawidłowe. EDIT Zmodyfi
  14. Cześć, Usiłuję wyrzeźbić prosty prędkościomierz na bazie HC-SR04 ale nie mogę zmusić go do działania. Algorytm jest oczywisty: wywołanie funkcji mierzącej odległość odczekanie krótkiej chwili ponowny pomiar Obliczenie różnicy obydwu wartości Przeliczenie na prędkość (m/s). Problem polega na tym, że nie udaje mi dokonać dwóch pomiarów w jednej pętli. Zawsze jeden z pomiarów jest prawidłowy a drugi wynosi niezmiennie 0 (zazwyczaj ten drugi ale po wydłużeniu czasu odstępu czasowego drugi jest ok a pierwszy pokazuje 0). Próbowałem kombinować z odstę
  15. Dziękuję za zainteresowanie tematem. Może doprecyzuje zatem - jestem po Automatyce i Robotyce (już parę lat) więc ogólnie temat elektroniki jak i uC nie jest mi obcy. Mam problem jedynie w skladni programu, generalnie z językiem C bo go po prostu nie znam czyli. Z tego co widzę kurs Arduino tłumaczy właśnie składnie C oraz takie dość powszechne zaatosowania uC jak sterowanie silniczkami. Kurs STM32 skupia się na nieco bardziej specyficznych przykładach (a może to tylko moje mylne wrażenie) oraz wychodzi z założenia że C jest już opanowane.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.