Przeszukaj forum

Jak szybko przygotować STM32F746G-DISCO do pracy. Do zainteresowanych dodam Video.STM32.pdf

Cześć, Zacząłem naukę programowania STM32 na podstawie kursu dla STM32F101 tylko używam STM32F303. Niestety pojawił się problem przy konfiguracji UART2. Poniżej załączam kod programu. /** ****************************************************************************** * @file main.c * @author Ac6 * @version V1.0 * @date 01-December-2013 * @brief Default main function. ****************************************************************************** */ #include <string.h> #include "stm32f3xx.h" UART_HandleTypeDef uart; void send_string(char* s) { HAL_UART_Transmit(&uart, (uint8_t*)s, strlen(s), 1000); } int main(void) { SystemCoreClock = 8000000; HAL_Init(); __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_USART2_CLK_ENABLE(); GPIO_InitTypeDef gpio; gpio.Pin = GPIO_PIN_2 | GPIO_PIN_3; gpio.Mode = GPIO_MODE_AF_PP; gpio.Pull = GPIO_NOPULL; gpio.Speed = GPIO_SPEED_FREQ_HIGH; gpio.Alternate = GPIO_AF7_USART2; HAL_GPIO_Init(GPIOA, &gpio); UART_HandleTypeDef uart; uart.Instance = USART2; uart.Init.BaudRate = 38400; uart.Init.WordLength = UART_WORDLENGTH_8B; uart.Init.Parity = UART_PARITY_NONE; uart.Init.StopBits = UART_STOPBITS_1; uart.Init.HwFlowCtl = UART_HWCONTROL_NONE; uart.Init.OverSampling = UART_OVERSAMPLING_16; uart.Init.Mode = UART_MODE_TX_RX; HAL_UART_Init(&uart); while(1) { send_string("Hello World\r\n"); HAL_Delay(100); } } Czy ktoś mógłby wskazać gdzie zrobiłem błąd? Pozdrawiam.

Hej, próbuję przerobić kurs STM32 F1 HAL i na samym początku pojawiły się problemy, a mianowicie od kilku dni próbuję zrobić zadanie 4.1, jednak wszystkie próby kończą się niepowodzeniem. Ma może ktoś zrobione to zadanie i chciałby się nim podzielić oraz sposobem jego rozwiązania? Poniżej mój kod. Z góry dziękuję! #include "stm32f1xx.h" int main(void) { SystemCoreClock = 8000000; // taktowanie 8Mhz HAL_Init(); __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_GPIOC_CLK_ENABLE(); GPIO_InitTypeDef gpio; // obiekt gpio będący konfiguracją portów GPIO gpio.Pin = GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4| GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7|GPIO_PIN_8|GPIO_PIN_9; gpio.Mode = GPIO_MODE_IT_RISING; gpio.Pull = GPIO_PULLUP; // rezystory podciągające są wyłączone gpio.Speed = GPIO_SPEED_FREQ_LOW; // wystarczą nieskie częstotliwości przełączania HAL_GPIO_Init(GPIOC, &gpio); // inicjalizacja modułu GPIOC gpio.Pin = GPIO_PIN_13; // konfigurujemy pin 13 gpio.Mode = GPIO_MODE_INPUT; // jako wejście gpio.Pull = GPIO_PULLUP; // włączamy rezystor podciągający HAL_GPIO_Init(GPIOC, &gpio); // port GPIOC while (1) { if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET) { uint32_t led = 0; HAL_GPIO_WritePin(GPIOC, 1 << led, GPIO_PIN_SET); //włącz diode HAL_Delay(150); HAL_GPIO_WritePin(GPIOC, 1 << led, GPIO_PIN_RESET); //wyłącz diode if (++led >= 10) { // przejdz do nastepnej led = 0; } else { uint32_t led = 10; HAL_GPIO_WritePin(GPIOC, 1 << led, GPIO_PIN_SET); //włącz diode HAL_Delay(150); HAL_GPIO_WritePin(GPIOC, 1 << led, GPIO_PIN_RESET); //wyłącz diode if (--led >= 10) { // przejdz do nastepnej led = 10; } } } } }

