przemof-s

Witam, próbuję uruchomić akcelerometr LIS3DHH ( https://www.st.com/en/mems-and-sensors/lis3dhh.html) na zestawie Nucleo F411RE (https://www.st.com/en/evaluation-tools/nucleo-f411re.html). Czujnik mam w postaci adaptera STEVAL-MKI180V1 (https://www.st.com/en/evaluation-tools/steval-mki180v1.html). Konfigurację dla mikrokontrolera generuję za pomocą CubeMX 5.0.1 z bibliotekami HAL dla rodziny STM32F4, w wersji 1.23.0. Próbę uruchomienia czujnika rozpocząłem od wykorzystania bibliotek: https://github.com/STMicroelectronics/STMems_Standard_C_drivers/tree/master/lis3dhh_STdC, a dokładnie od przykładu: read_data_simple.c. Po dużej liczbie nieudanych prób komunikacji, maksymalnie uprościłem przykład. Aktualnie próbuję odczytać wartość rejestru WHO_AM_I. Adres rejestru to: 0x0F. Podczas odczytu danych, bit SMB adresu powinien mieć wartość 1, więc modyfikuję adres rejestru do wartości 0x8F. Wartość rejestru WHO_AM_I powinna wynosić 0x11, a ja otrzymuję wartość 0x00. Wszystkie linie SPI są sprzętowo podciągnięte do plusa zasilania, za pomocą wewnętrznych rezystorów mikrokontrolera. Korzystam z SPI2. Jego konfiguracja to: CPOL = High, CPHA = 2 Edge, prędkość: 1.3125 Mbits/s. Sygnał CS jest generowany programowo. Poniżej przedstawiam fragment kodu źródłowego odpowiedzialnego za inicjalizację SPI oraz próbę odczytania rejestru WHO_AM_I. Inicjalizacja SPI: void MX_SPI2_Init(void) { hspi2.Instance = SPI2; hspi2.Init.Mode = SPI_MODE_MASTER; hspi2.Init.Direction = SPI_DIRECTION_2LINES; hspi2.Init.DataSize = SPI_DATASIZE_8BIT; hspi2.Init.CLKPolarity = SPI_POLARITY_HIGH; hspi2.Init.CLKPhase = SPI_PHASE_2EDGE; hspi2.Init.NSS = SPI_NSS_SOFT; hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32; hspi2.Init.FirstBit = SPI_FIRSTBIT_MSB; hspi2.Init.TIMode = SPI_TIMODE_DISABLE; hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE; hspi2.Init.CRCPolynomial = 10; if (HAL_SPI_Init(&hspi2) != HAL_OK) { Error_Handler(); } } [Próba odczytu zawartości rejestru WHO_AM_I (zawarte w funkcji main): MX_GPIO_Init(); MX_SPI2_Init(); HAL_Delay(10); HAL_StatusTypeDef status; uint8_t reg = 0x0F; // Adres rejestru WHO_AM_I uint8_t bufp[3]; uint16_t len = 1; reg |= 0x80; // Informacja, ze przeprowadzany bedzie odczyt danych HAL_GPIO_WritePin(SPI_CS_GPIO_Port, SPI_CS_Pin, GPIO_PIN_RESET); // Aktywacja SPI status = HAL_SPI_Transmit(&LIS3DHH_HANDLE, ®, 1, 1000); // Wyslanie adresu do odczytu status = HAL_SPI_Receive(&LIS3DHH_HANDLE, bufp, len, 1000); // Odbior zawartosci adresu HAL_GPIO_WritePin(SPI_CS_GPIO_Port, SPI_CS_Pin, GPIO_PIN_SET); // Dezaktywacja SPI W załączniku przedstawiam przebiegi uzyskane z analizatora stanów logicznych, plik konfiguracyjny dla CubeMX oraz kod źródłowy programu testowego. Dodam, że testy przeprowadzałem na dwóch czujnikach, oraz dodatkowo na zestawie z mikrokontrolerem STM32F103 (blue PCB). Modyfikowałem na wiele sposobów konfigurację SPI oraz odczyt rejestrów. Efekt za każdym razem taki sam. Czy ktoś ma pomysł co robię nie tak, że za każdym razem otrzymuję wartość zero z rejestru WHO_AM_I? Test_LIS3DHH_F4.zip

Kto co lubi, dlatego właśnie istnieją alternatywne rozwiązania Nie będziemy chyba rozważać wyższości jednego programu nad drugim, bo żaden nie jest lepszy czy gorszy. Każdy ma swoje plusy i minusy. Jednym odpowiada "to" a innym "tamto". Jak już powstanie wspomniany tutorial do vi i gcc, to również będę nim zainteresowany Natomiast co do używania trzeciej formy osobowej, nie jest to potrzeba, a raczej nawyk będący spadkiem po pisaniu "oficjalnych" dokumentów, w których nie jest zalecane stosowanie formy pierwszoosobowej.

Przedstawiony tutorial dotyczy głównie konfiguracji Code::Blocks, umożliwiającej pisanie i debugowanie kodu w języku C/C++, m.in. dla mikrokontrolerów z rodziny STM32. Opis zrealizowany został na przykładzie płytki STM32F4DISCOVERY. Jednak przedstawioną metodę można wykorzystać do konfiguracji innych układów z tej rodziny. Prezentowany opis zawiera informacje dotyczące konfiguracji: Code::Blocks + GCC ARM Embedded Toolchain + OpenOCD + STM32CubeMX + STM32F4Discovery + Linux. Dla układów STM32 jest już dostępne gotowe, zintegrowane środowisko programistyczne: System Workbench for STM32 (SW4STM32), który bazuje na środowisku Eclipse. Jaki jest więc sens samodzielnego składania środowiska? Autor nie lubi środowiska Eclipse, nie odpowiada mu jego rozmieszczenie okien, obsługa, po prostu źle mu się w tym środowisku pracuje. Jest to wystarczający powód. Ze względu na dużą objętość tutoriala, został umieszczony w załączniku, w postaci pliku pdf. Dodatkowo umieszczono dwa pliki *.zip. Jeden zawierający przykładowy projekt utworzony na podstawie tutoriala. Drugi zawierający strony www, do których odnosi się tutorial (na wypadek ich "zniknięcia" z sieci internet). stm32f4_discovery.zip Tutorial Code-Blocks.zip Tutorial Code-Blocks, Rev. 0.4.pdf