[STM32F4][C] - odczyt wartości za pomocą DMA I2C

Witam
chciałem wykorzystać DMA do odczytywania wartości z akcelerometru poprzez I2C. Na stronie ST udostępniono przykładowy kod wykorzystujący DMA. Poniżej udostępniam przykład funkcji wysyłania danych. No i niby wszystko rozumiem, oprócz jednej podstawowej rzeczy. W którym miejscu jest to niby szybsze niż zwykły transfer poprzez i2c, tzn. wysyłanie, oczekiwanie,... Tutaj też procesor nie ma odpoczynku są pętle oczekujące while. Czy po przerobieniu tego kodu tak aby było wywoływanie przerwanie od zakończenia transferu z użyciem DMA miałoby to sens i można by usunąć np tę linijkę
?

Fragment kodu funkcji wysyłającej przez I2C:


Pozdrawiam
A.T.

A.T. napisał:

W którym miejscu jest to niby szybsze niż zwykły transfer poprzez i2c

W żadnym.

A.T. napisał:

Czy po przerobieniu tego kodu tak aby było wywoływanie przerwanie od zakończenia transferu z użyciem DMA miałoby to sens

Teoretycznie tak, choć nigdy w praktyce nie sprawdzałem - nie miałem potrzeby.

Męczyłem się swego czasu z I2C w procesorze F1 - bez użycia DMA nie chciało działać. Podobno jest coś skopane w implementacji tego interfejsu w STM32. Może właśnie dlatego przykłady z ST (ogólnie raczej słabej jakości) dla I2C używają zawsze DMA.

Pozdrowienia,
m.ki

m.ki napisał:

Męczyłem się swego czasu z I2C w procesorze F1 - bez użycia DMA nie chciało działać.

Eeeee, ja uruchomiłem I2C normalnie bez DMA zarówno w F1 (STM32F103) jak i w F4 (STM32F407) - żadnych problemów nie miałem w tych 2 procesorkach...

Mi także się udało uruchomić na F4 bez problemu normalnie I2C:) Chcę uruchomić te I2C z DMA bo myślałem, że przy odczycie z akcelerometru to będzie lepsze. A mógłby się ktoś z Was mi podpowiedzieć, jak najlepiej zorganizować odczyt takiego czujnika. Posiada on opcję zewnętrznego przerwania gdy dane na I2C są gotowe do odczytu. Na chwilę obecną ciągle badam flagę gotowości danych. Jednak potrzebuję coś wydajniejszego, bo odczyty muszę robić z częstotliwością około 250Hz. Może się mylę i wcale nie potrzebuję DMA:) Akcelerometr to BMA180.
Dzięki i pozdrawiam

A.T. napisał:

Mi także się udało uruchomić na F4 bez problemu normalnie I2C:) Chcę uruchomić te I2C z DMA bo myślałem, że przy odczycie z akcelerometru to będzie lepsze. A mógłby się ktoś z Was mi podpowiedzieć, jak najlepiej zorganizować odczyt takiego czujnika. Posiada on opcję zewnętrznego przerwania gdy dane na I2C są gotowe do odczytu. Na chwilę obecną ciągle badam flagę gotowości danych. Jednak potrzebuję coś wydajniejszego, bo odczyty muszę robić z częstotliwością około 250Hz. Może się mylę i wcale nie potrzebuję DMA:) Akcelerometr to BMA180.
Dzięki i pozdrawiam

Akcelerometru nie znam, więc szczegółowo nie pomogę.

Na pewno warto wykorzystać przerwanie zewnętrzne i w jego obsłudze uruchamiać transfer I2C.
Jeśli danych jest dużo, transfer I2C można podzielić na dwie części, tak jak to sugerowałeś w pierwszym tekście - do uruchomienia DMA i po jego zakończeniu.
W przerwaniu zewnętrznym pierwsza część.
W przerwaniu "koniec transferu" druga część.
Jeśli danych jest mało, nie bawiłbym się w podział i przerwanie "koniec transferu".
Jeśli to wszystko dalej będzie niewydolne, czeka Cię chyba obsługa I2C kompletnie na przerwaniach, czyli przerwaniowa obsługa każdego zdarzenia - wszędzie tam, gdzie są pętle oczekiwania. Raz to robiłem (na innym procku) i nie powiem, żebym marzył o powtórce.

