[Rozwiązano] STM32F401RE L3GD20H - konfiguracja przerwań I2C w HAL

Witam, mam problem z opanowaniem przerwań na mikrokontrolerze stm32f401re. Próbuję odczytać pomiary z żyroskopu l3gd20h. Pomiar blokujący działa bez zarzutu, kod załączam. Problem w tym że potrzebuję pomiar nieblokujący i chciałem to zrobić na przerwaniach. Niestety tu pojawia sie problem bo nie działa mi to prawidłowo, są same zera. Specjalistą nie jestem i nie mam pojęcia jak to zrobić. Ktoś wie może co źle robię i byłby w stanie mnie poprawić? Nie znalazłem żadnego poradnika odnośnie przerwań i2c na stm z użyciem bibliotek hal, albo po prostu nie potrafię szukać. Kod bazujący na przerwaniach również załączam. Dodatkowo dodaje też screeny z konfiguracji w cube.
Z góry dziękuję za odpowiedź, Patryk.

Odczyt blokujący który działa:



Odczyt z przerwaniami:

Wywołujesz HAL_I2C_Mem_Write_IT a callbacka Tx Complete brak. Za to jest Rx Complete. Wydaje mi się, że w tym stanie rzeczy callback nigdy nie będzie wywołany.
Rozumiem, że HAL_I2C_Mem_Read_IT wewnątrz HAL_I2C_MemRxCpltCallback ma zapewnić ciągłe odpytywanie czujnika.

Tak, ma na celu zapętlić pomiar. Nie wiem w jakim celu miałbym używać przerwania od wysyłania. Bawiłem się już wcześniej z tym przerwaniem i uruchamia się, zapalałem diodę wraz z wejściem w przerwanie. Z kolei przerwanie od odebrania w ogóle się nie uruchamia i nie potrafię sobie odpowiedzieć dlaczego.

patrgk napisał:

Nie wiem w jakim celu miałbym używać przerwania od wysyłania

Pewnie po to, żeby się wywołało po uruchomionym przez Ciebie wysyłaniu. O tu:

HAL_I2C_Mem_Write_IT(...)

Dopiero w callbacku od wysłania możesz wywołać pierwszy odczyt. Potem w callbacku od odczytu możesz sobie odczytać co dostałeś i ewentualnie wywołać kolejny zapis/odczyt.

Zadziałało, dziękuję za pomoc. Ale pojawił sie kolejny problem z przerwaniami. Ogólnie w projekcie używam 3 przerwań od timerów, przerwań od uarta, przerwań od gpio i do tego doszło teraz i2c i... zaczęło sie wszystko sypać. Wszystkie przerwania są o jednym priorytecie i podejrzewam że w tym tkwi problem, nigdy nie zmieniałem priorytetów w programach bo nie byłło mi to konieczne. Po uarcie zamiast prawidłowej ramki zaczeły wysyłać się jakieś znaczki. Czy ustawienie priorytetów załatwi problem czy może jest jakiś inny powód że przestało to działać? Da się jakoś spowolnić to przerwanie od i2c, żeby nie wykonywało się tak często? Macie jakies "pro tipy" jak sobie radzić z takimi sytuacjami?

Edit: Ustawiłem wiekszość przerwań z priorytetem na 1, a uarta zostawiłem 0. Dalej wysyłają się znaczki chociaż jest ich już więcej. Ramka tranimsyjna składa się z 26 znaków. Załączam zrzut odbieranej ramki

patrgk napisał:

Czy ustawienie priorytetów załatwi problem czy może jest jakiś inny powód że przestało to działać?

Definitywnie to drugie. Na 99% Twoje przerwania trwają zbyt długo lub użyłeś w nich (pośrednio lub bezpośrednio) funkcji blokujących/oczekujących/pollingu. Jeśli zaczniesz kombinowac z priorytetami bez zrozumienia przyczyny, to tylko wpędzisz się w więcej kłopotów, a niczego nie rozwiążesz.

Do tego nie wiem do czego używasz przerwań od GPIO, ale zwykle nie nadają się one do niczego sensownego, a już definitywnie nie nadają się do obsługi przycisków.

Dodano po 54 [sekundy]:

patrgk napisał:

Da się jakoś spowolnić to przerwanie od i2c, żeby nie wykonywało się tak często?

Przecież sam zdecydowałeś, że chcesz mieć transmisję I2C na okrągło...

Do UARTa lepiej użyć DMA, zawsze to zmniejszy obciążenie, choć to i tak nie będzie rozwiązanie, a tylko "przypudrowanie" problemu.

Zastosowanie porad do tematu