microgeek.eu

Męczę się już cały dzień
Chciałbym odpalić OLED-a po I2C ale utknąłem na samym początku czyli komunikacji.

Czytam RM wte i nazad ale coś kiepsko mi idzie.

Funkcja do inicjalizacji:


Zegar dla szyny włączam nieco wcześniej (RCC->APB1ENR |= RCC_APB1ENR_I2C1EN;)
Do I2C1->CR2 wpisuję 8 (tak wynika z dokumentacji).
I2C1->TRISE = 9 też z RM tam jest (1000 ns / 125 ns = 8 + 1)
I2C1->CCR z tym mam największy problem ale dla 100kHz powinno być 80 czy 160?

potem mam funkcje:


Ale i tak wisi mi na pierwszej pętli po wysłaniu start, czyli tu: while( !(I2C1->SR1 & I2C_SR1_SB) );

Prosił bym o jakieś nakierowanie gdzie robię błąd

A to: I2C1->CR2 = I2C_CR2_FREQ_3; // 8MHz HSI faktycznie wpisuje wartość dziesiętną 8 w bity FREQ [5:0]? U mnie nigdzie nie ma makra I2C_CR2_FREQ_3

Ok, dogrzebałem się do tego makra w CMSIS. Tak czy siak coś mi tu nie gra. Ty masz zegar 8MHz, a w CCR ustawiasz 80 i zastanawiasz się nad 160. W RM zaś napisane jest jak byk:

For instance: in Sm mode, to generate a 100 kHz SCL frequency:
If FREQR = 08, TPCLK1 = 125 ns so CCR must be programmed with 0x28
(0x28 <=> 40d x 125 ns = 5000 ns.)

No i wygląda na to, że musisz wpisać wartość dziesiętną 40

Zapytasz pewnie dlaczego 40, a nie 80. Otóż wczytałem się nieco uważniej w RM i dotarło do mnie, że wartość wpisana w CCR ustala czas trwania POŁOWY okresu na pinie SCL. A skoro tak, to CCR (40 dziesiętnie) * 125ns = 5us. 5us wysokiego poziomu + 5us niskiego poziomu daje nam 10us okres, czyli 100kHz częstotliwość.

Aha, zegar dla GPIO podłączanych pod moduł I2C1 również należy włączyć zanim wydasz jakąkolwiek komendę modułowi GPIO. Napisałeś, że włączyłeś zegar dla modułu I2C1, a o GPIO nie wspomniałeś. Dlatego ja o tym wspominam.
Przejrzałem raz jeszcze rejestry i skonfrontowałem z Twoim kodem. Wydaje mi się, że reszta jest ok, ale to się okaże w praniu.

edit:

A jednak coś mi tu nie gra. Zerknij na tę linijkę:

GPIOB->CRL |= GPIO_CRL_CNF6 | GPIO_CRL_CNF7 | GPIO_CRL_MODE6 | GPIO_CRL_MODE7;

Gdy spojrzysz do RM zauważysz, że do CNF6, CNF7, MODE6 i MODE7 wpisuje się wartości od 0 do 3, a Ty wpisałeś...No właśnie, co wpisałeś?


Pozdrawiam

Zegar dla lini GPIO tez mam tylko wlaczony szybciej w system_init().
GPIO dla linii I2C powinny byc ustawione jako alternatywne, otwarty dren.
czyli bity CNF powinny być 11 to własnie ustawia makro GPIO_CRL_CNF6 pojedyncze bity można ustawić np. GPIO_CRL_CNF6_0 i GPIO_CRL_CNF6_1 i wyjdzie na to samo.Podobnie jest z MODE ustawione na 11.

Mnie interesuje konfiguracja AF

For bidirectional Alternate Functions, the port bit must be configured in Alternate
Function Output mode (Push-Pull or Open-Drain). In this case the input driver is
configured in input floating mode

W tab 27 dla I2C jest podane

GPIO configuration: Alternate function open drain

A co CCR to miałem tam 40 (0x28) i też nic.

Jeszce budzi moje wątpliwości że w RM podane jest by skasować bit SB w rejestrze SR1 należy go odczytać

Cleared by software by reading the SR1 register followed by writing the DR register, or by hardware when PE=0

Ale pętla while czyta ten rejestr, no chyba ze przed pętlą mam go permanentnie odczyta np. tmp = I2C1->SR1;

Ok, z bitami w GPIO_CRL się wyjaśniło. O tym kasowaniu bitu SB też czytałem i zasadniczo pętla while czyta ten rejestr, ale można do próby zrobić tak, jak sugerujesz. Zastanawiam się też nad tym sygnałem ACK, który wysyłasz w momencie włączenia modułu I2C1. Kolejna sprawa to część sprzętowa. Masz dołączone rezystory do pinów SDA i SCL?

rezystory podciągające 4k7 mam na SDA i SCL. Bez ACK sprawdzałem (na początku miałem bez) potem dodałem w akcie desperacji
Podepnę tez analizator i zobaczę czy start jest generowany albo czy jest przebieg na SCL.

OK udało się odpalić, OLED działa

Jakie zrobiłem błędy ... a bo podstawa początkującego, pierwsze nie podłączyłem GPIOB :/ choć pisałem że to zrobiłem bo było w kodzie ale za komentowane a potem pokręciło mi się że to na linie I2C są na porcie A.
Ale to nie jedyne wpadki, gdy na oscyloskopie zobaczyłem przebiegi (jak GPIOB załączyłem) to ustawiłem dokłądnie częstotliwość i dla mojej konfiguracji CCR = 0x24 co daje lekko ponad 100kHz ale OLED cały czas pusty, musiałem przerobić nieco funkcję do "zamykania" połączenia czyli wysyłanie STOP.