Na to wszystko jeszcze trzeba nałożyć ew. problemy, jeśli na tym I2C wisi jeszcze jakiś inny układ, obsługiwany bezprzerwaniowo. Wtedy trzeba stosować jakieś sekcje krytyczne lub inną kontrolę dostępu do zasobu.

Pozdrowienia,
m.ki

Dziękuję za odpowiedź. Postaram się dzisiaj coś napisać. Jak będę miał problemy to się jeszcze zgłoszę Niestety na tym samym I2C wisi jeszcze żyroskop ITG3200 który także muszę odczytywać z tą samą częstotliwością:/ Jeśli ktoś ma jeszcze coś do powiedzenia, jakąś podpowiedź to bardzo proszę pisać.

A.T. napisał:

Dziękuję za odpowiedź. Postaram się dzisiaj coś napisać. Jak będę miał problemy to się jeszcze zgłoszę Niestety na tym samym I2C wisi jeszcze żyroskop ITG3200 który także muszę odczytywać z tą samą częstotliwością:/ Jeśli ktoś ma jeszcze coś do powiedzenia, jakąś podpowiedź to bardzo proszę pisać.

Jeśli dokładnie z taką samą, to najlepiej po zakończeniu odbioru danych z jednego uruchamiaj odczyt z drugiego. Wtedy w miarę bezpiecznie możesz założyć, że nie będzie konfliktu.
Jeśli tylko z mniej więcej tą samą częstotliwością, to musisz chronić program przed konfliktem - na przykład w trakcie odbioru danych z DMA przyjdzie zewnętrzne przerwanie "dane gotowe" z drugiego układu - jeśli program w obsłudze tego przerwania wyśle START, to rozłoży transmisję I2C na łopatki.

A najbezpieczniej użyj drugiego I2C, jeśli możesz.

Pozdrowienia,
m.ki

W koncu mogę wyrazić swój żal do ST!!...

W STM32F1 peryferial I2C jest dokumentnie spie-przo-ny w samym krzemie. Ponad 2 tygodnie walczyłem z stabilnością odczytu z dwóch akcelerometrów i ADC wiszących na kabelku. Ciężko we znaki dał mi się bug powodujący, ze po "misplaced stop" (więc de facto byle durne zakłócenie linii), cały peryferial wisi az do jego resetu!! co wymusiło na mnie uzycie dedykowanego timera pełniącego rolę watchdoga odczytu i to resetowany 'co krok' (czyli ustaw tryb master, wd reset, czekaj na flage, wyslij adres wd reset, czekaj na flage...) i tak przez caly cholerną transakcję! - w sumie 2 2bajtowe zapisy i 8 2bajtowych odczytów. Co wazne - dzięki temu, ze istnieje drugi bug - niektóre zdarzenia z I2C muszą zostać obsłużone natychmiast, bo inaczej rozwala sie transmisja - zostałem zmuszony do uwalania wszystkich przerwań na czas praktycznie całej procedury transferu.
Czare goryczy przelał fakt, ze ja te dane z czujników musiałem zaciągać 50 razy na sekundę, sekwencyjnie, i mialem ogolnie 'nie gubić próbek'...
DMA lekko rozwiązało problem z drugim bugiem - przerwania mozna bylo włączyć spowrotem juz po dostaniu flagi ADDR... Ale co k'wa z tego; pierwszego buga to nie omija, więc watchdog został, tym razem czekający na TCIF od DMA.
Wniosek: nigdy!! nie uzywaj I2C w STM32F1 jesli chcesz uniknąć kombinacji, wielotygodniowych testów, przeróbek softu i innych szopek.
No może to nie dotyczy sytuacji kiedy ma się pewność, że 'coś' nigdy nie wygeneruje paskudnego misplaced stop'a na magistrali...

U mnie skonczylo się to dodatkowym wątkiem, stosunkowo długo trwającą sekcją krytyczną w tym wątku, zmarnowaniem timera i jednego kanału DMA (czego nie planowałem), a przez sekcję krytyczną zacząłem gubić próbki/przerwania z innych peryferiów co zmusiło mnie do nieziemskich kombinacji zeby nie gubić danych lub unikać rozsynchronizowania z strumieniem wejściowym (UART).

