logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

AVR i SHT71 nie stabilne odczyty

GienekS 02 Maj 2011 22:20 2650 18
  • #1 9462748
    GienekS
    Poziom 32  
    Zaadaptował załączone oprogramowanie dla AVR-a i uzyskałem całkowicie nie stabilne odczyty temperatury i wilgotności. Co może być nie tak.
  • #2 9463464
    skalsky5000
    Poziom 21  
    Gieneks czym to zasilasz? Pokaż schemat.
  • #3 9463477
    GienekS
    Poziom 32  
    skalsky5000 napisał:
    Gieneks czym to zasilasz? Pokaż schemat.
    Zasilam to z modułu STK500, którego zasilanie jest ustawiony na 3,6V na porcie C a kabelek ma około 10 cm, chyba nie za długi. Procesor leci na 8MHz i najważniejsze JTAG jest wyłączony oczywiście.
    Ta niestabilność to odczyty zmieniają się w całym przedziale zmiennej int do której jest ładowana wartość.
    Jest dodany opornik 10k pomiędzy linią DATA a zasilaniem, tak jak jest zalecone w dokumentacji układu.
  • #4 9463891
    skalsky5000
    Poziom 21  
    /***********************************************************************************
    Project:          SHT1x/7x demo program (V2.4)
    Filename:         SHT1x_sample_code.c    
    
    Prozessor:        80C51 family
    Compiler:         Keil Version 6.23a
    
    Autor:            MST
    Copyrigth:        (c) Sensirion AG      
    ***********************************************************************************/
    // Revisions:
    // V2.4	 calc_sht11()       Coefficients for humidity and temperature conversion 
    //                          changed (for V4 sensors)
    //       calc_dewpoint()	New formula for dew point calculation 
    
    
    
    #include <AT89s53.h> //Microcontroller specific library, e.g. port definitions
    #include <intrins.h> //Keil library (is used for _nop()_ operation)  
    #include <math.h>    //Keil library  
    #include <stdio.h>   //Keil library

    Używasz AVR czy '51 ?

    Dodano po 12 [minuty]:

    Sorki nie doczytałem ze dostosowałeś kod.Pokaz swój kod.
  • #5 9464088
    GienekS
    Poziom 32  
    To jest moja adaptacja.
    Dodałem szereg opóźnień być może są zbędne. Jak będzie działało to będę optymalizował.

    Jedyne co jest stałe to odczyt statusu układu = 0 a suma kontrolna = 117
  • #6 9467553
    encore
    Poziom 19  
    Wygląda że komunikacja z czujnikiem nie działa.
    Jesteś pewien że sumę kontrolną liczysz dobrze?
    Przewody masz krótkie, mimo to może warto zastosować układ linii zasilania i sygnałowych jaką zaleca producent w dokumentacji. Właściwe rozłożenie linii sygnałowych i zasilających ma w przypadku tego czujnika na prawdę bardzo duże znaczenie.
    Rozumiem że częstotliwość pracy protokółu transmisyjnego nie jest zbyt duża.
    Problem może być jeszcze w oczekiwaniu na zakończenie konwersji przez czujnik, to też wyjaśnia rysunek w dokumentacji jak wygląda pełna transmisja.
  • #7 9467937
    GienekS
    Poziom 32  
    Co do linii zasilających co masz na myśli "Właściwe rozłożenie linii sygnałowych i zasilających". Lecą w tasiemce jeden obok drugiego.
    Co do sumy kontrolnej to jak widać na załączonym kodzie to ją odbieram ale jeszcze jej nie liczę. Kontroluję sygnały "ACK"
    Co do oczekiwania na koniec przetwarzania to jak widać
     for (i=0; i<65535; i++) 
      {
       	  delay_us (10);
       	  if (DATAIN == 0) break; //wait until sensor has finished the measurement
      }
    
    czekam na stan niski linii DATAIN jak jest podane w dokumentacji. Robiłem też że to czekałem około 1 sek ale też tu nic nie dało.

    Zastanawia mnie fakt dlaczego jak czytam status, który = 0 to suma kontrolna = 117 Czy to jest dobrze. Bo z tej tabeli którą załączam wynika że powinna być = 0
  • #8 9468057
    encore
    Poziom 19  
    Zobacz do dokumentacji czujnika.
    Jasno jest tam napisane że linie SCK, DATA, VCC, GND muszą być w tasiemce w odpowiedniej kolejności .
  • #9 9468067
    GienekS
    Poziom 32  
    Fakt ja mam SCK, DATA, GND, VCC
    Czyżby ta kolejność miała znaczenie. Zadam sobie trud i zamienię to. Ciekawe czy to coś zmieni.
    Czyli powinny być tak jak wychodzą z układu ?? czy jeszcze inaczej ?
  • #10 9468218
    encore
    Poziom 19  
    Człowieku zobacz do dokumentacji !!!! Tam to wprost jest opisane a nawet narysowane. Ja nie mam przy sobie w tej chwili dokumentacji do tego czujnika.
    Z jakiegoś niezrozumiałego dla mnie powodu nie chce ci sie przeczytać datasheeta , i to już twój problem.

    Właściwy układ przewodów ma znaczenie przy długich przewodach. W twoim przypadku wygląda że protokół komunikacyjny stwarza problemy.
  • #11 9468623
    tmf
    VIP Zasłużony dla elektroda
    Kolejność sygnałów w tasiemce nie ma wielkiego znaczenia. Należy jednak pamiętać, że ten czujnik nie powinien być podłączony na tasiemce dłuższej niż 10cm. Podciąganie DATA za pomocą rezystora masz?
    Zacząłbym od napisania poprawnej komunikacji, samo sprawdzenie ACK nic nie daje. Sprawdź czy CRC się zgadza (założę się, że nie), odczytaj rejestr stanu i sprawdź czy tu też masz takie pływanie. Jeśli tak to skopany jest protokół. Sam czujnik daje naprawdę stabilne odczyty.
  • #12 9468731
    GienekS
    Poziom 32  
    GienekS napisał:

    Jedyne co jest stałe to odczyt statusu układu = 0 a suma kontrolna = 117

    Linię DATA jest podciągnięta opornikiem 10k do zasilania.
    Zastanawia mnie skąd się bierze taka wartość sumy kontrolnej tego statusu. Dla zera powinno być chyba też zero.

    Dodano po 2 [godziny] 24 [minuty]:

    tmf napisał:
    Sprawdź czy CRC się zgadza (założę się, że nie), odczytaj rejestr stanu i sprawdź czy tu też masz takie pływanie.

    Jak już pisałem odczyt statutu i jego sumy kontrolnej jest stabilny.
    Status = 0
    a suma kontrolna = 117;
    Jeżeli byś mógł sprawdzić jaka jest odpowiedź u Ciebie.
    Nawet zauważyłem że po załączeniu niekiedy status = 64 a suma = 201
    To 64 to świadczy o niskim zasilaniu ale suma kontrolna nie wiem czy taka powinna być.
    Chyba znalazłem przyczynę.
    Teraz będę wywalał zbędne opóźnienia. Dla ciekawych powiem że wina oczywiście była w kodzie. Ciekawe że wszyscy niby czytają ale tego "ząga" nikt nie zauważył.
    Tak było:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    a tak jest teraz:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    I faktycznie pięknie trzyma temperaturę i wilgotność.
    Żadne czary mary, kabelki duperelki, tylko fizyka i matematyka.
  • #13 9471852
    GienekS
    Poziom 32  
    Obecnie usunąłem wszystkie opóźnienia z programu i przy takim samym zasilaniu (tasiemka około 10 cm +ścieżki na kicie STK500 od gniazda PORTY C do ATmegi 16) przy zegarze 8MHz i zasilaniu w przedziale od 3v6 do 5v, odczyty temperatury i wilgotności nie wykazują widocznych zmian.
    tmf napisał:
    Sprawdź czy CRC się zgadza (założę się, że nie), odczytaj rejestr stanu i sprawdź czy tu też masz takie pływanie.

    Miałbym prośbę do kolegi tmf o sprawdzenie tej sumy kontrolnej dla tego statusu = 0 i sumy = 117, chciałbym jeszcze dołożyć sprawdzanie sumy kontrolnej.
  • #14 9472034
    tmf
    VIP Zasłużony dla elektroda
    Sprawdzić w tej chwili tego nie mam jak, można ją wyliczyć na podstawie algorytmu z noty, mogę ci też podesłać na 100% działający mój kod na AVR, tyle, że w assemblerze, ale jest na tyle krótki, że nie powinno być problemu.
  • #15 9472142
    GienekS
    Poziom 32  
    Byłbym bardzo wdzięczny.
    Wyobraź sobie że ten moduł dopiero zaczął się sypać jak mu obniżyłem napięcie do 2V. Temperatura poważnie podskoczyła, a jeszcze przy 2v2 działa zupełnie normalnie. A cha jeszcze jedno, przy tych niskich zasilaniach status zwraca 64 a sumę kontrolną 201
    Jeszcze jedno, cały czas jadę na wyśrubowanym kodzie bez jakiegokolwiek "waita".
    I niema się co dziwić jak w dokumentacji tego układu są czasy rzędu 100ns a przy kwarcu 8MHz dla AVR-ów to jest 125ns fakt że przy napięciu >4,5v a poniżej maksymalna prędkość to tylko 1MHz ale widać że się jeszcze radzi.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Jak ustawić stałe CRC8INIT oraz CRC8POLY aby dla wartości odczytanej=0 uzyskać crc=117 oraz dla
    dana = 64
    crc = 201
  • Pomocny post
    #16 9475401
    tmf
    VIP Zasłużony dla elektroda
    W załączeniu masz mój kod. Działa na 90S2313 z zegarem 8MHz. Przy okazji jak widać jest też dosyć krótki, testowałem go na SHT75 i działał bez najmniejszych problemów. Mam gdzieś jeszcze w asemblerze funkcje konwersji wyników do danych stałopozycyjnych, ale to musze poszperać, bo jak widać to dawno robiłem.
  • #17 9476262
    GienekS
    Poziom 32  
    Na pięknie ale liczenia CRC to tu niema.:cry:
  • Pomocny post
    #18 9476345
    encore
    Poziom 19  
    Masz algorytm liczenia sumy kontrolnej i pełną obsługę komunikacji.
    Suma kontrolna liczona jest w wykorzystaniem tablicy w której sa odpowiednio przygotowane wartości. Zaletą tego rozwiązania jest szybkość działania.

    Kolego nie chce się wyzłośliwiać ale wierz mi znajomość angielskiego przynajmniej umiejętność czytania po angielsku jest obowiązkowa w elektronice. Intuicja podpowiada mi że jesteś z tym na bakier.

    Na tej stronie masz wszystko co potrzeba , łącznie z liczeniem sumy kontrolnej, oczywiście po angielsku.

    Link
  • #19 9476942
    GienekS
    Poziom 32  
    Tak to jest jak się czyta z "nie zrozumieniem". A poza tym to takim drobnym drukiem pisało
    The CRC register initializes with the value of the lower
    nibble of the status register (“0000’s3s2s1s0”, default
    “00000000”).
    
    1. Initialize CRC register to low nibble of status register
    (reversed (s0s1s2s3‘0000))

    Należą się dla was słowa uznania za cierpliwość, ale można było od razu napisać w czym rzecz że:
    1. W sumę kontrolną odebranych znaków wchodzi komenda nadawana (z czym się pierwszy raz spotkałem)
    2. I że dla psikusa zachciało im się zamieniać te bity.

    Myślę że jak dla mnie temat jest rozwiązany i wyczerpany.
    Jeszcze raz wszystkim WIELKIE DZIĘKI :D
REKLAMA