Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

DS18B20 - DS18B20 - brak konwersji temperatury

Kubbaz 16 Paź 2014 13:18 2607 28
  • #1 16 Paź 2014 13:18
    Kubbaz
    Poziom 26  

    Witam wszystkich Elektrodowiczów!

    Otóż muszę użyć układu DS18B20 do pomiaru temperatury.
    Sięgnąłem po niego, gdyż kiedyś go używałem i działało wszystko OK ;) - jednak nie tym razem :/.

    Chcę wykonać po prostu zwykłą pojedynczą konwersję temperatury i odczytać ją ze ScratchPada.

    Wykonuję:

    1. Wysyłam Presence Pulse do DS18B20.
    2. Otrzymuję "1". (zapala mi się dioda LED, gdy jest podpięty DS18B20, gdy go nie ma dioda LED jest zgaszona, więc inicjalizacja przebiega poprawnie)
    3. Wysyłam komendę 0xCC (Skip ROM)
    4. Wysyłam komendę 0x44 (ConvertT)
    5. Czekam 750 ms
    6. Wysyłam Presence Pulse do DS18B20.
    7. Otrzymuję "1". (zapala mi się dioda LED, gdy jest podpięty DS18B20, gdy go nie ma dioda LED jest zgaszona)
    8. Wysyłam komendę 0xCC (Skip ROM)
    9. Wysyłam komendę 0xBE (Read ScratchPad)
    10. Odczytuje 2 bajty (2 pierwsze bajty dot. temperatury)
    11. Wysyłam Presence Pulse do DS18B20 (żeby przerwać dalszy odczyt)
    12. Wysyłam po UARTcie do komputera te dwa bajty

    Cały czas wartość tych dwóch bajtów wynosi 0xFF.
    Funkcja Timer0_MicroSeconds () działa poprawnie. Sprawdziłem na oscyloskopem zmianę stanu jednego z GPIO (1-0-1-0-1-0-...) z wartością opóźnienia 10 us i rzeczywiście zbocza były w odstępie 10 us.
    Układ DS18B20 jest sprawny, bo po podłączeniu go przez adapter 1-Wire-USB do komputera, bez kłopotów odczytuje temperaturę.

    Poniżej zamieszczam kod źródłowy:

    Biblioteka do obsługi 1-Wire:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Program główny:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0 28
  • #2 16 Paź 2014 14:14
    michalko12
    Specjalista - Mikrokontrolery

    Kubbaz napisał:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #3 16 Paź 2014 14:37
    nsvinc
    Poziom 35  

    Bez resetu? Nic nie rozumiem z tego...

    Przeciez kazdą transakcję zaczyna się od 1wire_reset. Ten reset resetuje maszynę stanu protokołu 1wire w slave'ach. A standardowa transakcja składa się z:
    1) reset
    2) adres(match rom)/pomin adres(skip rom)
    3) rozkaz
    4) transfer (opcjonalnie)
    5) reset (opcjonalnie, ale zalecane)

    Z punktu widzenia mastera właśnie reset powoduje wystawianie presence pulse przez slave'y;

    Ja mam (mniej więcej) tak:

    Kod: C
    Zaloguj się, aby zobaczyć kod

    Działa w 101% przypadków.

    Swoją drogą, biorąc pod uwagę ilość UARTów w LPC17xx to obsługa 1wire w podany wyzej sposób to techniczny absurd śmierdzący rozwiązaniami z bascoma...

    0
  • #4 16 Paź 2014 15:14
    hexen2k
    Poziom 16  

    Niech kolega Kubbaz zaznajomi się z dokumentem AVR318
    Link

    0
  • #5 16 Paź 2014 15:40
    michalko12
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    Bez resetu? Nic nie rozumiem z tego...


    Ok. Już wiem o co Ci chodzi. Mając na myśli "reset" myślałem o szczelinie dłuższej od 960us, czyli stanu gdzie zaczyna brakować DS energii do podtrzymanie działania przy dwuprzewodowym podłączeniu. Już dawno nie zaglądałem do dokumentacji z 1Wire.

    0
  • #6 16 Paź 2014 16:10
    hexen2k
    Poziom 16  

    Prawidłowa transakcja dla kolegi Kubbaz. Żywcem wyjęte z dokumentacji i dostosowane do Twoich potrzeb:

    MASTER MODE DATA (LSB FIRST) COMMENTS
    1. Tx Reset, Master issues reset pulse.
    2. Rx Presence, DS18B20 responds with presence pulse.
    3. Tx CCh, Master issues Skip ROM command.
    4. Tx 44h, Master issues Convert T command.
    5. Tx ,DQ line held high by strong pullup Master applies strong pullup to DQ for the duration of the conversion (t CONV ).
    6. Tx Reset, Master issues reset pulse.
    7. Rx Presence, DS18B20 responds with presence pulse.
    8. Tx CCh, Master issues Skip ROM command.
    9. Tx BEh, Master issues Read Scratchpad command.
    10. Rx ,9 data bytes Master reads entire scratchpad including CRC. The master then recalculates the CRC of the first eight data bytes from the scratchpad and compares the calculated CRC with the read CRC (byte 9). If they match, the master continues; if not, the read operation is repeated.

    Zamiast odczytu 9 bajtów możesz zakończyć odczyt po odebraniu 2 pierwszych bajtów. Jednak rezygnujesz wtedy świadomie z weryfikacji odebranych danych za pomocą sprawdzenia CRC.


    Kolega michalko12 napisał wcześniej, iż po komendzie reset wynik konwersji zostanie utracony - komenda reset nie kasuje wyniku konwersji temperatury.

    Kolega nsvinc podał prawidłowy schemat postępowania, jednak ten końcowy, zalecany reset nie jest potrzebny przy prawidłowym wykonywaniu obsługi magistrali. Każda transmisja rozpoczyna się od resetu magistrali i to gwarantuje poprawną obsługę transmisji.

    Należy się jeszcze małe sprostowanie w kwestii nazewnictwa dla kolegi Kubbaz:

    Kubbaz napisał:
    Wysyłam Presence Pulse do DS18B20.


    Wysyłasz Reset Pulse z urządzenia nadrzędnego Master, natomiast w odpowiedzi otrzymujesz Presence Pulse z urządzenia podrzędnego Slave (czyli czujnika DS18B20).

    Powodzenia!

    0
  • #7 16 Paź 2014 16:25
    nsvinc
    Poziom 35  

    Nie bez powodu wspomniałem o końcowym resecie. To fakt, że specyfikacja 1wire w najmniejszym stopniu nie każe resetować magistrali po transakcji.

    Wynikło to z moich własnych doświadczeń. Taki DS2450 jeśli pracował z wieloma kolegami na długim kablu, nie zawsze chciał akceptować reset rozpoczynający transakcję. Empirycznie zostały na to znalezione 2 patenty - albo kilka resetów pod rząd na początku transakcji, albo jeden reset kończący transakcję.

    Kolega Kubbaz nigdzie nie napisał jak zasila czujnik(?). Tylko zasilanie pasozytnicze wymaga silnego plusa na linii DQ na czas wykonywania operacji (konwersji).
    Swoją drogą, w STM32 1wire z zasilaniem pasozytniczym zrealizowałem jednym pinem portu i jednym rezystorem (zadnych zewn. tranzystorów). W LPC17xx pewnie też się tak da ;]

    0
  • #8 16 Paź 2014 16:38
    hexen2k
    Poziom 16  

    Zatem dziękuję nsvinc za te cenne informacje!

    nsvinc napisał:
    Swoją drogą, w STM32 1wire z zasilaniem pasozytniczym zrealizowałem jednym pinem portu i jednym rezystorem (zadnych zewn. tranzystorów). W LPC17xx pewnie też się tak da ;]


    Ale podejrzewam, iż nie za pomocą interfejsu UART a zwykłego GPIO ;) Sam wcześniej napisałeś:
    nsvinc napisał:
    sposób to techniczny absurd śmierdzący rozwiązaniami z bascoma...

    z czym się w pełni zgadzam :)

    Jeśli nie ma specjalnych przesłanek do robienia 1-Wire na zwykłym porcie GPIO (brak wolnego UART, oszczędność jednego pinu uC itd.) propagujmy wśród forumowiczów jedynie dobre rozwiązania - tzn. wykorzystanie UART do realizacji 1-Wire ;)


    Serdecznie pozdrawiam kolegę nsvinc

    0
  • #9 16 Paź 2014 16:50
    nsvinc
    Poziom 35  

    hexen2k napisał:
    Ale podejrzewam, iż nie za pomocą interfejsu UART a zwykłego GPIO

    Oczywiście że UART. Domyślnie pin ustawiony jest w tryb push-pull. UART domyślnie 'wysyła' IDLE a więc ciągły stan wysoki, a więc linia DQ jest silnie zasterowana plusem.
    Funkcje dokonujące transakcji przełączają na czas transakcji pin w tryb open drain. Po transakcji znowu pin jest przełączany w push-pull.
    Tym sposobem nie trzeba się martwić o specjalne wystawianie silnego plusa na czas konwersji. Ma to tylko (dla mnie nieistotną) wadę, że nie mozna używać sygnałów alarmowych z czujników. Za to ma zaletę, że po linii DQ w spoczynku nie latają śmieci z powodu zakłóceń środowiskowych.

    Takie rozwiązanie pozwala na zasilanie pasozytnicze 5 czujników ds18b20; więcej nie testowałem...

    PS.
    No w sumie 2 piny procka, tyle że rx z tx'em zwarty, rx jako wejście HiZ ;]
    Na LPC812, gdzie jest SWM, tx i rx mozna zmapować na ten sam pin; wtedy jest bonanza, i o to mi chodziło. Pomyliłem procesory...;/

    0
  • #10 16 Paź 2014 17:03
    hexen2k
    Poziom 16  

    nsvinc napisał:
    Ma to tylko (dla mnie nieistotną) wadę, że nie mozna używać sygnałów alarmowych z czujników.

    Mowa o ALARM SEARCH [ECh] czy o sprawdzaniu READ POWER SUPPLY [B4h] w przypadku specjalnego zastosowania?

    0
  • #11 16 Paź 2014 17:33
    nsvinc
    Poziom 35  

    Muszę przyznać - pomyliłem się. Nie ma czegoś takiego jak alarm signaling na linii DQ, a jedynie alarm search. A więc podane rozwiązanie nie ma limitacji w obrębie standardu 1wire.

    0
  • #12 16 Paź 2014 19:54
    Kubbaz
    Poziom 26  

    hexen2k, z tego co przeanalizowałem, to ten fragment dokumentacji, który przytoczyłeś jest zrealizowany w moim kodzie (?):

    Kod: c
    Zaloguj się, aby zobaczyć kod


    michalko12 napisał:

    Kod: c
    Zaloguj się, aby zobaczyć kod



    ResetPulse jest 2 wiersze wyżej niż wiersz który wskazałeś...


    nsvinc napisał:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    nsvinc, jak wygląda cały Twój algorytm z częścią komendy Convert T?
    Bo ten fragment chyba dotyczy tylko już samego odczytu wartośći ze ScratchPada...?

    0
  • #13 16 Paź 2014 20:08
    michalko12
    Specjalista - Mikrokontrolery

    Kubbaz napisał:
    ResetPulse jest 2 wiersze wyżej niż wiersz który wskazałeś...

    Rzeczywiście, te odstające nawiasy mnie zmyliły.

    Ale jeszcze coś...
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Te 15us to jest już po czasie, sprawdź po 3us.

    0
  • Pomocny post
    #14 16 Paź 2014 20:24
    hexen2k
    Poziom 16  

    Kubbaz napisał:
    hexen2k, z tego co przeanalizowałem, to ten fragment dokumentacji, który przytoczyłeś jest zrealizowany w moim kodzie (?):

    Zgadza się :)

    michalko12 ma rację, sprawdzasz za późno:
    DS18B20 - DS18B20 - brak konwersji temperatury

    3us na krótkiej lini powinno zadziałać, jednak przy dłuższych magistralach może być problem. IMHO lepiej sprawdzać trochę później np. po 7us

    0
  • #15 16 Paź 2014 22:14
    Kubbaz
    Poziom 26  

    hexen2k napisał:
    michalko12 ma rację, sprawdzasz za późno:
    DS18B20 - DS18B20 - brak konwersji temperatury

    3us na krótkiej lini powinno zadziałać, jednak przy dłuższych magistralach może być problem. IMHO lepiej sprawdzać trochę później np. po 7us


    Faktycznie.... te 15 us to tak zupełnie na styk :/. Kiedyś mi to działało, dlatego nie zmieniałem tego, a teraz się zdziwiłem widząc po odbiorze danych same 0xFFy.
    Jutro z samego rana przetestuję odczyt bitu z krótszym opóźnieniem niż 15 us.

    0
  • #16 17 Paź 2014 11:07
    Kubbaz
    Poziom 26  

    Witam po porannych zmaganiach z DS18B20.
    Otóż... zmieniałem wartości opóźnienia w funkcji odczytu bitu:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    od 1 us do 20 us i od 1 us do 13 us na terminalu widzę 0x00 a powyżej 14 us widzę same 0xFF - albo tak albo tak.

    Podłączyłem oscyloskop do pinu GPIO P2.12 LPC i sprawdziłem ResetPulse i PresencePulse z DS18B20 - jest prawidłowy, tzn. uC daje stan niski na 500 us później jako wejście po 64 us sprawdza czy jest stan niski (wywołany przez DS18B20) czy wysoki (spowodowany przez pull-up'a 10 kOhm do Vcc). U mnie stan PresencePulse trwa 124 us.

    Prześledziłem moje funkcje po raz kolejny i zweryfikowałem timingi z dokumentacjęDS18B20 - wszystko się zgadza. Poszperałem w sieci. Znalazłem materiał Cezarego Klimasza wraz z kodem źródłowym w C na AVR: OBSŁUGA INTERFEJSU 1-WIRE NA PRZYKŁADZIE DS18B20.
    Wszystko tak jak w moim kodzie źródłowym, ale niestety w dalszym ciągu nie otrzymuję wartości temperatury.

    Ponownie podłączyłem DS18B20 do konwertera 1-WIre-USB i sprawdziłem czy on w ogóle działa - działa i odczytuje nim temperaturę na PC.

    Teraz już sam nie wiem... :/

    0
  • #17 17 Paź 2014 18:15
    michalko12
    Specjalista - Mikrokontrolery

    Znajdź różnicę...

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #18 17 Paź 2014 20:18
    nsvinc
    Poziom 35  

    michalko12 napisał:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Stan drzewny? ;)

    0
  • #19 17 Paź 2014 20:39
    michalko12
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    Stan drzewny? :wink:


    A to jest z oryginału ctrl+c, ctrl-v ;)

    0
  • #21 15 Sie 2015 13:54
    wojlej
    Poziom 17  

    Witam,

    Nie będę zakładał nowego tematu, mam problem z DS18B20. Procesor STM32F103 + wyświetlacze 7 segmentowe. Obsługa wyświetlaczy działa poprawnie. Procesor odczytuje temperaturę z DSa i wyświetla 27, co jakiś czas 00, i co jakiś czas 60, albo 58. Jak dotknę palec do czujnika to temperatura wzrasta do 33, co jakiś czas pokazuje się 62 i 00. Coś jest chyba nie tak z obsługą. Przedstawiam poniżej kod, ktoś na pewno znajdzie błąd.

    Plik onewire.c:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Pętla główna:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Proszę o pomoc w znalezieniu błędu...

    0
  • #22 15 Sie 2015 14:03
    Karol966
    Poziom 30  

    Do czego służy funkcja

    Kod: c
    Zaloguj się, aby zobaczyć kod
    , która co prawda i tak odnosi się do TIM3?

    Jak sterujesz wyświetlaczem, multipleksujesz? Jeśli tak to w czasie komunikacji z DS'em proponuję wstrzymać wszelkie zbędne przerwania.

    0
  • #23 15 Sie 2015 14:12
    wojlej
    Poziom 17  

    Gdzie widzisz u mnie funkcje TIM2 init? Ja jej nie mogę u siebie znaleźć.

    Wyświetlacze multipleksuje w przerwaniu. Używam Timera 2 który zgłasza przerwania o przepełnieniu. W tym przerwaniu ustawiam odpowiednie stany na portach i włączam odpowiedni wyświetlacz.

    0
  • #24 15 Sie 2015 14:16
    Karol966
    Poziom 30  

    wojlej napisał:
    Wyświetlacze multipleksuje w przerwaniu

    Karol966 napisał:
    multipleksujesz? Jeśli tak to w czasie komunikacji z DS'em proponuję wstrzymać wszelkie zbędne przerwania.

    0
  • #25 15 Sie 2015 14:19
    wojlej
    Poziom 17  

    OK.

    Dodałem w pętli głównej coś takiego:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Funkcja inicjalizujaca timer i i funkcja TimerStartStop:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Timer konfigurowany jest na samym początku programu jak powyżej. W pętli głównej podczas odczytu z DSa wylaczony jest timer. Podczas odczytu wyświetlacze się zatrzymują i tylko na jednym wyświetlana jest liczba (więc zatrzymywanie działa). Niestety nic to nie dało. Taki sam efekt.

    0
  • #26 15 Sie 2015 14:55
    nsvinc
    Poziom 35  

    Dziwne wartości z DSa masz na 80% z powodu zakłóceń linii. Nie czytasz całego scratchpada a tylko samą temperaturę, więc jeden przekłamany bit wystarczy żebyś dostał i wyświetlił śmieci.
    Czytaj cały scratchpad - on się konczy sumą kontrolną, więc po odebraniu danych możesz sensownie zweryfikować, czy to, co dostałeś, ma sens.

    Kod: C
    Zaloguj się, aby zobaczyć kod

    0
  • #27 15 Sie 2015 19:50
    wojlej
    Poziom 17  

    Jakoś dziwnie ten czujnik się zachowuje. Teraz pętla główna jest taka:

    Kod: objc
    Zaloguj się, aby zobaczyć kod


    Odczytuje za pomocą funkcji u1w_readSingle. Trochę ją zmodyfikowałem żeby od razu mi temperature wyrzucała.

    Dodatkowe funkcje w onewire.c:
    Kod: objc
    Zaloguj się, aby zobaczyć kod


    Teraz pokazuje się 12, raz -240, a raz 00.

    Mało tego. Wiem, że pierwszy pomiar powinien być 85. A nie jest. I dlaczego te zakłócenia? Czujnik jest oddalony od procesora o 4 cm.

    Dodano po 1 [godziny] 40 [minuty]:

    Czy problem może polegać na tym, że nie zmieniam konfiguracji pinów z wejścia na wyjście i odwrotnie w trakcie pracy magistrali?

    0
  • #28 16 Sie 2015 12:07
    nsvinc
    Poziom 35  

    wojlej napisał:
    Mało tego. Wiem, że pierwszy pomiar powinien być 85.

    A dlaczego miałby być, skoro zanim odczytasz temperature wysylasz rozkaz konwersji i czekasz na jej zakonczenie? Jakbyś najpierw czytał, a potem konwertował, to pierwszy wynik byłby 85 stopni.

    wojlej napisał:
    Czy problem może polegać na tym, że nie zmieniam konfiguracji pinów z wejścia na wyjście i odwrotnie w trakcie pracy magistrali?

    Jeśli ten pin nie pracuje w trybie otwartego drenu, a ty nie zmieniasz kierunku, to dziwię się że w ogóle cokolwiek działa...

    0
  Szukaj w 5mln produktów