Miesiąc w kąt na walkę z peryferialem i implementacją mechanizmów łagodzących w potężnym kodzie.

A wystarczyło dołożyć za dolara ko-procesor w postaci LPC1111, który robiłby nic innego tylko interfejsował I2C<->SPI...

Z I2C to miałem też inne bardzo niemiłe wspomnienia, tym razem ze slave'm MCP23008, które to cholerstwo też wisiało kompletnie po najmniejszym zakłóceniu na magistrali. Skonczyło się na jeżdżeniu po Polsce do klientów i rozkminianiu 'co jest do ....' że na stole działa, a u klienta nie. Detektor 'wiszenia', watchdog i reseter (o ja mądry podłączyłem pin RESET scalaka do procka na projekcie...) rozwiązał komplikacje.

I2C STANOWCZE NIE! ;]

PS
Zeby nie było - pomysł I2C na kabelkach nie był mój, musiałem się dostosować... Sam nigdy nie popełniłbym takiej głupoty...

Nsvinc mógłbyś powiedzieć jak ty byś zrealizował odczytywanie akcelerometru i żyroskopu z częstotliwością ok 250Hz. Oby dwa wiszą na tej samej szynie I2C. Próbuję coś z DMA ale za bardzo nie mam pomysłu jak to zrealizować. Najpierw jakoś muszę coś wysłać do czujników, nie wiem jakim sposobem, chyba nie przez DMA. A DMA użyć tylko do odczytu? Mam jeszcze do dyspozycji przerwania zewnętrzne z czujników kiedy dane są gotowe do przesłania. Liczę, że coś podpowiesz:) Jakiś przykładowy fragment kodu też byłby mile widziany.
A co do Twoich problemów z I2C to współczuje i mam nadzieję, że mnie takie ominą
Pozdrawiam

Jeśli scalaki masz na płycie i mozesz zagwarantować brak zakłóceń na magistrali, to się baw tym I2C w STM32 ;] "Ludziom działa"...
Jeśli chcesz rozwiązanie wyjątkowo proste i odporne, to pozostaje przejściówka I2C<->SPI (lub UART) na oddzielnym procku w którym I2C nie ma błędów, czyli np. LPC1111.
W dsPICach I2C też ma błędy, i ogólnie w prockach nie-Philipsowych I2C ma błędy - a to sie flaga nie ustawia, a to nie widzi ACK, a to peryferial wisi przy zakłóconej transmisji, itp itd...

250Hz to dosyc duża częstotliwość odczytu - w STM32 koniecznie potrzebujesz DMA. I watchdoga na timerze, który zaoszczędzi wycieczek do wk**wionych klientów...

Oto małpy w cyrku:




Zapis jest obslugiwany bez DMA, bo mialem 'mało do zapisania', za to odczyty juz idą przez DMA...

Czy opisane przez Cibie nsvinc błędy I2C dotyczą także STM32F4 i F0?

Dla F4 niestety tak - errata sheet, str. 16 pkt 2.3.2 - najbardziej denerwujący bug nie został w żaden sposób poprawiony w stosunku do F1. W F2 - to samo.
Wszędzie gdzie jest ten zonk będą działy się cyrki gdy magistrala zostanie jakkolwiek zakłócona, w tym:
- stop w trakcie trwania transferu bajtu (nie wazne czy adres czy dane)
- stop w ack slocie
- stop po stop (czyli w trakcie trwania stanu idle)
Zeby peryferial sie nie wywalił, stan stop ma prawo wystąpić tylko i wyłącznie po ack slocie na koniec przesyłu bajtu.
Rozgrzewałem oscyloskop do czerwoności rozkminiając ten wtf ;/

Nie testowałem I2C fizycznie w innych prockach niż F1, ale zakładam, że skoro błąd w erracie jest opisany w sumie identycznie dla F2 i F4 co dla F1, to problem jest tak samo identyczny.

Poprawili za to bug nr 2, z rozwalaniem transmisji jesli niektóre zdarzenia z I2C nie zostaną obsłużone natychmiast - ale co z tego, skoro durny watchdog musi być zeby po losowym czasie transmisja nie zdechła.

