Skocz do zawartości

Przeszukaj forum

Pokazywanie wyników dla tagów 'STM32F7'.

  • Szukaj wg tagów

    Wpisz tagi, oddzielając przecinkami.
  • Szukaj wg autora

Typ zawartości


Kategorie forum

  • Elektronika i programowanie
    • Elektronika
    • Arduino i ESP
    • Mikrokontrolery
    • Raspberry Pi
    • Inne komputery jednopłytkowe
    • Układy programowalne
    • Programowanie
    • Zasilanie
  • Artykuły, projekty, DIY
    • Artykuły redakcji (blog)
    • Artykuły użytkowników
    • Projekty - DIY
    • Projekty - DIY roboty
    • Projekty - DIY (mini)
    • Projekty - DIY (początkujący)
    • Projekty - DIY w budowie (worklogi)
    • Wiadomości
  • Pozostałe
    • Oprogramowanie CAD
    • Druk 3D
    • Napędy
    • Mechanika
    • Zawody/Konkursy/Wydarzenia
    • Sprzedam/Kupię/Zamienię/Praca
    • Inne
  • Ogólne
    • Ogłoszenia organizacyjne
    • Dyskusje o FORBOT.pl
    • Na luzie

Kategorie

  • Quizy o elektronice
  • Quizy do kursu elektroniki I
  • Quizy do kursu elektroniki II
  • Quizy do kursów Arduino
  • Quizy do kursu STM32L4
  • Quizy do pozostałych kursów

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Rozpocznij

    Koniec


Ostatnia aktualizacja

  • Rozpocznij

    Koniec


Filtruj po ilości...

Data dołączenia

  • Rozpocznij

    Koniec


Grupa


Imię


Strona

