Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki



Teraz jest 29 mar 2024, o 15:08


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 5 ] 
Autor Wiadomość
PostNapisane: 16 paź 2017, o 17:58 
Offline
Użytkownik

Dołączył(a): 05 gru 2013
Posty: 246
Pomógł: 0

Przepraszam, że zawracam głowę, ale mam pewien problem, którego nie jestem w stanie rozwiązać. Patrzę w kod już kolejną godzinę przez kolejny dzień z rzędu i za nic nie mogę dojść do tego, co jest nie tak.

Ale do rzeczy...
Jeszcze na AVR-ach używałem pewnej biblioteki do obsługi sensora temperatury i ciśnienia BMP085. Wszystko działało idealnie.
Teraz przenoszę pewien projekt na PIC32, więc zabrałem się za portowanie tej biblioteki. Nie wydawało się to niczym specjalnie trudnym - podmieniłem instrukcje odpowiedzialne za komunikację po I2C i zastąpiłem wszystkie typy zmiennych na takie, które jasno określają rozmiar, aby uniezależnić się od architektury ("int16_t" zamiast "int", "int32_t" zamiast "long" itp.).

Komunikacja po I2C najwyraźniej działa - sprawdzałem analizatorek stanów logicznych.
Temperatura jest czytana prawidłowo - różni się maksymalnie o 0.3 stopnia C od wskazań drugiego czujnika DHT22.
Natomiast wskazanie ciśnienia jest dziwne...

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


W załączniku kod dla PIC32 z moimi zmianami, a także oryginalna biblioteka dla AVR.

Ktoś ma jakiś pomysł, co może być nie tak? :)


Załączniki:

Aby zobaczyć załączniki musisz się zalogować. Tylko zalogowani użytkownicy mogą oglądać i pobierać załączniki.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 16 paź 2017, o 20:51 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 06 gru 2013
Posty: 121
Pomógł: 16

A próbowałeś trochę sprzętowego debugowania programu, np. podglądu danych jakie przychodzą po I2C. Masz możliwość przecież ustawiania pułapek czy podglądu zmiennych, wyczerpałeś tę drogę ???. MPLABX IDE i PICKIT3 to bardzo dobry duet do sprzętowego debugowania a zakładam , że taki zestaw masz. Jeśli nie wiesz jak to zrobić to chętnie pomogę w tym zakresie.

_________________
http://strefapic.blogspot.com



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 17 paź 2017, o 07:00 
Offline
Użytkownik

Dołączył(a): 05 gru 2013
Posty: 246
Pomógł: 0

wat1970 napisał(a):
A próbowałeś trochę sprzętowego debugowania programu, np. podglądu danych jakie przychodzą po I2C. Masz możliwość przecież ustawiania pułapek czy podglądu zmiennych, wyczerpałeś tę drogę ???. MPLABX IDE i PICKIT3 to bardzo dobry duet do sprzętowego debugowania a zakładam , że taki zestaw masz. Jeśli nie wiesz jak to zrobić to chętnie pomogę w tym zakresie.


Na razie próbowałem dwóch rzeczy:
1) Sprawdziłem komunikację przez I2C za pomocą prostego analizatora stanów logicznych Saleae. Wygląda na to, że dane są czytane prawidłowo.
2) Podejrzałem szesnastobitowe zmienne, przechowujące (już poskładane z dwóch odebranych bajtów) kopie rejestrów z danymi kalibracyjnymi. Mają właściwe typy i zawartość. To znaczy w zapisie hex widać, że składają się z tych samych bajtów, które chwilę wcześniej widziałem na analizatorze podpiętym do I2C.

Jedyna dziwna rzecz wystąpiła, gdy chciałem podejrzeć wartości bufora odbiorczego, wykorzystywanego przy odczycie części MSB i LSB rejestrów kalibracyjnych. Tym razem skorzystałem uarta i zwykłej instrukcji printf("MSB: %x, LSB%x\n", buff[0], buff[1]). W dwóch miejscach zaobserwowałem dziwny efekt zamiany półbajtów miejscami w stosunku do tego, co pokazywał analizator i debugger
Czyli na przykład analizator pokazywał, że przez I2C szły kolejno dwa bajty: 0x12 oraz 0x0C. Debugger pokazał, że zostały one złożone w 0x120C. Natomiast wśród danych przesłanych przez serial pojawiało się coś takiego: "MSB: 12, LSB: C0". To ma jakieś znaczenie? Czy raczej wina leży po stronie jakiegoś błędu w stdio.h?

Dokładne dane z analizatora i podglądu zmiennych debuggera prześlę wieczorem, teraz nie mam do nich dostępu.

Przeglądałem też kod funkcji odpowiedzialnych za obliczenia, porównując go z przykładem z dokumentacji czujnika. Wygląda w porządku. Zresztą na AVR ten sam kod działał,

Testowałem układ także na innym czujniku BMP085 i występuje dokładne ten sam efekt, więc nie jest to chyba problem sprzętowy. No chyba, że obydwa czujniki będące w moim posiadaniu zostały dotknięte w tym samym momencie przez dokładnie taki sam problem. :)



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 17 paź 2017, o 10:31 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 06 gru 2013
Posty: 121
Pomógł: 16