Poniżej kod może się komuś przyda, to prymitywna wersja w poolingu ale jak to odpaliłem to teraz będę chciał zrobić komunikację I2C na przerwaniach. tak by wywalić wszystkie while() z funkcji I2C.

Kurczaczki ... mam problem uruchomić komunikację na przerwaniach, erratę czytałem, zwiększyłem priorytet dla wyjątku I2C jak sugerowali ale nadal d...



Jeśli miałby ktoś jakieś sugestie, pomysły, działające przykłady ... byłbym wdzięczny.

W dokumentacji HAL jest napisane, że przerwania I2C mają mieć najwyższy możliwy priorytet, by NIC nie zakłóciło pracy I2C.

Teraz nie mam kodu przy sobie (został w domu) ale ustawiłem priorytety na 4G i 4S.
Czyli coś w stylu:

Mam jeszcze przerwanie od TIM1 i EXTI ale TIM1 generuje przerwanie co 2s to raczej nie ma szans by akurat wchodził w drogę, podobnie jak EXTI z przycisku (nie wciskam go).
Jak rozumiem im mniejsza wartość priorytetu, tym jest on ważniejszy, czyli nadanie 1 dla I2C1_EV_IRQn powinno go uczynić najważniejszym (poza tymi o stałych priorytetach jak reset itp.).

@rezasurmar ale to jest transmisja na przerwaniach i działająca na F103?
PS. rejestry są fajne

OLED też mi działa ale w poolingu (teoretycznie to nie problem) ale w ramach zabawy i poznawania STM32 chciałem odpalić I2C na przerwaniach/wyjątkach a potem dodać jeszcze do tego DMA.
A biblioteki jakoś mi nie podchodzą (masa poznawania funkcji, dokumentacja do nich itp.) już wolę przeczytać RM i ustawiać wszystko na rejestrach, chociaż wiem co dokładnie robię ale fakt na początku bardziej upierdliwe jest niż skorzystanie z gotowca.

Debuger to nieocenione narzędzie

Ile to ja się namęczyłem nad tym a problem bardzo prozaiczny, funkcja inicjująca OLED-a przygotowywała tablicę komend i wysyłała ją (wskaźnik na tą tablicę), tyle że gdy funkcja kończyła swoją pracę (tablica była lokalna) to wiadomo co się z nią działo ... obszar pamięci był nadpisywany i w przerwaniu wysyłane były śmieci, choć tak nie do końca bo kilka wartości początkowych się zgadzało co mnie mocno zmyliło

Kolejna spraw to dzięki debugerowi poprawnie napisałem obsługę wyjątku dla I2C.

Jak by kogoś interesowało (tak w skrócie):

P.S. jutro pod palec idzie DMA dla I2C

Z kronikarskiego "obowiązku" dodam że transmisja (nadawanie) I2C w przerwaniu z DMA zrobiona w sumie z DMA łatwiej niż bez bo nie trzeba obsługiwać w zdarzenia TXE, robi to za nas DMA.

Teraz poszukam jakiegoś zegarka i dopiszę odbieranie dla mastera
Jak naskrobię coś co będzie bardziej użytkowe to się podzielę.

Również mam problem z I2C w STM32, moja platforma testowa to chińska płytka z mikrokontrolerem STM32F103RCT6 na pokładzie.
Sam zapis wydaje się że mam opanowany, problem mam natomiast z odczytem. Funkcja która powinna w założeniu odczytać N-bajtów w rzeczywistości odczytuje z układu slave N+1 bajtów. Na oscyloskopie to wygląda tak



Konfigurację I2C jak i portów GPIO z nim związanych użyłem taką jak mi HAL wygenerowało.

I2C programowo zrealizowałem tak:


Przed pierwszym użyciem a po inicjalizacji włączenie I2C


Użycie w programie


I nie rozumiem dlaczego po odczycie ostatniego bitu a przed wysłaniem stopu master jeszcze coś próbuje odczytać.

Może ktoś rzucić okiem na mój problem ?

Na szynie nic więcej nie ma poza GY-86.

Kluczem do rozwiązania zagadki jest:

1. Świadomość obecności bufora (a więc konieczności odczytu dwóch bajtów zamiast jednego, jak w AVR).
2. Prawidłowe posługiwanie się bitami POS i ACK w rejestrze I2Cx->CR1. Zwłaszcza bit POS jest istotny, gdyż to on decyduje, kiedy nastąpi wygenerowanie ACK lub NACK. Jeśli bit jest wyzerowany, NACK/ACK dotyczy aktualnie odbieranego bajtu (wsuwanego do rejestru). Jeśli POS jest ustawiony, wygenerowanie NACK/ACK będzie dotyczyło dopiero następnego bajtu. Bit POS, zgodnie z treścią reference manual, ma być używany wyłącznie podczas odbierania dwóch bajtów. W przypadku jednego lub trzech i więcej bajtów bit ten ma być wyzerowany.

A wracając do bufora - To normalne, że za każdym razem masz o jeden bajt za dużo do odczytu, ponieważ jeden odebrany bajt siedzi w I2Cx->DR, a kolejny w rejestrze przesuwnym. Gdy odczytasz DR, dane z rejestru przesuwnego przenoszone są automatycznie do przed chwilą opróżnionego DR. Stąd ten nadmiarowy bajt. Spróbuj obniżyć ilość odbieranych bajtów o jeden, tzn.: Chcesz odczytać 10 bajtów. Do funkcji odczytującej dane przekazujesz "len" = 10. Wewnątrz funkcji dekrementujesz "len" i tak naprawdę starasz się odczytać 9 bajtów. Efektem będzie odczyt 10 bajtów.