Witam.
Borykam się z problemem dotyczącym komunikacji z urządzeniem wymienionym w temacie.
Próbuję napisać program pobierający dane z rejestrów MPU 6050 (dane z czujników), wysyłający dane do mikrokontrolera Atmega8, a następnie przez UART do komputera, gdzie odbieram je poprzez terminal Realterm.

Problem polega na tym, że odbierane dane nie są poprawne, otrzymuję 3 takie same wyniki dla akcelerometru i 3 dla żyroskopu; jeden z wyników z akcelerometru powinien wskazywać 1g, a reszta 0 (układ dla celów testowych znajduje się w bezruchu). Otrzymane wyniki nie odzwierciedlają poprawnie rzeczywistości.

Żeby sprawdzić poprawność elementów systemu wgrałem prosty program z niebieskiej książki do przetestowania UART, wysyłałem również dane typu int16_t korzystając z funkcji itoa(), odbyło się bez zastrzeżeń.
Dodatkowo trochę zmodyfikowałem program aby pobrać zawartość jednego z rejestrów MPU 6050; jego domyślna zawartość powinna być równa 0x40, ja natomiast odbierałem wartość 0xc4 (wynikałoby z tego, że układ cały czas się resetuje i jest w trybie uśpienia). Oprócz tego co 1s chciałem zamigać diodą; mikrokontroler w ogóle nie zmienia stanu pinu do którego podłączyłem diodę; kiedy wgrałem program, który tylko migał i nic więcej nie robił działało to bezproblemowo.

Poniżej zamieszczam kod programu testowego, który miał zapisać rejestr wartością 0x28 a następnie odczytywać go; funkcje do obsługi komunikacji I2C żywcem przepisane z niebieskiej książki.





Dodam, że pomyłkowo przez krótki czas zasilałem układ napięciem 5V, ale według producenta dopiero przekroczenie 6V powoduje uszkodzenie.

Proszę o pomoc; jeśli ktoś potrzebuje dodatkowych informacji wystarczy napisać.

Jeśli dioda nie miga to gdzieś jest babol i trzeba go zlokalizować
przenieś włączanie diody na początek main tylko nie migaj ale zaświeć ją.
Jeśli się zaświeci to przenieś diodę za następną instrukcję itd.
aż znajdziesz winowajcę.

Jeszcze jedno nie widzę ustawiania prędkości na I2C .

Pomysł z diodą wydaje się niezgorszy, jutro spróbuję.
W kwestii prędkości to trochę niezbyt konkretnie napisałem, ustawiam ją funkcją init(), która zawartą w pliku TWI.c, zamieszczam jej kod



Chciałem uaktywnić w niej wewnętrzne rezystory podciągające i ustawić wartość TWBR na 2 żeby uzyskać prędkość 400kHz

Tak przy okazji spytam czy program z poprzedniego posta nie zawiera jakiś rażących błędów?
Pytam, bo wiem, że łatwiej wychwycić cudze błędy niż swoje.

Spróbowałem metody z diodą. Za pierwszym razem po wstawieniu zapalenia diody po _delay_ms() nie chciała się zapalić, jednak po kilku próbach świeciła jak trzeba więc zapewne zapomniałem wtedy czegoś kliknąć. Ciekawsze jest jednak to, że gdy zastosowałem taką zmianę w programie. który miał być tym docelowym (nie wstawiałem na forum jego kodu) to gdy wstawiłem zapalenie diody po instrukcji zapisania kilku rejestrów (funkcja zapożyczona z niebieskiej książki) dioda nie chciała się zapalić.

Piszesz o podciąganiu linii i2c ,powinny one być podciągnięte
zewnętrznym rezystorem do VCC (4,7K ).
Wewnętrzny jest za "słaby".

Masz BB ?
tam są przykłady transmisji i2c tylko ściągnij uaktualnienia ze strony atnel.pl
bo coś nie tak z ustawianiem prędkości w TWBR

Niestety nie mam na podorędziu rezystorów 4,7k , mogę zamiast nich użyć 10k? albo 2 połączone szeregowo 2,2k?

W kwestii prędkości wprowadziłem do programu funkcję i2cSetBitrate z niebieskiej książki, na razie nic to nie dało.

Dla celów testowych spróbowałem odczytać wartości rejestrów obok tego wymienionego w programie (ich wartości powinny być
równe 0), w terminalu odczytuję trzy razy wartość c4. Dioda działa bez zarzutu.
Dlatego też się zastanawiam czy nie wprowadziłem błędu w przygotowywaniu wartości do wysłania. Poniżej zamieszczam kod funkcji,
która zmienia odczytaną wartość na łańcuch znaków i wysyła do terminala:



Wydałoby mi się dziwne gdyby była zła, bo bardzo podobną funkcją wysyłałem zmienne int do terminala i działało dobrze

Daj 2,2k w szereg do VCC na linich i2c.
linie i2c muszą być pociągnięte.