0x0C i 0xC0 to nie to samo jakby co :)

------------------------ [ Dodano po: 45 minutach ]

jak masz to na AVR postawione to na sztywno zapodaj dane (bez odczytu z DT22) na wejście sekwencji /*calculate raw pressure*/ i zobacz wyniki a potem porównaj co z tymi samymi danymi na wejściu robi PIC32. Funkcja bmp085_getrawpressure(), robi sporo obliczeń i tu bym trochę kijem pogrzebał. To że kody wyglądają tak samo nie oznacza , że będą wypluwać te same dane :)

_________________
http://strefapic.blogspot.com



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 17 paź 2017, o 11:39 
Offline
Użytkownik

Dołączył(a): 05 gru 2013
Posty: 246
Pomógł: 0

wat1970 napisał(a):
0x0C i 0xC0 to nie to samo jakby co :)


Tyle, to ja wiem. ;)
Zakładam tylko, że ta sytuacja wynika z jakiegoś błędu w bibliotece stdio.h, używanej do wysłania danych przez UART. Bo wartości czytane przez analizator stanów logicznych (podczas transmisji I2C) oraz debuger (po scaleniu odebranych danych w jedną zmienną szesnastobitową) są ze sobą zgodne. Gdyby w buforze z jakiegos powodu półbajty były zamieniane miejscami, to debuger by to zauważył też w docelowej zmiennej.

UPDATE:

Dane z debugera wyglądają następująco, jeśli chodzi o wartości rejestrów kalibracyjnych:

Kod:
buff[0]    0x1E
buff[1]    0x12
buff[2]    0xFB
buff[3]    0xC6
buff[4]    0xC7
buff[5]    0x0C
buff[6]    0x85
buff[7]    0x3B
buff[8]    0x5E
buff[9]    0xEC
buff[10]    0x52
buff[11]    0x58
buff[12]    0x15
buff[13]    0x7A
buff[14]    0x00
buff[15]    0x38
buff[16]    0x80
buff[17]    0x00
buff[18]    0xD4
buff[19]    0xBD
buff[20]    0x09
buff[21]    0x80

bmp085_regac1   __int16_t   0xA0000336   0x1E12   7698   
bmp085_regac2   __int16_t   0xA000033E   0xFBC6   -1082   
bmp085_regac3   __int16_t   0xA0000328   0xC70C   -14580   
bmp085_regac4   __uint16_t   0xA0000320   0x853B   34107   
bmp085_regac5   __uint16_t   0xA000033A   0x5EEC   24300   
bmp085_regac6   __uint16_t   0xA0000332   0x5258   21080   
bmp085_regb1   __int16_t   0xA0000330   0x157A   5498   
bmp085_regb2   __int16_t   0xA0000322   0x0038   56   
bmp085_regmb   __int16_t   0xA0000338   0x8000   -32768   
bmp085_regmc   __int16_t   0xA000033C   0xD4BD   -11075   
bmp085_regmd   __int16_t   0xA0000334   0x0980   2432


Wygląda chyba na to, że wszystko jest poskładane prawidłowo... Powinienem szukać przyczyny gdzie indziej?


UPDATE2:

Sprawdziłem zawartość zmiennych lokalnych w funkcji getrawpressure(). Jest coś dziwnego. Jak mam rozumieć to "invalid address"?

Kod:
b6   __int32_t   0xA0009F3C   0xA2D0C9CE   -1563375154   
x3   __int32_t   0xBFFCBFFF   Invalid Address   Invalid Address   
b4   __uint32_t   0xBFFDBFFF   Invalid Address   Invalid Address   
b3   __int32_t   0xFF3FBFFF   Invalid Address   Invalid Address   
up   __int32_t   0xFFFFFFF0   Invalid Address   Invalid Address   
b7   __uint32_t   0x5127A   Invalid Address   Invalid Address   
buff   unsigned char[3]   0xA000FF78   "\x a2\x 4f\x 40"      
x1   __int32_t   0x0 (CONST)   0x00000000   0   
p   __int32_t   r02  (CPU)   0x000180E5   98533   
x2   __int32_t   0x0 (CONST)   0x00000010   16   



UPDATE3:
Problem został rozwiązany przy pomocy debugera. Okazuje się, że lekarstwem na komunikat "Invalid Address" było wyłączenie optymalizacji dla konkretnej funkcji. Dzięki temu mogłem już na bieżąco podglądać wartości lokalnych zmiennych. Okazało się, że obliczenia przebiegają prawidłowo i na końcu uzyskuje się wiarygodną wartość. Z tego miejsca było już łatwo trafić do źródła problemu, którym nie była wcale biblioteka, ale pomyłka w innej części kodu, polegająca na przypisywaniu wartości zwracanej przez funkcję do zmiennej o zbyt małym rozmiarze.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 5 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 gości


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
Sitemap
Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
phpBB SEO