Znaleziono 5 wyników

  1. Cześć, ponownie wrócił u mnie temat wysyłania z uC danych z czujników MPU9250 do PC. Poprzednio robiłem to z użyciem funkcji printf i terminala CoolTerm i w przypadku 6 osi (akcelerometr + żyroskop) i szybkości próbkowania 20 Hz nie było problemu. Obecnie potrzebuję przesłać dane z 24 osi (4 akcelerometry i 4 żyroskopy na 4 IMU) z szybkością 500 Hz. No i tutaj printf nie wyrabia. Próbowałem też użyć sprintf oraz funkcję HAL_UART_Transmit, HAL_UART_Transmit_IT, HAL_UART_Transmit_DMA. (Z tą ostatnią mam problem, ponoć jest jakiś kłopot z CubeIDE i serią F7. Pierwsze testy pokazały mi jednak, że IT działa tak samo szybko jak DMA. Jeśli to prawda, to na razie ten problem pomijam. Jeśli jednak będzie potrzebne DMA, to tutaj też będę prosił o pomoc. W STM32F410RB Nucleo działa mi bez zarzutu.) Tutaj jednak przy przesyłaniu 24 wartości typu float czas przesłania danych jest zbyt duży i rzeczywista szybkość próbkowania mi spada. Wpadłem na pomysł, by zamiast danych typu float i funkcji (s)printf przesłać po prostu surowe wartości uint8_t z 2 rejestrów (lub jeszcze lepiej połączone od razu w uint16_t) dla każdej osi. Ale tutaj napotykam na problemy. Po pierwsze - jak wysłać te dane? Kolejno po sobie wartości z każdej osi? Czy jakoś je spakować "do kupy" i zrobić jedną transmisję w każdym przerwaniu zegarowym 500 Hz? Pierwszy pomysł wyglądałby mniej więcej tak (od razu proszę o korektę): int16_t MPU9250_aX_A, MPU9250_aY_A ... MPU9250_gZ_D); HAL_UART_Transmit_IT(&huart3, MPU9250_aX_A, sizeof(MPU9250_aX_A)); HAL_UART_Transmit_IT(&huart3, MPU9250_aY_A, sizeof(MPU9250_aY_A)); HAL_UART_Transmit_IT(&huart3, MPU9250_aZ_A, sizeof(MPU9250_aZ_A)); . . . HAL_UART_Transmit_IT(&huart3, MPU9250_gX_D, sizeof(MPU9250_gX_D)); HAL_UART_Transmit_IT(&huart3, MPU9250_gY_D, sizeof(MPU9250_gY_D)); HAL_UART_Transmit_IT(&huart3, MPU9250_gZ_D, sizeof(MPU9250_gZ_D)); Kolejny problem to odbiór tych danych i ich konwersja do postaci zrozumiałej dla człowieka. Na razie otrzymuję w terminalu coś w stylu: BĽR–ˇÍ.h)B*]+ ,Ş.A,Ş)B+ )BŐń."únôA-0Ŕ,."-0~,ŞˇÍÉČÚą.hŐńçÖ~´)Uź˝..áR–)BBĽŐńĺ.Ŕ,çÖ~..ú‰‡.˙,Ş`“+ á.}.ÉČ­mnô[`¦“.űëm.ś '—..˝.††`J.ĹV-0|<’ ĺ.D.›@úí.÷hú..^[.˝J„–÷h‰‡A+ .Š.‰‡~UźçÖ`“Ü÷˛h0`“JahUź©;BĽëmÉČÚą.˙á.ŠUź8\‰‡‰‡éjĺ.Aöš)B+ Korzystam z STM32F746ZG Nucleo, STM32CubeIDE 1.10.1, MCU Package 1.17.0. Na razie dane przesyłam z Nucleo poprzez USB, docelowo będzie to nowy układ z rdzeniem STM32F756VGT6 i komunikacja poprzez BT lub WiFi. 4 czujniki mam podłączone do 2 magistrali I2C. Proszę o wszelkie porady i pomysły, jak szybko przesłać wszystkie potrzebne dane i je poprawnie odczytać w PC.
  2. Cześć, od dłuższego czasu pracuję nad projektem o poniższych założeniach: - odczyt z 4 czujników IMU (24 osie) - szybkość akwizycji - 400-500 pomiarów na sekundę - mikrokontroler z serii F7 (wymogi późniejszej rozbudowy) - zapis na kartę SD lub bezprzewodowe przesłanie danych. Wpis ten jest tak naprawdę kontynuacją wątku STM32 UART wysyłanie danych typu uint16_t. Okazało się, że pomysł z bezprzewodowym przesyłaniem danych po UART jest trudny/nierealny do zrealizowania, więc postanowiłem wykorzystać zapis na kartę pamięci. Było z tym mnóstwo problemów (z zainteresowanymi chętnie się podzielę), ale koniec końców udało mi się zrealizować zapis w 4-bitowym trybie SDMMC. Obecnie zmagam się z problemem odpowiedniej szybkości pobierania danych z czterech MPU9250 podłączonych do dwóch linii I2C i ich zapisem na SD. Realizuję to w przerwaniu timera, które odpowiada za stałą szybkość akwizycji. Ustawiając zegary na maksymalne wartości pozwalające na skuteczny zapis na SD, podczas 1-minutowych testów z fs=400 Hz całkowity czas operacji wynosi ok. 65 sekund. Np. dla 100 Hz jest to dokładnie 60 sekund. Zatem program "nie wyrabia" owych 400 Hz. Wpadłem na pomysł, żeby czujniki podłączyć do 4 osobnych magistrali I2C i używać trybu IT, ale mój procesor ma tylko 1 pin (PC9) odpowiedzialny zarówno za I2C3_SDA, jak i MMC1_D1, czyli w moim przypadku nie da rady go użyć. Musiałbym wykorzystać wersję przynajmniej 176-pinową, a tych nie znalazłem dostępnych w Polsce. Póki co, aby nieco przyśpieszyć akwizycję, zastosowałem pewien (dziwny) trick i z każdej I2C jeden czujnik obsługuję trybem blokującym, a drugi z użyciem przerwania. Poniżej fragment kodu: uint8_t my_string[4*24+1]; //bez spacji void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM10) //przerwanie pochodzi od timera 10 { HAL_I2C_Mem_Read(&hi2c1, MPU9250_ACC_ADDRESS_A, MPU9250_ACCEL_XOUT_H, 1, MPU9250_Data_A, 14, 50); //14 pomiarów od razu HAL_I2C_Mem_Read_IT(&hi2c1, MPU9250_ACC_ADDRESS_B, MPU9250_ACCEL_XOUT_H, 1, MPU9250_Data_B, 14); //14 pomiarów od razu HAL_I2C_Mem_Read(&hi2c2, MPU9250_ACC_ADDRESS_C, MPU9250_ACCEL_XOUT_H, 1, MPU9250_Data_C, 14, 50); //14 pomiarów od razu HAL_I2C_Mem_Read_IT(&hi2c2, MPU9250_ACC_ADDRESS_D, MPU9250_ACCEL_XOUT_H, 1, MPU9250_Data_D, 14); //14 pomiarów od razu timer_tim10++; if (timer_tim10 <= 6*4000) { sprintf(my_string, "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x" "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x" "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x" "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x\n", MPU9250_Data_A[0],MPU9250_Data_A[1],MPU9250_Data_A[2],MPU9250_Data_A[3],MPU9250_Data_A[4],MPU9250_Data_A[5],MPU9250_Data_A[8],MPU9250_Data_A[9],MPU9250_Data_A[10],MPU9250_Data_A[11],MPU9250_Data_A[12],MPU9250_Data_A[13], MPU9250_Data_B[0],MPU9250_Data_B[1],MPU9250_Data_B[2],MPU9250_Data_B[3],MPU9250_Data_B[4],MPU9250_Data_B[5],MPU9250_Data_B[8],MPU9250_Data_B[9],MPU9250_Data_B[10],MPU9250_Data_B[11],MPU9250_Data_B[12],MPU9250_Data_B[13], MPU9250_Data_C[0],MPU9250_Data_C[1],MPU9250_Data_C[2],MPU9250_Data_C[3],MPU9250_Data_C[4],MPU9250_Data_C[5],MPU9250_Data_C[8],MPU9250_Data_C[9],MPU9250_Data_C[10],MPU9250_Data_C[11],MPU9250_Data_C[12],MPU9250_Data_C[13], MPU9250_Data_D[0],MPU9250_Data_D[1],MPU9250_Data_D[2],MPU9250_Data_D[3],MPU9250_Data_D[4],MPU9250_Data_D[5],MPU9250_Data_D[8],MPU9250_Data_D[9],MPU9250_Data_D[10],MPU9250_Data_D[11],MPU9250_Data_D[12],MPU9250_Data_D[13]); if(f_lseek(&fil, f_size(&fil)) != HAL_OK) printf("f_lseek ERROR\n"); if(f_write(&fil, my_string, sizeof(my_string), &numread) != HAL_OK) printf("f_write ERROR\n"); }else if (timer_tim10 == 6*4000+1) { close_file(); unmount_sd(); printf("done\n"); } } } Jak widać (mam nadzieję), czujnik A i B znajdują się na I2C1, C i D na I2C2. B i D odczytuję z użyciem przerwania (IT) po zakończeniu odczytu odpowiednio A i C. Jak mogę to zrobić szybciej? Domyślam się, że DMA mogłoby pomóc, ale kompletnie nie umiem tego zrobić. Zwykła zamiana _IT na _DMA nie działa. W sieci znalazłem mnóstwo wątków z problemami użycia DMA na F7, ale bez skutecznych (w moim przypadku) rozwiązań. Proszę tu o Waszą pomoc. A może mogę jakoś przyśpieszyć zapis na kartę pamięci? Czy tutaj można jakoś zaprząc do pacy DMA lub inny szybki mechanizm? Wydaje mi się też, że funkcja sprintf zajmuje sporo czasu. Usunąłem z niej wszystkie zbędne znaki i przesyłam jedynie po 2 na każdy rejestr oraz znak nowej linii po zapisaniu wszystkich potrzebnych rejestrów (w liczbie 48), czyli w sumie 97 znaków w każdej iteracji. Czy są jakieś szybsze alternatywy? Trochę się rozpisałem. Temat jest wielowątkowy, generuje różne problemy i zaskakujące niespodzianki. Starałem się zawrzeć tylko najważniejsze informacje. Testy przeprowadzam na Nucleo F746. Docelowo chciałem użyć 100-pinowego F756VGT6, ale może być inny (dostępny od ręki) z serii F7. STM32CubeIDE 1.10.1 MCU Package 1.17.0
  3. Cześć, próbuje uruchomić układ z akcelerometrem LSM303D (kurs) na płytce nucleo-f7, niestety w tej generacji nie ma już dostępnej biblioteki "STM32F10x Standard Peripherals Library". Aktualnie korzystam z biblioteki HAL. Czy jest jakiś dobry sposób aby przerobić ten kod pod generacje F7? Czy jest może już napisana jakaś biblioteka tego akcelerometru? Czy jest może jakiś odpowiednik "Standard Peripherals Library" dla stm32f7?
  4. Potrzebowałem zapisać zmienną do pamięci FALSH gdy będzie zanikało zasilanie. W tym celu w konfiguratorze w zakładce System Core/NVIC ustawiłem przerwanie PVD kontrolera napięcia zasilania procesora. W wyniku czego w main.c pojawiło się przerwanie: static void MX_NVIC_Init(void) { /* PVD_IRQn interrupt configuration */ HAL_NVIC_SetPriority(PVD_IRQn, 8, 0); HAL_NVIC_EnableIRQ(PVD_IRQn); } Aby odczytać uprzednio zapisaną wartość zmiennej dodałem po inicjacji przerwania: total_time = *(__uint32_t*) ADD_FLASH; // odczytanie z FLASH całkowitego czasu pracy Napisałem trzy funkcje: static void PVD_NVIC_Init(void) { PWR_PVDTypeDef sConfigPVD; sConfigPVD.PVDLevel = PWR_PVDLEVEL_7; sConfigPVD.Mode = PWR_PVD_MODE_IT_RISING; HAL_PWR_ConfigPVD(&sConfigPVD); HAL_PWR_EnablePVD(); } void HAL_PWR_PVDCallback(void) { if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, ADD_FLASH, total_time) == HAL_OK) HAL_FLASH_Lock(); } void FLASH_Erase(void) { EraseInitStruct.TypeErase = FLASH_TYPEERASE_SECTORS; EraseInitStruct.VoltageRange = FLASH_VOLTAGE_RANGE_3; EraseInitStruct.Sector = FLASH_SECTOR_7; EraseInitStruct.NbSectors = 1; HAL_FLASH_Unlock(); if (HAL_FLASHEx_Erase(&EraseInitStruct, &SECTORError) == HAL_OK) ; } Konfiguracji PVD, wywołania od PVD gdy napięcie zasilające zanika oraz wymazanie sektora w pamięci FLASH. Ponieważ korzystałem z FREERTOS umieściłem przed wejściem w pętlę: void StartTask02(void *argument) { /* USER CODE BEGIN StartTask02 */ PVD_NVIC_Init(); HAL_Delay(50); FLASH_Erase(); /* Infinite loop */ for (;;) { osDelay(1) } /* USER CODE END StartTask02 */ } Powoduje to skasowanie i przygotowanie FLASH do zapisu w chwili wywołania przerwania przy zaniku napięcia. Napięcie wygenerowania przerwania ustawiłem na 3.0 V w przywołanej już funkcji konfiguracji. To działa! Andrzej
  5. Witam, Uruchomiłem przykładowy program z STM32Cube_FW_F7_V1.15.0, który steruje wyświetlaczem przez interfejs DSI w trybie Video. Mikrokontroler przechowuje obraz w zewnętrznej pamięci sterowanej przez kontroler FMC. Dsi współpracuje z LTDC, który po prostu generuje sygnał RGB oraz sygnały synchronizujące H-sync i V-sync i tą część w większości rozumiem i ogólnie mi to działa. Nie rozumiem tylko, o co chodzi z tym kontrolerem FMC, ponieważ zapis do tej pamięci powoduje wyświetlenie obrazu. Rozumiem, że wyświetlacz jest w trybie odświeżania i jak zmieni się obraz no to od razu się pokazuję. Tylko, że jaki interfejs odpowiada za przesłanie obrazu z pamięci zewnętrznej do wyświetlacza ?? Sama pamięć nie ma fizycznego połączenia z LCD tak jak na schemacie w załączniku: Myślałem, że w tle działa DMA, które przesyła dane z pamięci do DSI ale takiej konfiguracji również nie ma. Ogólnie chciałbym po prostu użyć DSI i LTDC do kontroli wyświetlacza bez kontrolera FMC, potrafię skonfigurować LCD i widzę, że LCD reaguje, podświetlenie itp. ale nie wiem jak przesłać obraz. Mogę dodać zdjęcie konfiguracji lub przesłać cały program, jeżeli ma ktoś dostęp do tego modułu "stm32f769-discovery". Pozdrawiam Adrian
×
×
  • 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.