Jakieś pól godziny temu coś sobie przypomniałem. Mianowicie ok. 2 tygodnie temu wgrałem program czysto testowy, zapomniałem w nim ustawić prędkości, nie wstawiłem rezystorów, a mimo to udawało się odczytywać w przerwaniu dane (co prawda bezużyteczne bo nie zmieniłem int na char) z częstotliwością 4Hz, czyli dokładnie taką jaką ustawiłem. teraz natomiast MPU 6050 wydaje się być ślepe i głuche.

Zapomniałbym zapytać - czy to oznacza, że układ jest uszkodzony czy jeszcze powinienem popróbować coś z niego wyciągnąć?

To chyba w DS producent tak tyko sobie pisze
w rozdziale 9.2



Czy Ty masz moduł z tą kostką czy fizycznie kość MPU6050 ?

------------------------ [ Dodano po: 7 minutach ]

Wrzuć schemat jak to wszystko jest połączone
i może jakąś fotkę

Zdjęcia układu


Na zdjęciu po prawej na dole jest układ do zasilania płytek, na dole mam 5V, na górze 3,3V (albo odwrotnie).
Dwie płytki bo już miałem dość przenoszenia układu z jednej na drugą a chciałem podpiąć się do 3,3V.

BTW czy dobrze zrobiłem podciągając SCL i SDA do 3,3V? Bo mikrokontroler jest zasilany z 5V.

Widzisz trzeba było tak od razu Ty nie masz układu (kostki) MPU6050
tylko moduł z tym układem a to zmienia postać rzeczy.

Przez to że to jest moduł mogłem Cię wprowadzić w błąd z PullUp I2C
za co z góry przepraszam ale miałem nie pełne informacje a z tematu
wywnioskowałem że posiadasz sam układ scalony.

Prawdopodobnie nie potrzebujesz podciągnięcia linii I2C
bo posiada je ten moduł ale musisz to koniecznie sprawdzić
w schemacie swojego modułu.
Musisz wiedzieć dokładnie co tam producent zamonował.
Możliwe że jest tam też stabilizator 3,3V .

Jak wszystko posprawdzasz to przedstaw jak najwięcej informacji
wtedy może coś się uda ogarnąć.

Kurde, niby widziałem, że jest napisane gy-521 i płytka jakaś taka niebieska ale w życiu bym nie pomyślał, że to moduł.

Przeczytałem Internet i dowiedziałem się, że faktycznie posiada stabilizator napięcia (na stronce Arduino zalecają nawet podpinać Vcc do 5V żeby i2c dobrze działało) i wewnętrzne rezystory podciągające. Nic więcej nie znalazłem; wygląda na to, że każdy kto pisze o tym module patrzy w Internet i robi ctrl+c ctrl+v, ale nawet to to już coś

Znalazłem taki schemat tego modułu ,
tylko sprawdź sobie czy się zgadza z Twoim
bo jak sam widzisz informacje z netu trzeba dobrze odfiltrować

Już miałem nadzieję, że to rozwiąże problem ale nie - nadal odczytuję c4 z tych rejestrów. I z każdych innych.
Poza tym zauważyłem coś dziwnego, mianowicie program wysyła dane do terminala tylko wtedy gdy jest podłączony programator (używam USBASP). Coraz poważniej myślę, że błąd tkwi w programie.

Wiem czemu dioda dziwnie pracowała - po pierwsze jak się trochę przechyliła to chyba coś nie łączyło bo nie świeciła.
Po drugie nie mam pojęcia dlaczego ale dioda bez Vcc z programatora nawet nie myśli o współpracy.
Myślę o tym aby wywalić ten moduł do zasilania skoro i tak niewiele daje, dobry pomysł?

Pozbycie się modułu zasilającego nic nie dało.
Pomyślałem więc, że inaczej sprawdzę co jest nie tak. Bazując na nocie aplikacyjnej atmegi8 zmodyfikowałem program tak aby monitorował dodatkowo stan rejestru TWSR. Po modyfikacji odczytałem, że układ gy-521 nie wysyła bitu ack po wysłaniu adresu + R/W oraz danych. Co ciekawsze program nie wysyła również innych znaków, które wstawiłem aby lepiej zorientować się w którym momencie wystąpił problem. Ma ktoś może pomysł co może być tego powodem?

Zobacz tutaj: http://playground.arduino.cc/Main/MPU-6050 - w Example Sketch (code) jest mnóstwo pomocnych definicji.

Sam będę próbował na dniach uruchomić moduł także dam znać jak się uda

Pociągnę temat pullup'ów na I2C.

Gdzie należałoby umieścić rezystory w przypadku gdy I2C przechodzi przez konwerter stanów logicznych 3,3/5V - podciągnąć linie do 5V przed konwerterem (przy CPU) czy do 3,3V za nim ?

Schemat konwertera na BSS138 w zasadzie zawiera w sobie pullupy po obu stronach przez 10K, czy dopuszczalne jest w tym przypadku użycie niższych wartości oporów?
http://i.stack.imgur.com/3Jz1E.jpg
proszę o poradę.

