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

KURS HOME ASSISTANT

Chcesz zautomatyzować swój dom bez skomplikowanego kodowania?
Zastanawiasz się nad wyborem sprzętu, oprogramowania i aplikacji?
Od czego zacząć przygodę z HA? Co będzie najlepsze na start?

Nasz kurs Home Assistant nauczy Cię krok po kroku, jak łatwo zautomatyzować swój dom i oszczędzić na rachunkach za prąd i ogrzewanie. Bez chmur, bez zbędnych abonamentów. Twoja przygoda z Home Assistant zaczyna się tutaj!

↓↓↓

    Szanujemy Twoją prywatność. Możesz wypisać się w dowolnym momencie.




    Teraz jest 10 lip 2025, o 23:56


    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 1 gość


    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:  
    cron
    Sitemap
    Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
    phpBB SEO