Cześć, Mam dziwny problem którego nie mogę rozwiązać od dłuższego czasu. Potrzebuje wysłać cyklicznie do raspberry PI 4 pakiet UDP z stm32(mam nucle f207zg oraz f767zi, na obu jest to samo). Używam lwip 2.x. Moja funkcja została przerobiona z przykładu UDPechoserver i jest wywoływana w cyklicznym przerwaniu wygląda tak: void UDPSendString(void) { struct udp_pcb *upcb; struct pbuf *p; upcb=udp_new(); /*assign destination IP address */ ip_addr_t ipDest; IP4_ADDR(&ipDest, 192, 168, 0, 4); char buf[bufSize]; int size; err_t err; if (upcb) { /* Bind the upcb to the UDP_PORT port */ /* Using IP_ADDR_ANY allow the upcb to be used by any local interface */ err = udp_bind(upcb, IP_ADDR_ANY, 0); if(err == ERR_OK) { size = snprintf(buf, bufSize, "B value=500\r\n"); p=pbuf_alloc(PBUF_TRANSPORT,size, PBUF_RAM); pbuf_take(p, buf, size); /* Connect to the remote client */ udp_connect(upcb, &ipDest, 8089); /* Tell the client that we have accepted it */ udp_send(upcb, p); /* free the UDP connection, so we can accept new clients */ udp_disconnect(upcb); } } // /* Free the p buffer */ pbuf_free(p); udp_remove(upcb); } Dziwne jest to, że jeżeli w adresie ip podam adres mojego PC na windows to w wiresharku widzę, że wszystko jest ok i pakiety są cyklicznie wysyłane. Natomiast gdy zmienię adres na raspberry to jakby nic nie było wysyłane. Idąc dalej... Za pomocą konsoli w raspberry jestem w stanie wysłać pakiet do pc a do stm już nie. Dziwne jest to, że wireshark nie widzi żadnych pakietów pomiędzy stm a raspberry. Nawet ping który jest wysyłany z raspberry do stm jest niewidoczny pomimo tego, że stm odpowiada. Dodam, że wszystkie urządzenia są podłączone do jednego switcha. Gdzie mogę szukać problemu? Będę wdzięczny za wszystkie sugestie.

Siema, zbudowałem sobie takiego robota balansującego: i od miesiąca próbuję go zmusić do balansowania, a ten mnie nie słucha. MPU6050 -> filtr kalmana -> pid(na filmiku sam człon PD). Sterowanie wychyleniem wywoływane w w przerwaniu co ok 10 ms. I teraz moje pytanie : Czy kaszanię coś programowo, regulacyjnie, Czy skaszaniłem coś mechanicznie ? Tu podgląd z STMStudio ... robot.zip

Jestem na lekcji 3 z kursu STM32 F1 HAL i próbując pobrać sterowniki z linku podanego w kursie na stronie producenta po kliknięciu w link z maila wyskakuje mi error 403. Miał może ktoś podobny problem? Z Góry dzięki za odpowiedź.

Cześć, na początek chciałbym się przywitać. Nie pamiętam czy pisałem coś na forum, a jeżeli tak to musiało być bardzo dawno. Zaprojektowałem urządzenie serwera HTTP na bazie stm32f207 i DP83848 (PHY). Oprogramowanie wygenerowałem z użyciem najnowszego CubeMX oraz wersji biblioteki dla procesora stm32f207 v1.9. Wykorzystałem LWIP jako stos TCP/IP oraz FreeRtos-a jako system, komunikacja TCP za pomocą netconn. Wygenerowany szablon zmodyfikowałem na wzór dostarczonego przez ST. Utworzyłem wątek http_server_netconn_thread(), w którym oczekuję na informacje ze strony. Nic odkrywczego. Pierwsza linia to utworzenie nowego wątku a poniżej jest sam wątek. httpTaskHandle = sys_thread_new("HTTP", http_server_netconn_thread, NULL, 4095, osPriorityHigh); void http_server_netconn_thread(void *arg) { static struct netconn *TCPListener, *newconn; static err_t err, conn_check, deleteErr; TCPListener = netconn_new(NETCONN_TCP); if (TCPListener != NULL) { err = netconn_bind(TCPListener, IP_ADDR_ANY, PORT_60662); if (err == ERR_OK) { netconn_listen(TCPListener); while(1) { netconn_set_recvtimeout(TCPListener, TIME_DELAY_500_MS); conn_check = netconn_accept(TCPListener, &newconn); if(osOK == osTimerStart (timeOutHttpServerHandle, TIME_DELAY_60_SECONDS)) { timerHttpStatus = TIMER_RUN; } if(ERR_OK == conn_check) { http_server_serve(newconn); netconn_close(newconn); netconn_delete(newconn); } osTimerStop(timeOutHttpServerHandle); } } else { netconn_close(newconn); netconn_delete(newconn); } } } Funkcja http_server_serve(newconn)() sprawdza czy przyszło zapytanie http i na nie reaguje. Również nic odkrywczego. void http_server_serve(struct netconn *conn) { connCheck = netconn_recv(conn, &inbuf); if(connCheck == ERR_OK) { if (netconn_err(conn) == ERR_OK) { // pobranie danych do bufora netbuf_data(inbuf, (void**)&buf, &buflen); analiza_metody_GET(buf); analiza_metody_POST(buf); } } netconn_close(conn); netbuf_delete(inbuf); } Jeżeli przyszło zapytanie ze strony, program wysyła odpowiedź na to zapytanie. I mógłbym powiedzieć, że wszystko działa. Program działa dobrze do czasu gdy pracuje w sieci lokalnej. Problemy zaczęły się gdy udostępniłem stronę poza sieć lokalną. Szczególnie zauważalne to jest gdy chcę wyświetlić stronę na smartfonie poprzez sieć komórkową. Dane do przeglądarki przesyłam za pomocą funkcji netconn_write_partly(). netconnResult = netconn_write_partly(conn, buffer_send, len, NETCONN_NOCOPY, &written); Niestety po pewnym czasie program blokuje się na tej funkcji i pozostaje już tylko reset. Sytuacje taką zauważyłem przy przesyłaniu do przeglądarki pakietów danych o objętości 6,5 kB. Przy przesyłaniu pakietów o objętości poniżej 1kB takich problemów nie zauważyłem. Przeglądając internet znalazłem parę wątków o problemach z oprogramowaniem od ST. Niestety nie pomogły mi rozwiązać mojego problemu. Pytanie do osób przerabiających temat serwera www na stm32 czy przerabiały podobny problem lub czy istnieje możliwość włączenia dla tej funkcji timeout-u umożliwiającego jej opuszczenie i dalsze działanie urządzenia?

Witam, Właśnie rusza projekt, który ma umożliwiać zdalne nauczanie zagadnień z mechatroniki i przetwarzania sygnałów. Idea jest taka, aby każdy uczeń/student miał w domu swoje własne stanowisko ze szkoły, sam rejestrował dane, a następnie, żeby nauczył się je przetwarzać w chmurze. Na chwilę obecną szukane są pomysły, np.: 1) użytkownik sam zbiera dane drganiowe z kilkudziesięciu cykli prania, a dostarczony generator dodaje sygnały powolnego uszkodzenia łożyska, generując zbiór Big Data. Następnie, użytkownik zgodnie z instrukcją opracowuje w chmurze algorytm Novelty Detection (np.sieć LSTM). 2) w zestawie jest obudowa łożyska, która jest elektromechanicznie wzbudzana z wykorzystaniem Arduino/Raspberry Pi. Drugi układ Arduino/Raspberry Pi rejestruje odpowiedź na wymuszenie. Następnie, estymowana funkcja odpowiedzi częstotliwościowej (FRF) jest wykorzystywana jako część stochastyczna sygnału syntetycznego rozwoju uszkodzenia łożyska tocznego. Na jej podstawie budowany jest zbiór Big Data, który bardzo wiernie odzwierciedla sygnały rzeczywiste. Dane są zbierane od wielu użytkowników i są użyte w procesie uczenia maszynowego w chmurze. 3) oczywiście, takie zestawy WYMUSZENIE/REJESTRACJA same w sobie pozwalają na analizę wpływu rodzaju wymuszenia na estymowaną FRF 4) Dalsze pomysły?! Pozdrawiam, Ajab00

Cześć. Zdarza mi się popełnić jakiś układ, który wykonuję samodzielnie - trawienie, lutowanie, programowanie itp. Hobbystycznie - dla siebie, ewentualnie coś dla znajomych. Zwykle korzystam z uC AVR, ale ostatnio bawię się płytkami Nucleo od STM. Powoli myślę o przesiadce z THT na SMT. I tu pojawia się pytanie - w jaki sposób programować takie mikrokontrolery? Mam w domu jakieś przejściówki z QFP na DIP, ale to wymaga przylutowania, zaprogramowania, odlutowania i przylutowania na gotowej płytce. Trochę mnie taki proces przeraża. Chciałem zakupić taki adapter z klipsem, ale okazuje się, że to uzależnia mnie zarówno od danej wielkości układu (QFP48, QPT64 itd.), jak i rozstawu nóżek (np. 0.8 mm dla AVR i 0.5 mm dla STM32). Znalazłem też takie igły-sondy z wysuwanymi szczypcami do chwytania nóżek, ale czy to mi chwyci 0.5 mm bez zwierania sąsiednich nóżek??? Czy jest jakieś w miarę uniwersalne rozwiązanie, które pozwoli mi na programowanie układów SMD o różnym rastrze, a przynajmniej różnej liczbie nóżek? Takie dedykowane adaptery są dość drogie (ok. 60 zł zwykły i ok. 300 zł z wyprowadzeniami JTAG/SWD i USART) i nie chciałbym kupować kilku, by móc używać różnych uC. Czy pozostaje mi wlutowywanie na docelowej płytce pinów do programowania? Używając SMD chciałbym przede wszystkim uniknąć wiercenia w płytce i zająć jak najmniej miejsca na niej, a takie piny trochę mi się z tym kłócą. Jakie rozwiązanie polecacie dla mnie? I drugie - poboczne pytanie: jak najlepiej/najłatwiej programować gołe scalaki z STM32, jeśli posiadam programatory z płytek Nucleo-64 i Nucleo-144?

