Kurs STM32L4 – #17 – termometry DS18B20 (1-wire, UART)

[Komentator]

Protokół 1-wire spotykany jest chyba najczęściej podczas komunikacji z termometrami DS18B20. Dlatego w tej części kursu STM32L4 zajmiemy się właśnie tym zagadnieniem. Podczas eksperymentów z DS18B20 utworzymy najpierw niskopoziomową bibliotekę do 1-wire, a później użyjemy jej do obsługi tych sensorów.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Komentator]

Przypominamy: w komentarzach do kursów rozmawiamy wyłącznie na tematy związane z konkretnym kursem. Mile widziane są również informacje od osób, które korzystały wcześniej z naszych poradników. Wszystko po to, aby kursanci, którzy mają zamiar korzystać z tego kursu nie musieli "przedzierać" się przez dziesiątki postów na inne tematy. Tematy na pytanie, które nie są związane z kursem można zadawać na naszym forum o mikrokontrolerach.

[Treker (Damian Szymański)]

Zachęcam do lektury kolejnej części kursu, w której opisaliśmy komunikację z popularnymi termometrami DS18B20. Był to oczywiście przykład, dzięki któremu mogliśmy omówić podstawy 1-wire. Mam nadzieję, że udało nam się pokazać tutaj coś ciekawszego od "zwykłego gotowca", który wyświetla temperaturę, bo warto wiedzieć jak samodzielnie tworzyć takie biblioteki (również z "niestandardowym" wykorzystaniem peryferiów sprzętowych).

[Zealota]

Doskonałe są te przykłady z kursu dla L4. Szacun!

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Treker (Damian Szymański)]

@Zealota miło słyszeć! Sporo się napracowaliśmy, więc dobrze słyszeć, że kurs jest pomocny 🚀

[Elvis]

W tej części chcieliśmy pokazać jak można za pomocą naszego mikrokontrolera komunikować się z czujnikami podłączanymi za pomocą interfejsu 1-wire, ale okazało się, że przy okazji musieliśmy sporo miejsca poświęcić na opisanie działania samego czujnika DS18B20. Nie jest to kurs obsługi tych czujników i wiele funkcji musieliśmy pominąć, ale o jednej warto byłoby wspomnieć.

Pokazaliśmy jak można odczytywać temperaturę z jednego czujnika nawet bez znajomości jego kodu (adresu) - wystarczy wysłać polecenie SKIP_ROM (0xCC) i jeśli tylko jeden czujnik jest podłączony, możemy z nim "rozmawiać". W przypadku dwóch czujników użyliśmy bardzo prostej chociaż nie idealnej metody, w której identyfikatory czujników zostały zapisane na stałe w programie.

Możliwa jest obsługa wielu czujników podłączonych do jednej linii 1-wire nawet jeśli nie znamy ich adresów. Komenda SEARCH_ROM (0x0F) pozwala na ustalenie kodów wszystkich podłączonych czujników. Wymaga to wielu odpytań i sam proces jest nieco skomplikowany, ale jego przeanalizowanie jest niewątpliwie interesującym ćwiczeniem. Osoby zainteresowane szczegółami więcej informacji znajdą w dokumentacji.

Po odczytaniu kodów podłączonych czujników możemy się z nimi komunikować w sposób opisany w kursie, czyli wybierając określony czujnik komendą MATCH_ROM (0x55). Niestety problemem jest rozróżnienie samych czujników - jeśli jeden mierzy temperaturę np. w pokoju, a drugi za oknem, chcielibyśmy pewnie wiedzieć, który wynik pochodzi z którego czujnika. Odpytywanie kodów z pomocą SEARCH_ROM pozwoli nam na komunikację czujnikami, ale nadal nie będziemy wiedzieli, który jest który.

Tutaj z pomocą przychodzą nam pola "T_H REGISTER OR USER BYTE1" oraz "T_L REGISER OR USER BYTE2", które znajdują się w "brudnopisie" (scratchpad) naszego czujnika. Możemy te pola wykorzystać do przechowywania w nich dowolnych wartości, co więcej te wartości mogą być zapisane w pamięci nieulotnej (eeprom). Mamy więc 2 bajty pamięci w każdym czujniku - niby niewiele, ale w zupełności wystarczy, aby rozróżnić czujniki. Gdybyśmy do pola "USER BYTE1" wpisali np. wartość 1 dla czujnika znajdującego się w pokoju, a 2 dla czujnika umieszczonego za oknem, nasz program mógłby działać bez przechowywania informacji o adresach czujników. Wystarczyłoby najpierw odczytać kody wszystkich podłączonych czujników używając komendy SEARCH_ROM, a następnie z pola "USER BYTE1" pobrać wartość z informacją, który czujnik gdzie się znajduje.