Pewnie, że dopuszczalne a nawet wskazane jeśli po jednej stronie masz napięcie mniejsze niż 3,3V ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Mniej niż 3,3V nie będzie ale za to chciałbym aby i2c chodziło zarówno na 100 jak i 400KHz. Z wyliczeń wg pdf atmega168 w zależności od Vcc pullup'y powinny wynosić minimum 1K dla 3,3 i min 1,5K dla 5V. Nie wiem jak wyliczyć 100ns/Cb więc nie wiem jakie jest maksimum, lecz czy opisywane tu i ówdzie 4,7K będzie OK i dlaczego by nie dać czegoś nieco ponad to 1,5K ?

http://davidegironi.blogspot.com/2013/0 ... e-and.html

Zajrzyj tam, testowałem na Mega32, działa dobrze, wymaga większego taktowania np. 16MHz.

Odświeżę temat.
Udał mi się rozwiązać problem braku potwierdzeń od urządzenia. Teraz mam problem czysto programowy.

Jak już wspominałem korzystałem z niebieskiej książki, przepisałem z niej funkcje do obsługi TWI, niemniej jednak nie działa poprawnie funkcja:



Kiedy wysyłam do terminal odebrane znaki otrzymuję zawsze 0. Oprócz tego nie działa funkcja delay_ms - znaki są wysyłane tylko raz.
Dziwię się gdyż stosując łopatologię jak w kodzie poniżej wszystko działa jak należy (oprócz delay_ms)



Może ktoś wie dlaczego:
1. _delay_ms nie działa (znaki są wysyłane tylko raz)
2.funkcja i2c_read_buf nie spełnia swego zadania
3. dioda nie chce się nawet zapalić?

Problem a diodą rozwiązany, przy przenoszeniu układu na inną płytkę pomyłkowo źle ją podłączyłem.
Niemniej jednak pozostałe problemy nadal aktualne i nadal przeszkadzające

Trochę zbyt ogólnikowo przedstawiłeś problem,
nie widzę w kodzie gdzie używasz funkcji i2c_read_buf ?

Naturalnie, mój błąd. Tutaj wstawiłem ten kod, który działa.
Funkcji read_buf wstawiałem zamiast instrukcji od linijki 42 do 50 włącznie, mam wstawić taki kod czy wystarczy ta informacja?
Reszta kodu bez zmian.

To rozumiem że to co teraz jest pomiędzy liniami 42 i 50 działa poprawnie ?
bo jeśli tak to według tego napisz funkcję i2c_read_buf.
Jak porównać to co wykonujesz w ww. liniach a funkcję i2c_read_buf to jest to zupełnie coś innego

Oprócz tego, że w pierwszym przypadku używam wskaźnika a w drugim kodzie z miejsca wskazuje konkretne elementy tablicy, do których chcę zapisywać to dla mnie te programy się nie różnią. Mógłbyś trochę precyzyjniej wyjaśnić różnicę ? Chyba, że to tylko to co już napisałem.

Przepraszam za wprowadzenie zamieszania
moje niedopatrzenie, błędnie zrozumiałem parametry wywołania funkcji i2c_read_buf

Co dostajesz po wywołaniu tej funkcji w tablicy buf ?
opisz trochę dokładniej co znaczy "nie spełnia swojego zadania"
nie kompiluje się czy coś innego ?

Nie ma sprawy, w końcu jakby nie patrzeć próbujesz pomóc a to raczej często się nie zdarza.

Kiedy chciałem odebrać w ten sposób i wysłać to (o ile dobrze pamiętam) terminal "zgłupiał" - wysyłał całe mnóstwo przypadkowych znaków. Trochę dawno to było a ja stwierdziłem, że dalej tak się bawić nie będę.

Przy okazji info z ostatniej chwili - za żadne skarby świata nie mogę zrozumieć jak to możliwe ale gdy zacząłem zbierać dane do tablicy typu int16_t i bezpośrednio z niej odczytywać (wywaliłem rzutowanie na ten typ) to jakimś cudem funkcja _delay_ms ożyła,
mogę diodą migać i otrzymuję dane co 1 sek. Na prawdę nie wiem jak to się stało.
Teraz powalczę z odbieraniem danych

Zrób Clean projektu i dopiero kompilację
Robią Ci się jakieś dziwne rzeczy
(to żarty)
Na dziś mam już dość zwoje w korze mi się prostują

Należy się sprostowanie. Całe mnóstwo znaków odczytuję wtedy gdy próbuję przetworzyć otrzymane dane na wartości dla mnie zrozumiałe. Gdy używam funkcji i2c_read_buf to otrzymuję najczęściej 0, czasem pojawi się bodajże 30. Jedyne co daje (chyba) dobry efekt to łopatologia jednak funkcję służącą do wysyłania znaków do terminala muszę umieścić wewnątrz funkcji bazującej na łopatologii.
Jeśli utworzę nową funkcję i w mainie wstawię ją po funkcji odpowiedzialnej za odczyt to otrzymuję same 0, tak jakby kompilator nie widział, że zmieniłem wartości tablicy do odbierania danych.