Jest tak naprawde jeden jedyny sensowny patent zeby w 99% się errora pozbyć - linię SCK popędzać push-pullem zamiast OD. Ciężko zakłócić na sztywno wystawiony stan. Co jeszcze nie znaczy, że to niemożliwe, niestety - sprawdzałem...

Ogólnie mogę stwierdzić, że I2C nie nadaje się w zaden sposób do pracy w środowisku nawet najdelikatniej zakłóconym. Nie spotkałem takiego kontrolera który potrafiłby skutecznie wykryć błędy magistrali w celu zresetowania siebie i slave'ów. Dodatkowo, I2C daje zero weryfikacji danych, nie stosuje się zadnych wyższych protokołów pozwalających wykryć/naprawiać przekłamania bitów, nie ma sum kontrolnych, a master musi wypluć ACK zanim będzie miał możliwość zeryfikować poprawność otrzymanego bajtu.
To wszystko czyni I2C bezużytecznym do profesjonalnych zastosowań...

Gdy zajmowałem się tamtym nieszczęsnym urządzeniem, rozważałem wymianę procka na właśnie F2 lub F4, co też natychmiast odrzuciłem ze względu na to, że w peryferiach nie poprawili praktycznie nic.

Więc bierzesz potężnego CM4F do mocożernych operacji DSP a kończysz sekcją krytyczną trwającą pół wieczności po to zeby przetransferować sobie kilka bajtów.

Z niecierpliwością również czekam na taki procesor od ST, gdzie w koncu będzie prawidłowo działać dostęp multimaster do FSMC... Od 5 lat się nie doczekałem ;/

Bardzo Ci dziękuję za kody Nsvinc:) Troszkę je będę musiał zmienić bo potrzebuję dla F4. Gdybyś jeszcze mógł powiedzieć co robią funkcje: cpsie(0); cpsid(0); intermission();
Czy te cpsie i cpsid to __enable_irq() i __disable_irq() ?
Oraz gdybyś jeszcze mógł pokazać i2cDmaStart(data,size);
I jeśli chodzi o samą obsługę czujnika to w przerwaniu zewnętrznym z czujnika mam ustawiać jakąś flagę, a w pętli głównej po spełnieniu tej flagi wywoływać Twoją funkcję i2cRead czytającą dane z czujnika?

cpsid i cpsie to są (chyba) odpowiedniki __disable_irq() i __enable_irq(). W sumie w tych funkcjach jest tylko po jednej instrukcji asma, odpowiednio cpsie i cpsid.

Reszta kodu o który pytasz:


intermission() to funkcja która na chwilę włącza przerwania w 'bezpiecznym' miejscu, żeby przerwania które są pending mogły się wykonać.

Cytat:

I jeśli chodzi o samą obsługę czujnika to w przerwaniu zewnętrznym z czujnika mam ustawiać jakąś flagę, a w pętli głównej po spełnieniu tej flagi wywoływać Twoją funkcję i2cRead czytającą dane z czujnika?

Dokładnie tak. Albo jeśli masz dostępnego OSa, to wystarczy wątek (tak jak w moim przypadku - caly ten kod który udostępniłem chodzi u mnie z wątka).

Można założyć, że dla F4 nie jest potrzebna sekcja krytyczna i wyłączanie przerwań, z racji braku buga nr 2. Sprawdz czy działa bez wyłącznania przerwań...

Marek_Skalski napisał:

Lepiej używać do tego SPI @10MHz przez DMA startowane z przerwania.

Ja również używałem SPI do komunikacji z czujnikami MEMS tj. akcelerometrem BMA180 i żyroskopem L3G4200D gdzie częstotliwość odczytu wynosiła 1kH:
https://www.elektroda.pl/rtvforum/topic2364255-0.html

nsvinc napisał:

Zeby nie było - pomysł I2C na kabelkach nie był mój, musiałem się dostosować... Sam nigdy nie popełniłbym takiej głupoty...

Czy budowałeś układ z komunikacją przez I2C na PCB? I czy opisane przez Ciebie problemy dalej występowały?