[Toomas]

2 godziny temu, Zealota napisał:

Doskonałe są te przykłady z kursu dla L4. Szacun!

Podpisuję się pod tym w 100%. Cały kurs i przykłady są ekstra. Przyznam, że dopiero podczas czytania tego kursu zrozumiałem w końcu różnice między realizacją niektórych tematów w sposób programowy i sprzętowy. Chyba nigdy bym nie wpadł na to, że uart można wykorzystać w taki sposób. Fajnie widzieć w praktyce oba podejścia. Na razie za mną lektura na sucho, ale na dniach ostro siadam do praktyki.

[Treker (Damian Szymański)]

@Toomas miło słyszeć, że się podoba i życzę udanych eksperymentów w praktyce - taka nauka jest najciekawsza 😉

[padus]

Dobrnąłem do ostatniej lekcji i musze przyznać, że bardzo dużo się nauczyłem. Odpowiedzi na forum, na pytania które zadawałem praktycznie pojawiały się natychmiast. Poszczególne części kursu super zrobione, praktycznie wszystko dopracowane. Wykonaliście olbrzymią robotę. 

Powoli będę odstawiał atmega328p, STM32L4 to naprawdę fajna sprawa.

Cytat

Cały kurs i przykłady są ekstra.

Cytat

Doskonałe są te przykłady z kursu dla L4. Szacun!

Nic dodać, nic ująć - pozostaje mi tylko się pod tym podpisać.

Mam rozgrzebaną płytkę od automatycznego czyścika do grotów na atmega. Chyba przerobię ją na STM32L - ot taki mały test tego czego się tu dowiedziałem.

[Treker (Damian Szymański)]

Dnia 30.07.2021 o 10:21, padus napisał:

Dobrnąłem do ostatniej lekcji i musze przyznać, że bardzo dużo się nauczyłem. Odpowiedzi na forum, na pytania które zadawałem praktycznie pojawiały się natychmiast. Poszczególne części kursu super zrobione, praktycznie wszystko dopracowane. Wykonaliście olbrzymią robotę. 

@padus dziękuję za miłe słowa, cieszę się, że kurs Ci się podobał 🙂 Przed nami jeszcze jedna część, ale już nietechniczna (podsumowanie i ostatni quiz) - trochę jednak przekładam ją w czasie, bo widzę, że sporo osób przechodzi dopiero przez wcześniejsze ćwiczenia. Opublikujemy podsumowanie, gdy więcej osób dojdzie do końca tej serii (na pewno do końca sierpnia).

[Vict]

Bardzo pomocny kurs!

Czy planujecie dodanie wpisów o bardziej zaawansowanej transmisji danych przez SPI, I2C, UART z przerwaniami i DMA? Szczególnie takie niebanalne przykłady, gdzie trzeba wplatać maszyny stanów i występuje wiele transmisji po sobie w określonej kolejności.

Z góry dziękuję za odpowiedź!

[Treker (Damian Szymański)]

@Vict witam na forum i dziękuję za miłe słowa. Cieszę się, że kurs Ci się podoba 🙂 Jeśli chodzi o opisywanie kolejnych zagadnień to wszystko zależy od zainteresowania czytelników. Na ten moment skończyliśmy publikację lekcji z tego kursu (będzie jeszcze tylko podsumowanie). Ewentualne inne zagadnienia będziemy mogli podjąć podczas ewentualnej kontynuacji tego kursu - jej powstanie zależy głównie od tego jaką popularnością będą cieszyły się materiały, które są aktualnie dostępnie 🙂

[fonak]

Witam,

Mnie także bardzo podobał się kurs i z niecierpliwością czekam na ewentualną nową edycje.

Zgadzam się również z kolegą Vict co do przedstawienia bardziej zaawansowanych tematów (np transmisja SPI z użyciem DMA taktowanym timerem, zaawansowane tryby ADC) nowych peryferiów (np. DFSDM, QUADSPI, SAI, USB) czy zastosowań DSP. 

Myślę że taki kurs mógłby się ukazać także dla rodziny STM32H lub STM32G ze wskazaniem na mniej typowe peryferia jak CORDIC, FMAC, MDMA, BDMA, HRTIM. 

Kurs debugowania (Keil, Ozone, CubeIDE, IAR) także by się przydał.

 

 

[Gieneq]

@fonak dziękujemy za pozytywny komentarz i sugestie. Na razie jesteśmy świeżo po wydaniu kursu, ale będziemy mieli to w pamięci 🙂 

[roz]

Czemu w kodzie pojawia się często delay_us? O ile w przykładzie to nie ma większego znaczenia o tyle w większym projekcie już może sprawiać problemy. To tak, jak z delay...