Cześć, to już któryś wieczór, kiedy siedzę i próbuję zrozumieć dlaczego nie mogę połączyć się z magnetometrem MMC5983MA po SPI, więc postanowiłem się podzielić problemem. Na własnej płytce mam STM32F4, kilka układów na SPI1, SPI5, które działają i nieszczęsny magnetometr MMC5983MA na SPI2, który korzysta z tych samych funkcji, lecz nie chce rozmawiać. Odbiór danych w kodzie wygląda tak: uint8_t bufferSize = 2U; uint8_t readWriteBit = 0x80; uint8_t timeout = 10U; uint8_t productIdAddress = 0x2F; uint8_t txBuffer[2] = { productIdAddress | readWriteBit, 0x00 }; uint8_t rxBuffer[2] = { 0 }; HAL_GPIO_WritePin(MMC5983MA_SPI2_CS_GPIO_Port, MMC5983MA_SPI2_CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(&hspi2, txBuffer, rxBuffer, bufferSize, timeout); HAL_GPIO_WritePin(MMC5983MA_SPI2_CS_GPIO_Port, MMC5983MA_SPI2_CS_Pin, GPIO_PIN_SET); Na analizatorze wygląda to tak, układ w ogóle nie macha linią MISO: Konfiguracja SPI2 z CubeMX: Schemat: Sekwencja zapisu/odczytu SPI: Przykład połączenia: Rejestr, który próbuję odczytać: Mam polutowane 4 płytki i na żadnej z nich nie udało mi się nawiązać połączenia, nie jest to dowód na to, że z pcb na pewno jest wszystko w porządku, ale chciałbym najpierw potwierdzić, że sposób odczytu danych od strony programowej jest poprawny. W erracie używanego procka nie ma żadnej wzmianki, która mogłaby mieć bezpośredni związek z moim problemem. Czy ktoś ma jakiś pomysł co mogę jeszcze sprawdzić? Edit: Płytki wypiekam w piecu IR, rampa jest bardzo zbliżona do tej z dokumentacji układu magnetometru, do tej pory nie udało mi się upalić pozostałych układów, więc obstawiałbym, że proces lutowania ich nie zabija.

Witam Tak jak w temacie chciałbym skonfigurować dwa moduły nRF24L01 do najprostszej komunikacji między sobą. Mam na myśli podstawowe wysyłanie danych np. jednego bajtu, bez żadnych bajerów typu zmiana adresu, automatyczna odpowiedź, potwierdzenie dostarczenia itp. Do obsługi tych modułów korzystam z mikrokontrolerów STM32. Konfiguruję wszystko zgodnie z notą od producenta, krok po kroku ustawiam wszystkie rejestry konfiguracyjne tj: - CONFIG - tu ustawiam maskę przerwań, włączam moduł i ustalam tryb pracy (Rx lub Tx) - EN_AA Enhanced ShockBurst™ - tutaj zeruję cały rejestr - nie korzystam z Auto Acknowledgment - RX_PW_P0 - korzystam z pipe 0 i dla niej ustawiam długość ładunku na 1 bajt - SETUP_RETR - tutaj wyłączam retransmisję - RF_SETUP - ustawiam prędkość transmisji na 1 Mbps ...i w zasadzie to wszystko. Doczytałem że tyle jest wymagane do prostej komunikacji. Dodam jeszcze że korzystam z domyślnych adresów zarówno w nadajniku jak i odbiorniku (0xE7E7E7E7E7) więc rejestrów z adresami w ogóle nie ruszam. Nadawanie realizuję w ten sposób: po konfiguracji (przy niskim CE) wysyłam do modułu komendę "Chcę wysłać dane" oraz dane do wysłania (1 bajt) przez SPI. Po zakończeniu transmisji wystawiam impuls wysoki na pinie CE. Odbieranie: po konfiguracji (również przy niskim CE) wystawiam stan wysoki na pinie CE - nasłuchiwanie, po czym moduł po otrzymaniu poprawnie odebranych danych wystawia stan niski na pinie przerwania IRQ co oznacza że są gotowe dane do odczytania. Problem w tym że..... nie wystawia sygnału na IRQ... czyli nie odbiera danych a przynajmniej nie poprawnie. Dlatego też zwracam się z prośbą o pomoc i pytaniem co w powyższych czynnościach jest błędne lub czego brakuje ??? Liczę na to że ktoś z mądrych ludzi, których na tym forum nie brakuje zadał sobie kiedyś taki trud jak ja i zechciał samodzielnie obsłużyć moduły radiowe nRF24L01 nie korzystając z bibliotek. Bardzo proszę o nawet drobne wskazówki.

Witam! Czy ktoś jest w stanie polecić jakieś materiały na temat współpracy ESP32-CAM i STM32 udało mi się nawiązać komunikację poprzez FTDI lecz nie wiem co dalej.

Cześć. Robię projekt rozpoznawania jednego z kilku ruchów za pomocą akcelerometru, żyroskopu, STM32F467ZG i pakietu X-CUBE-AI. Opieram się na artykule @Elvis Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI, ale mam kłopot z jego rozszerzeniem. Próbowałem różnych sposobów, ale nie mogę zrobić sieci, która zamiast wartości binarnej (ruch - brak ruchu) zwróci mi prawdopodobieństwa każdego z 6 wyjść (na razie chciałbym tyle różnych ruchów rozpoznawać). Mam książkę, którą poleca Elvis ("Deep Learning" autorstwa Chollet'a), ale brak doświadczenia z SSN, czy nawet językiem Python mocno mnie ogranicza. Chciałbym też, żeby zamiast jednego wejścia będącego prostą funkcją odczytów z czujników (suma kwadratów odczytów z akcelerometru), f = open('data1.csv','r') values = [] results = [] for line in f: fields = line.strip().split(',') if len(fields) == 4: x = float(fields[0]) y = float(fields[1]) z = float(fields[2]) values.append([math.sqrt(x**2 + y**2 + z**2)]) results.append(float(fields[3])) f.close() układ bezpośrednio korzystał ze wszystkich 6 (3ACC i 3 GYRO). Tutaj fragment kodu Elvisa z STM'a: void MX_X_CUBE_AI_Process(void) { /* USER CODE BEGIN 1 */ float nn_input[AI_FORBOT_AI_IN_1_SIZE]; float nn_output[AI_FORBOT_AI_OUT_1_SIZE]; aiRun(nn_input, nn_output); /* USER CODE END 1 */ } static uint32_t next_ms = 1000; static float nn_input[AI_FORBOT_AI_IN_1_SIZE]; float nn_output[AI_FORBOT_AI_OUT_1_SIZE]; while (HAL_GetTick() < next_ms) {} next_ms += READ_DELAY_MS; lsm6_value_t acc; acc = lsm6_read_acc(); for (int i = 0; i < AI_FORBOT_AI_IN_1_SIZE - 1; i++) nn_input[i] = nn_input[i + 1]; nn_input[AI_FORBOT_AI_IN_1_SIZE - 1] = sqrt(acc.x * acc.x + acc.y * acc.y + acc.z * acc.z); aiRun(nn_input, nn_output); if (nn_output[0] >= 0.5f) HAL_GPIO_WritePin(LED2_GPIO_Port, LED2_Pin, GPIO_PIN_RESET); else HAL_GPIO_WritePin(LED2_GPIO_Port, LED2_Pin, GPIO_PIN_SET); Pomożecie mi zmienić kod Python'a i STM'a, bym mógł go użyć do swoich potrzeb? Naprawdę długo szukałem sposobu i próbowałem wielu rozwiązań, ale albo nie działa mi sieć neuronowa, albo nie kompiluje się projekt w SW4STM32.

Witam, jak osiągnąć maksymalny sampling rate na ADC + DMA? SysClock ustawiony na 72Mhz. APB2CLKDivider i APB1CLKDivider ustawione na 1. ADC leci w ContinuousConvMode = ENABLE i ExternalTrigConv = ADC_SOFTWARE_START; SamplingTime = ADC_SAMPLETIME_13CYCLES_5; DMA zapisuje do bufora[128] z jednego kanału ADC i wysyłam sobie to na ekran co jakiś czas. Oczekuję zapisu badania sygnału do 20kHz, jak na razie nie łapie mi poprawnie nawet sygnału 9kHz, Co tu zrobić, dać zewnętrzny trigger z jakiegoś timera ustawionego na przerwanie co 44.1kHz? Jest to szybsze?

Cześć. Mam taki problem, mam program do obsługi radia i chcę za pomocą enkodera wybierać odpowiednie stacje. Mam zmienną do której zapisuje pozycje enkodera (wzorowałem się na kursie Forbota z stm32F4) potem za pomocą instrukcji switch sprawdzam tę pozycję i na tej podstawie wykonuję się odpowiedni case który ustawia stację, to nie jest optymalne bo muszę to zapętlać żeby co chwilę sprawdzać pozycję enkodera. Nie wiem czy słusznie, ale wydaje mi się że powinienem tutaj użyć przerwań i jakiejś funkcji callback. Moje pytanie brzmi jak skonfigurować Timer, a następnie co zrobić żeby program wykrywał zmianę pozycji enkodera? Dodam jeszcze że przeglądałem dokumentacje biblioteki HAL i dalej nie jestem w stanie tego zrobić. Mam nadzieję że w miarę jasno to przedstawiłem dołączyłem jeszcze screen aktualnego programu (jest bardzo prymitywny ale sprawdzałem czy wszystko inne działa :D)

Na podstawie kursu STM32 chcę uruchomić płytkę STM32F103C8T6, zdjęcie płytki poniżej. Oczywiście nie mogę podczas tworzenia projektu wybrać NUCLEO-F103RB więc poniżej przesyłam zdjęcia z konfiguracji, czy jest ona prawidłowa ? Czy może powinienem wejść w zakładkę MCU a nie Board i tam wybrać procesor ? Przechodząc do biblioteki, zgodnie z opisaną aktualizacją: https://forbot.pl/forum/topic/8387-kurs-stm32-3-plytka-nucleo-konfiguracja-srodowiska/page/10/#comments Dla NUCLEO-F103RB: https://www.st.com/en/embedded-software/stsw-stm32143.html#overview Dla STM32F103C8T6: https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-mainstream-mcus/stm32f1-series/stm32f103/stm32f103c8.html#tools-software Następnie wybrałem zakładkę Tools & Software, następnie MCU & MPU Embedded Software, następnie najbardziej podobny plik do "based on Standard Peripheral Library" to (proszę kliknąć ctrl+f i wkleić STM32-CLASSB-SPL). Czy to jest odpowiedni plik ?

W przypływie wolnego czasu chciałem przećwiczyć sobie obsługę USB w STM32 i przy okazji zrobić coś praktycznego do podłączenia do komputera. Ponieważ mam klawiaturę mechaniczną z przyciskami multimedialnymi ukrytymi pod mało praktyczną kombinacją z klawiszem FN (klawisz po prawej stronie - totalnie niepraktyczne w tym zastosowaniu) postanowiłem zrobić sobie dedykowany pilot do multimediów. Platforma STM32F103 bo mam mały zapas płytek BluePill. Jako sterowanie wybrałem joystick z enkoderem na wzór tych z systemów infotainment w samochodzie. Żeby doprecyzować joysticki ALPS RKJXT1F42001 zamówione jakiś czas temu na aliexpress i czekające na projekt jak ten. Kod na STM32 powstawał na bazie generowanego przez CubeIDE przy middleware USB_DEVICE z wybranym Human Interface Device Class (HID). W moim odczuciu generowany kod jest chyba bardziej demonstracją, ponieważ kod z definicjami deskryptorów jest stworzony dla myszy, i nie ma nigdzie znaczników USER_CODE_BEGIN/END. Próbowałem coś zadziałać z klasą Custom Human Interface Device ale mogłem znaleźć deskryptorów urządzenia, konfiguracji i interfejsu w kodzie, a deskryptor raportu HID był do napisania od zera, co jest raczej trudne przy pierwszym projekcie z USB. Zostałem przy przykładzie z myszką od ST, który sukcesywnie modyfikowałem, tworząc kopie zapasowe na wypadek potrzeby generowania kodu z Cube (przez brak znaczników USER_CODE wszystkie zmiany - głównie zmodyfikowany deskryptor raportu - byłyby nadpisane przez wygenerowany kod). Nie będę opisać tworzenia mojego deskryptora bo robiłem to raczej na czuja metodą prób i błędów. W skrócie chodzi o to, że deskryptor raportu HID informuje host(komputer) o możliwościach urządzenia oraz przypisuje funkcjonalności bajtom w raporcie HID - w moim przypadku każdy bit w drugim bajcie raportu niesie informacje o wciśnięciu przycisku z grupy consumer page (0x0C) (więcej o nich w dokumentacji USB HID - HID Usage Tables 1.12). Utworzenie deskryptora od zera jest raczej trudne dla początkującego ale w internecie jest sporo informacji - wielką pomocą był dla mnie raport z przykładowej implementacji (http://www2.ece.rochester.edu/~parihar/pres/Report_MultiMedia-KB.pdf) w którym o wiele lepiej wytłumaczono działanie USB, klas i deskryptorów, niż ja to jestem w stanie zrobić. Oprócz tego mój deskryptor raportu jest lekko zmodyfikowaną wersją tego spod linku. Deskryptory urządzenia, konfiguracji i interfejsu wykorzystałem w wersji wygenerowanej przez cube dla myszy - zmieniłem jedynie typ urządzenia na klawiaturę (0x01) w deskryptorze konfiguracji (Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c). Deskryptor raportu powstał na podstawie tego podlinkowanego. Mapowanie przycisków do bitów w raporcie jest tam zobrazowane na stronie 11. Dobry tutorial o deskryptorach raportów HID tutaj. Gotowy deskryptor raportu przedstawia się tak: 0x05, 0x0c, // USAGE_PAGE (Consumer Devices) 0x09, 0x01, // USAGE (Consumer Control) 0xa1, 0x01, // COLLECTION (Application) 0x85, 0x01, // REPORT_ID (1) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x10, // REPORT_COUNT (16) 0x09, 0xe2, // USAGE (Mute) 0x01 0x09, 0xe9, // USAGE (Volume Up) 0x02 0x09, 0xea, // USAGE (Volume Down) 0x03 0x09, 0xcd, // USAGE (Play/Pause) 0x04 0x09, 0xb7, // USAGE (Stop) 0x05 0x09, 0xb6, // USAGE (Scan Previous Track) 0x06 0x09, 0xb5, // USAGE (Scan Next Track) 0x07 0x0a, 0x8a, 0x01, // USAGE (Mail) 0x08 0x0a, 0x92, 0x01, // USAGE (Calculator) 0x09 0x0a, 0x21, 0x02, // USAGE (www search) 0x0a 0x0a, 0x23, 0x02, // USAGE (www home) 0x0b 0x0a, 0x2a, 0x02, // USAGE (www favorites) 0x0c 0x0a, 0x27, 0x02, // USAGE (www refresh) 0x0d 0x0a, 0x26, 0x02, // USAGE (www stop) 0x0e 0x0a, 0x25, 0x02, // USAGE (www forward) 0x0f 0x0a, 0x24, 0x02, // USAGE (www back) 0x10 0x81, 0x62, // INPUT (Data,Var,Abs,NPrf,Null) 0xc0 I definicje bitów dla przycisków oraz zmiennej przechowującej raport HID do wysłania #define HID_REPORT_SIZE 3 #define MEDIA_MUTE 0 #define MEDIA_VOLUP 1 #define MEDIA_VOLDOWN 2 #define MEDIA_PLAY_PAUSE 3 #define MEDIA_STOP 4 #define MEDIA_PREV 5 #define MEDIA_NEXT 6 /* USER CODE END PD */ /* Private variables ---------------------------------------------------------*/ TIM_HandleTypeDef htim1; /* USER CODE BEGIN PV */ extern USBD_HandleTypeDef hUsbDeviceFS; uint8_t HID_report[HID_REPORT_SIZE] = {0x01,0,0}; //empty hid report W celu zakomunikowania hostowi wciśnięcia przycisku wysyłamy raport HID z ustawionym bitem odpowiadającym wciśniętemu przyciskowi. Przykładowo dla przycisku VOL_UP ustawić należy drugi bit w drugim bajcie raportu. Ponieważ należy zasymulować wciśniecie i zwolnienie przycisku należy wysłać po chwili drugi raport z samymi zerami. Ważne jest też zachowanie co najmniej 10 ms odstępu między wysyłaniem raportów, by dać czas na przetworzenie informacji bibliotece USB na STMie oraz hostowi (komputerowi). Poniżej kod w funkcji main() obsługujący wysyłanie raportów o wciśnięciu przycisków HID_report[1]=0; //0 means none of the buttons pressed ////THIS CODE CAN SUPPORT ONLY 1 KEY AT A TIME, AND VERY SLOW REPEAT WITH LONG PRESS//// CheckButtonsState(); //check if any button is pressed and set appropriate bits in HID_report[1] if(HID_report[1]!=0){ USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); //send key-press and after 15 ms key-release reports HAL_Delay(400); HID_report[1]=0; USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); } Funkcja CheckButtonsState() ustawia na podstawie stanów logicznych na wejściach uC, bity w 2 bajcie tablicy uint8_t przechowującej raport HID. void CheckButtonsState(){ if(!HAL_GPIO_ReadPin(PUSH_GPIO_Port, PUSH_Pin)) { //push input is low when whichever button is pressed uint8_t isPushPressed=1; if(!HAL_GPIO_ReadPin(RIGHT_GPIO_Port, RIGHT_Pin)) {SetKeyPress(MEDIA_NEXT); isPushPressed=0; } if(!HAL_GPIO_ReadPin(LEFT_GPIO_Port, LEFT_Pin)) {SetKeyPress(MEDIA_PREV); isPushPressed=0; } if(!HAL_GPIO_ReadPin(UP_GPIO_Port, UP_Pin)) {SetKeyPress(MEDIA_MUTE); isPushPressed=0; } if(!HAL_GPIO_ReadPin(DOWN_GPIO_Port, DOWN_Pin)) {SetKeyPress(MEDIA_STOP); isPushPressed=0; } if(isPushPressed==1){SetKeyPress(MEDIA_PLAY_PAUSE);} } } void SetKeyPress(uint8_t key){ HID_report[1] |= 1<<key; } Zastosowany joystick ALPS jest tak skonstruowany, że wciśnięcie jakiegokolwiek przycisku zwiera także wyprowadzenie PUSH odpowiadające wciśnięciu joysticka. Z tego powodu funkcja jest napisana tak, że jeżeli na wejściu PUSH jest 1 to na każdym innym musi być 1 (styki otwarte). Jeżeli wciśnięty jest PUSH (logiczne 0) ale też 0 jest na pinie od innego przycisku, oznacza to że wciśnięto inny przycisk, a stan na wejściu PUSH jest ignorowany. Jeżeli 0 jest tylko na wejściu PUSH, oznacza to że joystick rzeczywiście został wciśnięty. Takie rozwiązanie prosi się aż o generowanie przerwania z wejścia PUSH i wykonywania kodu wtedy. Ponieważ jestem leniwy i miałem już gotowy kod do wysyłania raportów HID kiedy to odkryłem, zostałem przy pollingu stanu na wejściach. Delay po wysłaniu raportu rozwiązuje mi także problem z debouncingiem przycisków (obserwowałem wejścia na oscyloskopie i stwierdzam że styki w tym joysticku drżą jak złe ). Regulację głośności obsługuję przez timer 1 w trybie enkodera (przydał się kurs zaawansowanych timerów na STM32 z waszego bloga ). Przy zmianie wartości licznika timera wartość jest porównywana z zapisaną w poprzednim przejściu głównej pętli while(1). Jeżeli się zmieniła na mniejszą lub większą wysyłany jest raport HID z ustawionym bitem odpowiadającym klawiszowi VOLUP/VOLDOWN a zmienna lastEncoderCount jest in/dekrementowana. Dopóki obie wartości nie są równe raporty są wysyłane co przejście głównej pętli while. Wartość licznika jest dzielona przez 2 gdyż przy poprawnej pracy enkodera o tyle zmienia się po przeskoczeniu "o jeden ząbek". Czasem miałem sytuację że wartość licznika była nieparzysta (może błąd połączeń/drżenie styków) i algorytm w kółko podnosił/obniżał głośność o 1 bo wartości encoderCount i lastEncoderCount nigdy nie były równe. Dzielenie przez 2 gwarantuje parzystość wartości zmiennej ///TE ZMIENNE SA GLOBALNE/// uint16_t encoderCount=32766; //half of timers resolution (16bit) uint16_t lastEncoderCount=16383; //////////////////////////// //TEN KOD WYKONUJE SIE W PETLI WHILE FUNKCJI MAIN()// encoderCount=__HAL_TIM_GET_COUNTER(&htim1)/2; //get encoder absolute position if(encoderCount!=lastEncoderCount){ if(encoderCount<lastEncoderCount){SetKeyPress(MEDIA_VOLDOWN);lastEncoderCount-=1;} //set key press depending on encoder movement direction else{SetKeyPress(MEDIA_VOLUP);lastEncoderCount+=1;} USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); HID_report[1]=0; USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); } Kompletne oprogramowanie STMa dostępne na github.com/wiciu15/STM32-USBHID-MultimediaPilot. Po zweryfikowaniu działania prototypu zaprojektowałem i wytrawiłem prostą płytkę w KiCADzie żeby się pozbyć luźnych kabelków. Urządzenie zasilane jest z USB na BluePillu, programuje je z wyprowadzeń SWD po drugiej stronie płytki za pomocą ST-Linka V2. Żeby urządzenie jakoś wyglądało zaprojektowałem i wydrukowałem obudowę oraz gałkę do joysticka. Od razu ostrzegam że na drukarce FDM ciężko jest osiągnąć taką precyzję żeby gniazdo w gałce ciasno siedziało na wałku joysticka - ja zaprojektowałem 0,1mm ciaśniej i przy montażu rozgrzałem plastik tak by się uplastycznił i dopasował do kształtu na końcu drążka joysticka. Nie jest to ciasne pasowanie ale wystarcza żeby sterować bez urywania gałki co drugie dotknięcie . I wydrukowane: Wszystkie pliki z kodem, płytka i obudowa dostępne na github.com/wiciu15/STM32-USBHID-MultimediaPilot. Z racji że chciałbym dalej to rozwijać to zakupiłem moduł NRF51822 i będę próbował zrobić coś podobnego, ale na Bluetooth HID, i z zastosowaniem w aucie do sterowania tanim tabletem z emulatorem headunitu AndroidAuto (używam apki HeadUnit Reloaded która wspiera obsługę z klawiatury do sterowania API Androida Auto np. sterowanie jasny/ciemny tryb, multimedia, poruszanie się po interfejsie za pomocą enkodera - AA jest tak zaprojektowany bo piloty do systemów infotainment z reguły mają też enkodery). Jedyna moja obawa jest taka że pilocik będzie musiał działać cały czas ze stałej instalacji 12V, bo tablet z niewiadomych powodów po rozłączeniu z sparowanym urządzeniem BT wymaga ręcznego ponownego połączenia, więc po wyłączeniu i włączeniu pilocika czeka mnie wycieczka do ustawień tabletu by go z powrotem połączyć. Nie mam doświadczenia z programowaniem nRF więc zobaczymy jak mi pójdzie na raz z BT HID, przerwaniami, enkoderem i jeszcze minimalizacją poboru energii Łatwiej by było dorobić drugie USB w tablecie i podłączyć taki pilot jak opisałem powyżej. Tu jest problem tej natury, że tablet który mam już zmodyfikowany i założony na bardzo mocną taśmę dwustronną () nie chce działać na OTG z więcej niż jednym urządzeniem. Podłączałem do niego kilka HUBów USB, kupiłem nawet specjalną przejściówkę do OTG z paroma portami USB ale nic nie chce ruszyć. Póki co moduł z NRF81 dopiero przyszedł, będę teraz się oswajał z SDK do niego, może jakiś hello world . Nie jestem jeszcze pewny czy będę w stanie go programować i debugować bo mam tylko ST-Linka na stanie w tej chwili Podobno korzystając z OpenOCD można ST-Linka z tym połączyć ale to musiałbym przy wolnej chwili zrobić próby. Jak nie ruszy to będę szukać jakiegoś JTAGa ale ceny mnie trochę odstraszają. Wszelkie sugestie, pochwały, krytyka i komentarze mile widziane

Cześć, nie wiem czy dokładnie temat opisze mój problem ale: Musiałem zrobić na PC reinstalke Windowsa i pobrałem Keila. Wszystko ładnie pobrało mi - sterowniki do STlinka, biblioteki etc. zautomatu. I pojawił się taki problem, że za każdym razem jak zaprogramuje procka muszę wciskać reset by program ruszył. Wcześniej nie musiałem mam opcję zaznaczoną w ustawieniach STlinka ale po wgraniu i podstawowego programu (mruganie dioda) int main(void) { init_all(); while(1) { GPIOA->ODR^=1<<5; delay(20); } } zawsze musze zresetować plytke (nucelo f103) czy ktoś z Was miał podobny problem? Przed reinstalka systemu ten sam program nie wymagał czegoś takiego Pozdrawiam!

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?

Witam! To mój pierwszy wpis w dziale DIY. Projektem jest (a właściwie dopiero będzie) mini konsolka do gier na STM32F1. Robię ten projekt dla mojego 3-letniego synka. Docelowo będę mu wgrywać na nią różne napisane przeze mnie gry, ale na początek zacznę od klasyki, czyli gra w węża Robiłem już podobny projekt przy okazji kursu SMT32 na Forbocie, więc szybko powinienem napisać niezbędny kod. Tym razem ma to być gotowe urządzenie które bez problemu będzie mógł obsłużyć 3-latek. Założenia projektu: 1. Mikrokontroler STM32F1 2. Ekran TFT kolorowy 240x320 3. Zasilanie bateryjne LiPo z ładowaniem przez gniazdo USB (więcej szczegółów w moim wątku w dziale Zasilanie - szczególnie ostatni mój post) 4. Obudowa w całości drukowana w 3D 5. Żadnych gotowych modułów. Własny projekt PCB i własny montaż. 6. Klawiatura: Krzyżyk, przycisk A, przycisk B oraz przycisk POWER, jak w starych Game - Boy'ach 7. Dzwięk: Nad tym jeszcze nie myślałem, brak I2S oraz DACa na mojej płytce Nucleo trochę utrudnia sprawę. Może będzie coś na Timerach i PWM. Zobaczymy. Teraz po kolei. Pierwsze co musiałem zrobić to ogarnąć wyświetlanie na TFT. Zakupiłem trochę w ciemno kilka wyświetlaczy 2,8" na ILI9341. Mój brak doświadczenia z TFT natychmiast się zemścił. Po odbiorze przesyłki okazało się że obsługa SPI wcale nie jest oczywista i jestem skazany na 16-bitową magistralę. Nie znalazłem nigdzie driverów na STM32 do sterowania tym kontrolerem przy takim połączeniu, ale znalazłem kilka projektów na GitHub'ie gdzie było sterowanie przez magistralę 8-bitową. Postanowiłem więc na podstawie tych projektów napisać własne drivery i procedury wyświetlania podstawowych kształtów. W trakcie prac nad optymalizacją wyświetlania okazało się że jednak 16-bitowa magistrala to doskonały pomysł i jest 4-krotnie szybsza od 8-bitowej. Dlaczego? Już tłumaczę: Gdy używa się 8-bitowej szyny danych to wysłanie piksela wygląda następująco (już po ustawieniu adresu): - Ustawiamy pierwsze 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 - Ustawiamy kolejne 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 4 kroki. Gdy używamy 16-bitowej magistrali - wygląda to następująco: - Ustawiamy 16 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 2 kroki. Ale przecież pisałem że jest 4 razy szybciej, a tu wychodzi że 2 razy No więc łatwo można zauważyć, że przy 16 bitach raz ustawiony kolor na linii danych możemy zostawić do czasu aż będziemy musieli użyć innego koloru. Więc jeżeli mamy kilkaset pikseli do wypełnienia jednym kolorem to raz go ustawiamy, a później już tylko WR strobe tak długo jak potrzebujemy Czyli realnie wykonujemy tylko jeden krok. Zaimplementowałem to w moich driverach i rezultaty były doskonałe. Na tyle dobre że odpadła mi konieczność posiadania pamięci pod bufor klatki. Wszystko wyświetla się błyskawicznie: Aktualnie mogę wyświetlać do 8Mpix/s, co teoretycznie pozwala odświeżyć ekran 240x320 ponad 100 razy na sekundę na STM32F1 taktowanym 64MHz. Czyli mogę jeszcze podnieść tą częstotliwość do 72 MHz i jeszcze zwiększyć transfery. Niestety chwilowo mam odcięty programator od płytki Nucleo i muszę kożystać z wewnetrznego oscylatora który pozwala rozkręcić mikroprocesor do 64MHz. Kolejnym problemem z którym musiałem się zmierzyć to mała ilość flash na grafiki do gier. Jak łatwo policzyć jedna pełnoekranowa grafika to 153600 bajty, a mam tylko 128k do dyspozycji. A jeszcze musi się zmieścić program. Rozwiązaniem problemu jest kompresja. Tu znów musiałem od zera napisać program do kompresji grafiki który spełniałby moje wymagania. Kompresor został napisany w Pythonie. A szybki dekoder zaimplementowany w C w driverach na STM32. Pisałem program praktycznie od zera wg mojego pomysłu. Otóż dzieli on grafikę na bloki o jednolitych kolorach, a ich metadane zapisuje w binarnym pliku wyjściowym, albo w pliku C. Bloki są następujące: pozioma linia, pionowa linia, prostokąt. Pojedynczy piksel to pozioma linia o długości 1. Kompresja odbywa się przez rozkład grafiki na takie bloki, a następnie zapisaniu ich parametrów do pliku wyjściowego. Procedurę dekompresji zaimplementowałem w driverach do wyświetlacza, a każdy blok łatwo można wysłać bezpośrednio do pamięci ekranu, gdzie obraz zostaje odtworzony. Kolejną funkcją którą zaimplementowałem w kompresorze jest możliwość kodowania różnicy pomiędzy dwoma grafikami. Tzn jeżeli robię animację to program kompresuje tylko piksele które różnią dwie klatki. Poniżej proces odtwarzania obrazka na wyświetlaczu w zwolnionym tempie: Skoro miałem już ograne wyświetlanie grafiki, przyszedł czas na prototypowanie konsoli i pisanie samego kodu gry Aktualnie moje stanowisko pracy wygląda następująco: Sama gra jest na etapie tworzenia grafiki. Na razie mam animacje na intro: To tyle na dzisiaj. Wraz z postępami będę aktualizował ten wątek. Pozdrawiam, Marek

Po udanym projekcie robota "Copernicus" - w szeregowym łańcuchu kinematycznym 4DOF przyszedł czas na robota klasy delta, nazwanego "Astra", ponieważ ramiona układają się właśnie w gwiazdę Prototyp prezentowałem na targach Hobby 2019 na Międzynarodowych Targach Poznańskich, generalnie nie ma nic rewolucyjnego - zasilacz 36V, 3 silniki NEMA17 z przekładniami planetarnymi, przeguby kulkowe firmy Igus® (serdecznie dziękuję), zerowanie - krańcówki, eżektor, ssawka, w pierwszej wersji - Arduino Mega, teraz to już Discovery F429 z wyświetlaczem LCD (wyświetlam na nim koordynaty, chciałbym też obsługiwać dotyk, ale dodanie biblioteki do obsługi dotyku kłóci się ze sterowaniem silnikami krokowymi ). Aktualnie, robot potrafi wykonać proste zadanie pick&place Projekt cały czas ewoluuje (określiłbym postęp na 60%), mam zamontowaną RPi 3B+ z kamerką, chciałbym dodać podajnik obrotowy, rozpoznawać kolor krążków i układać do określonych pojemników, a na koniec pudełeczko z posortowanymi elementami pneumatycznie wysunąć - chyba, że komuś przychodzi na myśl coś lepszego? (ale, żeby z wykorzystaniem pneumatyki, mam do dyspozycji dużo różnych siłowników i kilka chwytaków ), z góry mówię, że znam aplikację taśmociągu i systemu wizyjnego Podziękowania składam również dla Kolegi @Eukaryota za pomoc i inspirację Pozdrawiam

Witam, Jestem początkującym w programowaniu STM32F103. Do tej pory programowałem Microchip PIC 8 bitowe w asm i C. Zakupiłem zestaw STM32F103 Nucleo i uczę się programowania z kursu, jest bardzo ciekawy i pomocny. Zgodnie z kursem uruchomiłem UART, przetwornik ADC na DMA, przerwanie na TIM2 z częstotliwością 4kHz, PWM 12kHz. W przerwaniu przepisuję wartość z przetwornika ADC (po przeskalowaniu od 0 - 1000) i zmieniam wypełnienie PWM. Pojawia się problem z przebiegiem PWM. Proszę o pomoc w rozwiązaniu problemu. Pozdrawiam. Jurek /** ****************************************************************************** * @file main.c * @author Ac6 * @version V1.0 * @date 01-December-2013 * @brief Default main function. ****************************************************************************** */ #include <stdio.h> #include <stdint.h> #include "stm32f10x.h" #include <math.h> #define ADC_CHANNELS 2 TIM_OCInitTypeDef channel; // PWM volatile uint32_t timer_ms = 0; uint16_t adc_value[ADC_CHANNELS]; volatile int32_t PID; volatile uint16_t PID_PWM; volatile uint32_t old_adc_0, old_adc_1; void SysTick_Handler() { if (timer_ms) timer_ms--; } void TIM2_IRQHandler() { if (TIM_GetITStatus(TIM2, TIM_IT_Update) == SET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); GPIO_SetBits(GPIOA, GPIO_Pin_5); PID = (adc_value[0] / 4); PID_PWM = PID; channel.TIM_Pulse = PID_PWM; TIM_OC1Init(TIM4, &channel); GPIO_ResetBits(GPIOA, GPIO_Pin_5); //if (GPIO_ReadOutputDataBit(GPIOA, GPIO_Pin_5)) //GPIO_ResetBits(GPIOA, GPIO_Pin_5); //else //GPIO_SetBits(GPIOA, GPIO_Pin_5); } } void delay_ms(int time) { timer_ms = time; while (timer_ms); } void send_char(char c) { while (USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET); USART_SendData(USART2, c); } int __io_putchar(int c) { if (c=='\n') send_char('\r'); send_char(c); return c; } int main(void) { //int8_t i; GPIO_InitTypeDef gpio; USART_InitTypeDef uart; DMA_InitTypeDef dma; ADC_InitTypeDef adc; TIM_TimeBaseInitTypeDef tim; // Timer 2 NVIC_InitTypeDef nvic; // Timer 2 //TIM_OCInitTypeDef channel; // PWM RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB | RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); RCC_ADCCLKConfig(RCC_PCLK2_Div6); RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, ENABLE); GPIO_StructInit(&gpio); gpio.GPIO_Pin = GPIO_Pin_5; gpio.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(GPIOA, &gpio); //*** konfiguracja pinow UART gpio.GPIO_Pin = GPIO_Pin_2; gpio.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_Init(GPIOA, &gpio); gpio.GPIO_Pin = GPIO_Pin_3; gpio.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &gpio); //*** //*** PWM wyjscia gpio.GPIO_Pin = GPIO_Pin_6|GPIO_Pin_7|GPIO_Pin_8|GPIO_Pin_9; gpio.GPIO_Speed = GPIO_Speed_50MHz; gpio.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_Init(GPIOB, &gpio); //*** USART_StructInit(&uart); uart.USART_BaudRate = 115200; USART_Init(USART2, &uart); USART_Cmd(USART2, ENABLE); //*** ustawienie wejsc przetwornika A/D gpio.GPIO_Pin = GPIO_Pin_0|GPIO_Pin_1; gpio.GPIO_Mode = GPIO_Mode_AIN; GPIO_Init(GPIOA, &gpio); //*** //*** ustawienie DMA do odczytu wejsc przetwornika A/D DMA_StructInit(&dma); dma.DMA_PeripheralBaseAddr = (uint32_t)&ADC1->DR; dma.DMA_PeripheralInc = DMA_PeripheralInc_Disable; dma.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord; dma.DMA_MemoryBaseAddr = (uint32_t)adc_value; dma.DMA_MemoryInc = DMA_MemoryInc_Enable; dma.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; dma.DMA_DIR = DMA_DIR_PeripheralSRC; dma.DMA_BufferSize = ADC_CHANNELS; dma.DMA_Mode = DMA_Mode_Circular; DMA_Init(DMA1_Channel1, &dma); DMA_Cmd(DMA1_Channel1, ENABLE); //*** ADC_StructInit(&adc); adc.ADC_ScanConvMode = ENABLE; adc.ADC_ContinuousConvMode = ENABLE; adc.ADC_NbrOfChannel = ADC_CHANNELS; adc.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; ADC_Init(ADC1, &adc); ADC_RegularChannelConfig(ADC1, ADC_Channel_0, 2, ADC_SampleTime_239Cycles5); ADC_RegularChannelConfig(ADC1, ADC_Channel_1, 2, ADC_SampleTime_239Cycles5); ADC_DMACmd(ADC1, ENABLE); ADC_Cmd(ADC1, ENABLE); ADC_ResetCalibration(ADC1); while (ADC_GetResetCalibrationStatus(ADC1)); ADC_StartCalibration(ADC1); while(ADC_GetCalibrationStatus(ADC1)); ADC_SoftwareStartConvCmd(ADC1, ENABLE); SysTick_Config(SystemCoreClock / 1000); // *** Timer4 jako PWM //RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); TIM_TimeBaseStructInit(&tim); tim.TIM_ClockDivision = 0; tim.TIM_RepetitionCounter = 0; tim.TIM_CounterMode = TIM_CounterMode_Up; tim.TIM_Prescaler = 5 - 1; tim.TIM_Period = 1000 - 1; TIM_TimeBaseInit(TIM4, &tim); //*** //*** ustawienia kanalow PWM TIM_OCStructInit(&channel); channel.TIM_OCMode = TIM_OCMode_PWM1; channel.TIM_OutputState = TIM_OutputState_Enable; channel.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1PreloadConfig(TIM4, TIM_OCPreload_Enable); //channel.TIM_Pulse = PID_PWM; //TIM_OC1Init(TIM4, &channel); channel.TIM_Pulse = 200; TIM_OC2Init(TIM4, &channel); channel.TIM_Pulse = 500; TIM_OC3Init(TIM4, &channel); channel.TIM_Pulse = 900; TIM_OC4Init(TIM4, &channel); TIM_Cmd(TIM4, ENABLE); //*** //*** Timer 2 TIM_TimeBaseStructInit(&tim); tim.TIM_CounterMode = TIM_CounterMode_Up; tim.TIM_Prescaler = 640 - 1; tim.TIM_Period = 25 - 1; TIM_TimeBaseInit(TIM2, &tim); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); TIM_Cmd(TIM2, ENABLE); nvic.NVIC_IRQChannel = TIM2_IRQn; nvic.NVIC_IRQChannelPreemptionPriority = 0; nvic.NVIC_IRQChannelSubPriority = 0; nvic.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&nvic); //*** while (1) { //GPIO_SetBits(GPIOA, GPIO_Pin_5); //printf("ADC%d = %d\n", 0, adc_value[0]); //printf("A = %d (%.3fV)\n", PID); //channel.TIM_Pulse = PID_PWM; //TIM_OC1Init(TIM4, &channel); printf("%d\n",PID); //GPIO_ResetBits(GPIOA, GPIO_Pin_5); delay_ms(1); } }

Dzień dobry, Pojawił się u mnie niedawno problem, uruchomiłem dwa wejścia ADC z pomocą DMA - podłączyłem do nich zwykłe potencjometry, działały one poprawnie lecz przy grzebaniu w hardware mogłem podpiąć napięcie wyższe niż 3,3 V i nagle przetworniki pokazują jedynie maksymalną wartość, a gdy zamienię kable zasilające potencjometr to pokazują wartość minimalną. Czy jest to możliwe, że załatwiłem tym sposobem przetwornik ADC? napięcie mogło wynosić około 3,5 V, potencjometry działają poprawnie. Korzystam z płytki rozwojowej STM32F103C8T6, załączam dodatkowo rysunek z połączeniem potencjometrów oraz projekt CubeIDE asdas.rar

Poniższe pytanie zostało wydzielone z kursu: https://forbot.pl/forum/topic/10506-kurs-stm32-f1-hal-8-bezposredni-dostep-do-pamieci/ Witam W zadaniu 8.1 wyniki z copy_cpu() i copy_dma() mam jednakowe i są następujące: Bufor zrodlowy: 536873560 Bufor docelowy: 536873592 Jak widać, wartości są różne. W ogóle wyświetlam wartości src_buffer i dst_buffer za pomocą printf. Jakiego formatu używać do wyświetlania liczb typu uint8_t albo uint16_t, bo %d zwraca ostrzeżenia.

Witam, muszę zaimplementować odczyt temperatury z czujnika DHT11 poprzez STM32F103RB i wysyłać to poprzez USART(9600b/s). Korzystam z DWT_delay aby mieć opóźnienie w us do inicjalizacji DHT. Problem polega na tym, że mikroprocesor pobiera dane tylko raz i zawiesza się. USART obsługuje przerwania i jest zaimplementowany na buforze kołowym(piny domyślnie PA2-PA3). Dodatkowo mam wyświetlacz 7-segmentowy i docelowo chce na nim wyświetlać dane ( podpięcia PA0-PA1,PA4-PA8) z czujnika(PA9). Po resecie z watchdoga/czarnego buttona na nowo pobrane są dobre dane. W załączniku podsyłam program main z CubeIDE. ProjectMain.zip