Qrcze - a mnie się jakoś udało obsłużyć I2C na STM32F107.
Wszystko na przerwaniach.
Trochę głupot owszem w implementacji jest - o ile pamiętam po odebraniu 2 bajtów, zawsze dosyłał trzeciego, bo nie można było wygenerować NACK'a na czas, ale poza tym działało.
Zrobiłem obsługę HD44780 przez PCF8574 (tryb 4-bitowy).
Ale SDA i SCL są podciągnięte do 5V.
Na magistrali wisi też pamięć EEPROM.
No, ale nie testowałem w warunkach silnie zakłóconych... (pytanie co to znaczy silnie zakłócone).

Nsvinc - > Myślisz, że to ogólnie jest słaba odporność I2C jako protokołu/interface'u? Czy tylko STM? Może zejście do 3V3 pogarsza sprawę?
Jak do tej pory często wykorzystywałem ten interfejs i wszystko działało (głównie na PIC'ach, 5-voltowy).

Interfejs który operuje na wyjściach open-drain nie może być odporny na zakłócenia "z definicji"...

4\/3!!

felekfala napisał:

Czy budowałeś układ z komunikacją przez I2C na PCB? I czy opisane przez Ciebie problemy dalej występowały?

Unikam I2C jak ognia w swoich konstrukcjach. Tak jak wspomniałem wcześniej, miałem przypadek wywalającego się I2C na płytce. Zakłócenie wygenerowane przez typowy przekaźnik 12V/230VAC 16A powodował absolutny zwis MCP23008...

Jado_one napisał:

Myślisz, że to ogólnie jest słaba odporność I2C jako protokołu/interface'u? Czy tylko STM? Może zejście do 3V3 pogarsza sprawę?
Jak do tej pory często wykorzystywałem ten interfejs i wszystko działało (głównie na PIC'ach, 5-voltowy).

Jedno i drugie. Nie odporny interfejs + błędy w krzemie peryferiala (czy to w procku, czy w scalaku typu RTC czy expander) to dosyc nieprzyjemna mieszanka. A to do jakiego napięcia podciągasz linie, jest mniej istotne. Bardziej istotne jest, jakim prądem. W eksperymentach wyszło że 3mA podciągania jeszcze ma sens, 10mA już nie. Co nadal nie zmienia faktu, że

Freddie Chopin napisał:

Interfejs który operuje na wyjściach open-drain nie może być odporny na zakłócenia "z definicji"...

Nic dodać nic ująć.

Typowe zastosowanie I2C tylko pogarsza sprawę, bo nie ma żadnych mechanizmów weryfikacji danych. Spotkałem się z przypadkiem eeproma po I2C, którego nie dało się opanować w lekko zakłóconym środowisku. Zapis 0x55 pod adres 0 konczył się zapisem 'czegoś' pod 'jakiś' adres... Odczyty taka sama szopka...

Znacznie lepszy od I2C jest 1wire. Niby też open-drain, ale dobrze napisany soft pozwala na uniknięcie przetwarzania przekłamanych pomiarów, ponowienia, itp - bo istnieją możliwości weryfikacji. Również dzięki resetowi magistrali, nie ma problemów z tym że 'coś wisi i nie gada'.
1wire pędzony UARTem chodzi u mnie jak żyleta nawet na przesadnie długim (100m) kablu - podciąganie 2k2r do 3V.

Jeszcze raz dziękuję Ci nsvinc za kody:) Spróbuję także bez wyłączania przerwań i napiszę czy się tak da.

@Marek_Skalski
Problem w tym, że specjalnie kupiłem i sprowadziłem z Francji ten moduł IMU. Trochę za niego zapłaciłem:/ Z datasheetów czujników wynikało, że oba mają I2C oraz SPI. To myślałem, że nie będzie problemu. A płytka została tak zaprojektowana, że pominięto SPI, wychodzi tylko I2C i przerwania dla każdego czujnika. Poniżej foto. A same czujniki posiadają dość dobre parametry. Jakoś bardziej im wierzę niż zamkniętym w jednej obudowie LSM330DLC:)

Hehe ale moduły... przyznaj się ile za to dałeś, i czy taniej by nie wyszło takich modułów wyprodukować u siebie - co ważne, szyte na miarę.
W życiu bym takiego czegoś nie kupił ;] Wystarczy wspomnieć, że kiedys dosyc popularne radyjko oparte o scalak NRF905 w postaci modułu kosztował ponad 4 dychy. Sam scalak kosztuje niecałe 2 dolary... Licząc nawet koszty płytek w satlandzie, radio kosztowało mnie ponad 2 razy taniej, niż jakby kupić moduł. I tak jest przeważnie ze wszystkimi modułami na rynku...

