Skocz do zawartości

Przeszukaj forum

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

  • 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 - roboty
    • Projekty - DIY
    • Projekty - DIY (początkujący)
    • Projekty - 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
    • Kosz

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


Znaleziono 88 wyników

  1. 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
  2. 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ź.
  3. 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
  4. 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?
  5. 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
  6. 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?
  7. 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.
  8. 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
  9. 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
  10. 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.
  11. 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.
  12. 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 ?
  13. 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.
  14. 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?
  15. 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)
  16. 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!
  17. 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?
  18. 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
  19. 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.
  20. 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); } }
  21. 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
  22. Cześć! Jako że już po sezonie to postanowiłem opisać tu moją i mateuszm konstrukcję. Robot powstał w ramach rekrutacji do koła naukowego robotyków KoNaR i debiutował na Robotic Arenie 2015. Był to nasz debiut w konstruowaniu robotów, ponieważ wcześniej żaden z nas tego nie robił. Mechanika Głównym założeniem mechaniki robota było wykorzystanie w pełni maksymalnej dopuszczalnej masy oraz skupienie jej w podstawie. W osiągnięciu tego celu pomógł nam projekt Autodesk Inventor, w którym to został wykonany szczegółowy projekt robota uwzględniający wszystkie drobne elementy mechaniczne. Podstawa robota została wykonana z trzech elementów: - ostrze z węglika spiekanego - płytka stalowa 3mm - płytka górna, 2mm, która łączyła dwa elementy wymienione wyżej W płytkach zostały wycięte otwory, w których następnie umieszczone były małe, okrągłe płytki z czujnikami białej linii. Stal była cięta laserowo oraz później frezowana. Napęd robota stanowiły znane i lubiane silniczki Pololu HP z przekładnią 50:1 przykręcone bezpośrednio do podstawy za pomocą dedykowanych mocowań. Podpięte do elektroniki były przy pomocy złączy ARK co umożliwiło ich łatwy demontaż w celach serwisowych. Obudowa robota została wykonana z laminatu 1mm. Na obudowie znajduje się nazwa robota oraz nasze imiona i nazwiska. Obudowa mocowana jest do podstawy za pomocą śrub, a jej elementy są do siebie lutowane. Dach robota wykonaliśmy z 2 mm przeźroczystego szkła akrylowego. Finalnie robot mierzy w najwyzszym miejscu 33,7 milimetra od podstawy do dachu, a od podłoza do dachu 37,2. Jego podstawa ma wymiary 98,9 mm na 99,6 mm. Masa waha się od 490 do 499g w zależności jak bardzo nakarmimy robota przed zawodami Elektronika Priorytetem projektu robota była jego dobra konstrukcja mechaniczna, w wyniku czego wymiary płytki z elektroniką były z góry narzucone. Elektronika została zaprojektowana w programie KiCad po zaimportowaniu wymiarów przeznaczonych na nią z programu Inventor. Elektronika robota dzieli się na dwie płytki: główną, która znajduje się tuż nad podstawą robota oraz dodatkowej, na której umieściliśmy włącznik zasilania, interfejs komunikacyjny oraz złącze na moduł startowy. Płytki połączone zostały ze sobą taśmą FFC. Mała płytka widoczna na zdjęciu nad płytką główną służy nam jako podstawka pod akumulator LiPo 7.4V, którym zasilamy robota. Sercem naszego robota został mikroprocesor STM32F1. Wybór tej rodziny wynikał z łatwości ich programowania przez początkujących. Czujniki odległości wykorzystane w robocie to znane i lubiane cyfrowe Sharpy 40cm. Umieściliśmy je 4, dwa z przodu oraz po jednym na bokach. Na czujniki białej linii użyliśmy dwa KTIRy 0711S. Jak wcześniej wspomniałem zostały one umieszczone na małych płytkach, które umieściliśmy w wycięciach w podstawie. Na sterowniki silników wybraliśmy dwa, podwójne mostki H TB6612. Zostały one dobrane ze względu na ich dobrą wydajność prądową, co umożliwiło nam skuteczne wysterowanie silników Pololu bez obawy o to, że przy pełnym zwarciu mostki ulegną uszkodzeniu. Płytki zostały wykonane metodą termotransferu oraz wyfrezowane za pomocą Dremela i pilników ręcznych. Software Kod robota został napisany w środowisku System Workbench for STM32 (SW4STM32) z użyciem generatora kodu konfiguracyjnego STM32CubeMX. Program podzielony był na dwie sekwencje: startową i walki. W pierwszej ustawiana była konfiguracja algorytmu robota oraz dostępne były funkcje testu czujników (widoczny na zdjęciu poniżej - cztery czerwone diody, które odpowiadały za pokazanie aktualnego stanu czujników) oraz czyszczenia kół (drobna funkcja pomocnicza ustawiająca małą prędkość na kołach). Sekwencja walki załączała się po otrzymaniu przez robota sygnału startowego z modułu. Większa część algorytmu walki opierała się na prostych if-ach z odpowiednio dobranymi nastawami silników w każdym przypadku, co okazało się wystarczające w większości starć. Następnie zostały dodane pewne udoskonalenia, o których już rozpisywać się nie będę Osiągnięcia - II miejsce Robomaticon 2016 - I miejsce Robotic Tournament 2016 - III miejsce Festiwal Robotyki Cyberbot 2016 - II miejsce [Minisumo] oraz I miejsce [Minisumo Deathmatch] Trójmiejski Turniej Robotów 2016 - II miejsce Opolski Festiwal Robotów 2016 - I miejsce Robotic Day 2016 [Praga] A poniżej kilka filmów z udziałem robota: 2Weak4U vs Hellfire 2Weak4U w Wiedniu 2Weak4U vs Dzik 2Weak4U vs Shevron (chyba) 2Weak4U w Deatmatchu [Rzeszów] 2Weak4U vs Szwagier Pozdrawiam i do zobaczenia w następnym sezonie, Aleksander
  23. Witajcie Realizuję komunikację pomiędzy mikroprocesorem STM32F411RE (NUCLEO) a modułem SIM800L. Wykorzystuję do tego interfejs UART. Inicjalizuję go poprzez bibliotekę HAL'a. Samą wymianę danych postanowiłem zrobić ręcznie, odwołując się bezpośrednio do rejestrów UART. Poniżej funkcja inicjalizacyjna: void uart_init(uint32_t baud) { uart_gpio.Pin = GPIO_PIN_9 | GPIO_PIN_10; //TX RX uart_gpio.Mode = GPIO_MODE_AF_PP; uart_gpio.Alternate = GPIO_AF7_USART1; uart_gpio.Speed = GPIO_SPEED_HIGH; uart_gpio.Pull = GPIO_PULLUP; HAL_GPIO_Init(GPIOA,&uart_gpio); usart.Instance = USART1; usart.Init.BaudRate = baud; usart.Init.Parity = USART_PARITY_NONE; usart.Init.StopBits = USART_STOPBITS_1; usart.Init.WordLength = USART_WORDLENGTH_8B; usart.Init.Mode = USART_MODE_TX_RX; HAL_USART_Init(&usart); } Sama komunikacja odbywa się w funkcji "sim_reception", w przerwaniu od timera mikroprocesora. #define SIM_TX_BUF_SIZE 32 #define SIM_RX_BUF_SIZE 32 volatile unsigned char sim_tx_buf[SIM_TX_BUF_SIZE]; volatile unsigned char sim_rx_buf[SIM_RX_BUF_SIZE]; volatile unsigned char sim_tx_len = 0; volatile unsigned char sim_rx_len = 0; enum { handshake, hdsh_resp }; volatile uint8_t sim_states = handshake; #define SIM_HNDSHK "AT\r\n" void sim_reception(void) { //RX //if Receiver not empty flag is set and we have space in rx buffer, we read byte while(USART1 -> SR & USART_SR_RXNE) { if(sim_rx_len < SIM_RX_BUF_SIZE) sim_rx_buf[sim_rx_len++] = USART1 -> DR; //after reading byte we increment buffer length else break; } //TX //if Transmitter empty flag is set and we have data in tx buffer, we send byte while(USART1 -> SR & USART_SR_TXE) { if(sim_tx_len != 0) { USART1 -> DR = sim_tx_buf[0];//send one byte sim_byte_up(sim_tx_buf); //shift one byte up } else break; } switch(sim_states) { case handshake: sim_tx_buf_put(SIM_HNDSHK); sim_states = hdsh_resp; break; case hdsh_resp: break; default: sim_states = handshake; break; } } Na razie chcę wysłać tylko jedno polecenie i odczytać odpowiedź modułu SIM800L. Krótko opiszę nadawanie, które działa bez zarzutu. Wywołuję funkcję "sim_tx_buf_put", która napełnia bufor komendą "SIM_HNDSHK", zdefiniowaną wyżej za pomocą #define. Funkcja bada ile miejsca mamy w buforze i czy wystarczy go jeszcze dla nowego polecenia. Jeśli tak to wstawia je bajt po bajcie i zwiększa odpowiednio zmnienną "sim_tx_len". Nie będe wstawiał kodu tej funkcji, ponieważ działa ona bardzo dobrze, nie mam z nią problemu. Wyżej w kodzie widać, że jest badany stan flagi "Transmitter Empty", gdy się ona pojawi i w buforze Tx są dane przystępuje się do wysyłania danych bajt po bajcie. Po każdym wysłanym bajcie wywoływana jest funkcja "sim_byte_up", która przesuwa bajty bufora "o jeden w górę", czyli sim_tx_buf[0] = sim_tx_buf[1], sim_tx_buf[1] = sim_tx_buf[2] itd. oraz zmniejsza wartość "sim_tx_len" o jeden, następnie wysyłany jest kolejny bajt i tak do opróżnienia bufora. Nadajnik działa jak należy, co pokazuje screenshot z analizatora stanów logicznych. Po wysłaniu wiadomości "AT\r\n" moduł SIM800L odsyła odpowiedź. Zatem flaga "Receiver Not Empty" powinna zostać aktywowana, bufor Rx jest pusty, tak więc coś powinno zostać zapisane w buforze. Jednak nic takiego się nie dzieje. Screenshoty z debugowania. W buforze Rx pojawia się tylko jeden bajt o wartości 127. Dalszych procedur odbioru nawet nie opracowałem, bo skoro w buforze odbiorczym nic nie ma... Nie bardzo wiem z czym jest związany ten problem, próbowałem wyprowadzić Tx i Rx we wszystkich możliwych konfiguracjach, jednak zawsze jest tak samo, nadajnik wysyła bez żadnego problemu a odbiornik nie może nic odczytać. Jeśli ktoś ma jakiś pomysł co może być przyczyną problemu i jak to rozwiązać to byłbym bardzo wdzięczny za pomoc Pozdrawiam mw
  24. Dzień dobry, Piszę program do swojego mikrokontrolera STM32F303VCT6, który wysyła sygnał sinusoidalny na rampie do sterowania laserem. Dodatkowo, ten sam mikrokontroler mierzy napięcie na fotodetektorze oraz mnoży te dwa sygnały - sinusoidalny i odbierany. Do tej pory wygląda na to, że wszystko działa. Potrzebuję jednak zaimplementować jeszcze filtr dolnoprzepustowy, który po wymnożeniu tych dwóch sygnałów, przefiltruje mi sygnał tak, aby na innym pinie skonfigurowanym pod przetwornik cyfrowo-analogowy "obetnie" mi żądane częstotliwości. Szukając w internecie implementacji takiego filtra nie uzyskałem satysfakcjonującej mnie odpowiedzi. Czy ktoś mógłby dokładnie wyjaśnić jak to zrobić? A może jest jakaś tego typu funkcja przy wykorzystaniu bibliotek HAL? Z góry dziękuję za pomoc!
  25. To mój pierwszy post na forum więc witam wszystkich Chociaż czytelnikiem jestem już od dawna;p Posiadam płytkę stm32f411re i próbuję przetestować akcelerometr jak w tytule(Był dołączony do kursu STM32F1). Do pomocy korzystałem z obu kursów STM32: F4 (HAL) oraz Kurs F1. Próbowałem już różnych konfiguracji interfejsu, różnych pinów itp. jednak ciągle nie mogę nawet odczytać rejestru WHO_AM_I. Konfiguracja I2C: static void MX_I2C1_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; if (HAL_I2C_Init(&hi2c1) != HAL_OK) { Error_Handler(); } } Adres układu: #define LSM303D_ADDR (0x3a << 1) (Próbowałem też 0x3c oraz opcji bez przesunięcia bitowego) Pętla główna: while (1) { HAL_I2C_Mem_Read(&hi2c1, LSM303D_ADDR, 0x0f, 1, &who_am_i, 1, 100); } Gdzie 0x0f to adres rejestru WHO_AM_I z dokumentacji zamieszczonej w kursie, a &who_am_i to adres zmiennej globalnej typu uint_8t. Dokumentacja LSM303D Układ zmontowany poprawnie, SDA i SCL podpinam pod piny ustawione w Cube, dodatkowo masa i 3v3 do Vin. Oczekiwana wartość rejestru to wg dokumentacji 0x49, jednak śledzenie zmiennej w STMStudio zawsze wskazuje 0. Zaznaczę jeszcze, że próbowałem też odczytywać konkretne wartości z akcelerometru po uprzedniej konfiguracji, ale nigdy nie zadziałało. Zakładam więc, że jest jakiś podstawowy problem z komunikacją układów, dlatego chcę zacząć od poprawnego odczytu who_am_i. Dajcie znać, jeśli czegoś brakuje w opisie. Dzięki.
×
×
  • Utwórz nowe...