Ehh, no muszę Wam co do ceny przyznać rację. Kosztował ponad 100zł. Jedynie co mnie trochę ratuje to to, że i tak bym sam takich czujników nie przylutował, nawet na fabrycznie wykonanej płytce. Nie mam hotaira. Tutaj przynajmniej są pewnie przylutowane i w miarę prosto(znaczy się równo przylegają do płytki). Wcześniej używałem analogowego akcelerometru i żyroskopu MMA7361 i LPR510AL + ADC MCP3208 na SPI. I przyznam, że z tym nie było takich problemów. Głównie skusiły mnie małe wymiary modułu.

Co do SPI w ITG3200 to faktycznie nie posiada. Mój błąd. Widocznie zasugerowałem się akcelerometrem.

Tego i tak nie warto lutować hotem. My kładziemy QFNy ręcznie. Tak samo LGA. Dobry topnik typu RMA i tak samo dobra cyna (nie RoHSowe badziewie) i przylutujesz ogólnie wszystko oprócz BGA...

Niestety mało który czujnik MEMS posiada obecnie SPI. Freescale ma mało takich modeli w ofercie, ADI jest strasznie drogi. ST ma MEMSy które w większości obsługują SPI lub I2C wybieralne pinem....

Spróbuję coś na tym obecnym zrobić i jak nie będzie wychodziło to pomyślę nad innym czujnikiem, np tym LSM303DLC) jeśli przekonujecie, że taki dobry:)
Mam jeszcze tylko jedno pytanie do nsvinc. W jaki sposób podajesz subaddress gdy coś odczytujesz z jakiegoś układu. Bo przecież oprócz adresu układu trzeba jeszcze podać miejsce z którego rozpocząć odczyt. Ja to miałem zrealizowane do tej pory przy zwykłej obsłudze I2C tak:
-START
-ADDRES + WR_bit
-SUBADDRESS
-START
-ADDRESS + RD_bit
-pętla z odczytywaniem n bajtów
-STOP

Czy powinienem w taki właśnie sposób zmodernizować Twoją funkcje i2cReadDMA? Bo raczej z powodu stopu na końcu funkcji i2cWrite nie można jej najpierw użyć do wpisania subaddressu, a potem od razu funkcja odczytu.
Podejrzewam, że istnieje jakiś zdecydowanie prostszy sposób, dlatego nie dodawałeś subaddressu do funkcji odczytu:P

Można!
Do tego służy funkcja write ;] Zapisujesz w sumie 2 bajty - address i subaddress, po czym robisz stop/start lub sam start, wysylasz adres+RD i odczytujesz. Ku grotesce obie te funkcje czytały właśnie dane z dwóch akcelerometrów MMA-ileśtam firmy Freescale...;]



Każdy typowy scalak po I2C ma wewnętrzny wskaznik na rejestr. Ten 'register pointer' ustawia się zawsze wysyłając bajt (jeden lub więcej) bezposrednio po adresie+WR. Zauważ, że zapis do rejestrów jest analogiczny - wysyłasz adres, potem pointer, a potem dane. Jesli wyslesz tylko adres i pointer, to zmienisz sam pointer bez dotykania rejestrów...
A spod tego pointera scalak bedzie czytał po wysłaniu do niego adresu+RD.

Męczę się już cały dzień i nie chce mi to zacząć działać
Program stoi na sprawdzaniu flag:
, jeszcze w funkcji zapisu subadresu podczas wywoływania Twojej funkcji accRead I nie wiem, co z tym dalej zrobić. Obawiam się, że to przez zmiany jakich musiałem dokonać, aby przystosować kod do procesora F4. Poniżej wrzucam kody, gdyby ktoś mógł spojrzeć, to byłbym bardzo wdzięczny.

nsvinc napisał:

... slave'm MCP23008, które to cholerstwo też wisiało kompletnie po najmniejszym zakłóceniu na magistrali...

Potwierdzam. Układ na stole w "idealnych" warunkach przestaje odpowiadać lub działa częściowo(działają tylko wyjścia gpio)