Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Rozbudowany Emulator DS18B20

niveasoft 31 Gru 2015 14:27 6408 15
  • Witam.
    Przedstawiam układ który pozwala na podszywanie się pod czujnik temperatury DS18B20.

    Mógłby się przydać każdemu kto oprogramowuje/projektuje coś co wykorzystuje czujniki DS18B20 lub nawet jakiemuś monterowi czy serwisantowi.

    Ideą było to, żeby można było odłączyć działający czujnik temperatury, w razie potrzeby skopiować jego ID by się nim przedstawiać w układzie, i potem można było zadawać różne wartości temperatury sprawdzając jak zareaguje na nie badany układ.

    Pierwsza wersja miała tylko swój jeden ID i reagowała tylko na podstawowe polecenie SkipROM po czym dawała możliwość odczytu zadanej enkoderem temperatury.

    Nowsza wersja, ta którą przedstawiam, potrafi dużo więcej(SkipROM,MatchROM,SearchROM). Potrafi uczestniczyć w dynamicznej funkcji wyszukiwania wszystkich urządzeń na linii, potrafi reagować na wywołanie swojego ROM_ID oraz nie wtrąca się kiedy odpytywane są inne czujniki. Pozwala więc na prace w środowisku większej ilości czujników.

    Zwykły czujnik DS18B20 nie ma nic innego do roboty tylko konwersje temperatury i ewentualne odpowiedzi na zapytania Mastera. Układ Emulatora musi łączyć dwie funkcje - responsywność na zapytania Mastera i responsywność na zadawane enkoderem zadania czyli wyświetlanie zadanych ustawień jak i zachować absolutną responsywność na zapytania Mastera układu w którym udaje czujnik.
    Było to priorytetem przy oprogramowywaniu i "kręcenie enkoderem" czy zapisywanie ustawień nie ma absolutnie wpływu na to jak układ przedstawia się w systemie w którym emuluje czujnik.

    Schemat działania z założenia ma być taki:
    Możemy odłączyć dowolny czujnik DS18B20 w systemie i podłacząjąc go na sekundę do emulatora kopiujemy jego ID.

    Urządzenie działa tak że kiedy naciskam przycisk enkodera sprawdza czy w gnieździe służącym do przyuczenia nowego ID włożony jest jakiś układ 1Wire. Jeśli tak to wydaje mu komendę ReadROM, jeśli nie wykryje żadnego czujnika w złączu to jest to zwykłe przyciśnięcie enkodera i zmienia skok o jaki zmieniana jest temperatura przedstawiana przez emulator.

    Możemy temperaturę zmieniać z rozdzielczością 0,1st, 0,5st i 1st

    Obsługa uproszczona do minimum

    Kiedy włożymy do gniazda czujnik i naciśniemy przycisk enkodera uczy się RomID czujnika
    Kiedy w gnieździe nie ma czujnika to zmienia w kółko rozdzielczość z jaką ustawiamy temperaturę 0,1st->0,5st->1st->0,1st itd

    Długie naciśnięcie przycisku enkodera powoduje zapamiętanie ustawionej aktualnie temperatury i ta temperatura będzie też ustawiona przy ponownym uruchomieniu.

    Tak samo wprowadzony ID czujnika zostaje zapamiętany i przywracany przy starcie urządzenia. Jeśli chcemy "wypisać" zapamiętany ROM_ID to wystarczy przycisnąć przycisk enkodera podczas włączania urządzenia. Odzyska swój własny ROM_ID.

    Rozbudowany Emulator DS18B20 Rozbudowany Emulator DS18B20 Rozbudowany Emulator DS18B20

    Teraz trochę o konstrukcji.
    Program pisałem na innym mikrokontrolerze a na końcu załadowałem do Mega8 ponieważ ona kosztuje 3zł50gr...

    Program zajmuje 60% tej Atmegi bez jakichkolwiek wysiłków w celu zoptymalizowania. Wolę jednak mieć pole manewru i zostawić sobie miejsce niż pokazywać czego to nie da się upchnąć.

    Płytka powstała wczoraj w dwie godziny a projekt pokazuję też po to by skonsultować z Kolegami ewentualne uwagi.

    Myślałem nad zabezpieczeniem linii 1Wire, ale ten układ jest nieaktywny na linii dopóki nie uaktywni się go przynajmniej sekwencją "stan niski na wejściu >480us -<960us" więc przy zwarciu do plusa się nie odezwie, ani przy zwarciu do masy też.
    Może ktoś zaproponuje zabezpieczenie przed podłączeniem jakiegoś wyższego napięcia.

    Chętnie rozważę każda inną konstruktywną uwagę

    Poniżej filmik który po Nowy Roku postaram się nagrać w lepszej jakości


    Link


    Fajne!
  • #2 31 Gru 2015 16:15
    M. S.
    Poziom 34  

    Dobry pomysł. Nie trzeba przypiekać ds'a zapalniczką. Co do zabezpieczenia to myślę, że ktoś, kto będzie tego narzędzia używał raczej wie co robi.

  • #3 31 Gru 2015 16:56
    SylwekK
    Poziom 28  

    Świetny pomocnik! Ależ by mi się to przydało jak testowałem mój sterownik pieca.
    Proponuję, o rozbudowę o dodatkowe kanały, aby zadawać kilka temperatur jednocześnie i dodać bajery w postaci automatyczne narastanie/opadanie temperatury w jednostce czasu - jak dla mnie była by to bardzo przydatna opcja i idealna do testowania czasowych algorytmów sterowania temperaturą.

  • #4 31 Gru 2015 18:06
    ZbeeGin
    Poziom 38  

    Wszystko pięknie i ładnie, tylko czy stworzenie urządzenia 1wire pracującego jako Slave nie jest (dalej) naruszeniem IP Dallas-a...

    Cytat:
    Dallas' intellectual property in the 1-Wire product area is structured around the 1-Wire slave devices. Regarding 1-Wire masters, however, the user is free to implement those in a variety of ways.
    At this time we have not yet authorized anyone outside of Dallas Semiconductor to create 1-Wire slave devices.

  • #5 31 Gru 2015 18:11
    niveasoft
    Poziom 34  

    Cytat:
    ... to create 1-Wire slave devices
    ..
    my device clone and then emulate /(not create) existing device so where is the problem :P

  • #6 31 Gru 2015 22:37
    nsvinc
    Poziom 34  

    niveasoft napisał:
    my device clone and then emulate /(not create) existing device so where is the problem

    licencja zabrania sprzedawać urządzenia będące slave'ami 1wire. Emulator udaje slave'a 1wire, wiec strice slave'm nie jest, w szczegolnosci, ze zaznaczone zostało, że jest to emulator.
    Z tego wynika, że nawet sam emulator można opychać, dopóki ma on status urządzenia R&D [debugger sieci 1wire] a nie komerycyjnego czujnika będącego zgodnym z protokołem.

  • #8 02 Sty 2016 20:24
    Karol966
    Poziom 30  

    nsvinc napisał:
    licencja zabrania sprzedawać urządzenia będące slave'ami 1wire

    Zastanawia mnie ocena tego postu przez innych użytkowników - w chwili pisania mojego postu było to -5 :D

    Do autora: Do jakiego pinu procesora podłączyłeś emulowany pin 1W? W sensie czy wykorzystujesz jakieś sprzętowe peryferia typu przerwania zewnętrzne/ timer a może jeden z istniejących interface diagnostycznych?
    PS. I wszystko w Bascomie? ;)

  • #9 02 Sty 2016 20:44
    nsvinc
    Poziom 34  

    Karol966 napisał:
    Zastanawia mnie ocena tego postu przez innych użytkowników

    Mnie też zastanawia za co mnie zminusowali...
    Czyżby, zgodnie z sondażami, większość Polaków miało problem z czytaniem ze zrozumieniem?

    Karol966 napisał:
    W sensie czy wykorzystujesz jakieś sprzętowe peryferia typu przerwania zewnętrzne/ timer

    Dobre pytanie. Niekoniecznie mógł wykorzystać UART, więc chyba kręci się wokół timera i przerwania na pinie...

    Karol966 napisał:
    PS. I wszystko w Bascomie?

    Precyzja rzędu mikrosekund w Bascomie dla mnie wydaje się być zatrważająca...

  • #11 06 Sty 2016 14:17
    niveasoft
    Poziom 34  

    Witam. Program napisałem w Bascom. Po bliższym poznaniu pisze mi się w nim z łatwością.
    Wiele rzeczy stało się możliwych po tym jak opanowałem obsługę zachowywania potrzebnych rejestrów przez siebie, a nie pozostawiania tego kompilatorowi.
    Może kiedyś to poprawią i może przyczyni się do tego narzędzie które stworzyłem na swoje potrzeby NoSave Tool
    Rozbudowany Emulator DS18B20

    Szybko sprawdza które z rejestrów zostały użyte w przerwaniu i podpowiada zachowanie tylko ich. Tak wiec czasem zamiast odkładać i ściągać trzydzieści rejestrów odkładam tylko jeden :D
    Przekłada się to oczywiście na szybkość i elastyczność kodu.

    Tak jak napisałem - może to narzędzie przyczyni się do tego, że kompilator będzie to robił sam.
    Dla mnie Bascom to jak motorower. Wiem że zdrowiej byłoby gdybym jeździł tylko na rowerze, ale mam motorower i samochód i to je częściej wybieram.

    Życzę Wszystkim miłego dnia i przyjemności z tworzenia

  • #12 04 Lut 2016 12:01
    DJ ANNUS
    Poziom 31  

    nsvinc napisał:
    licencja zabrania sprzedawać urządzenia będące slave'ami 1wire


    A to mnie ciekawi to znaczy że żadnego ukłądu slave nie można sprzedać, przecież ja kupuje często układy slave.... i sa w sklepach.

  • #13 04 Lut 2016 12:05
    niveasoft
    Poziom 34  

    Sprzedając urządzenie zawsze mógłbym dołączać DS18B20 i paragon do niego. Nabywca miałby pełne prawo skopiować sobie ID czujnika który kupił i udawać go w systemie mikroprocesorowym.

  • #14 10 Lut 2016 22:29
    bobeer
    Poziom 28  

    Bardzo praktyczny projekt (brak schematu, trudno doradzać odnośnie zabezpieczeń, hasło transil i oporniki powinno wystarczyć).
    Na marginesie. Nie marnuj kolego talentu na bascoma, tylko czym prędzej zajmij się C. :), tym bardziej że zająłeś się już grzebaniem w rejestrach. No chyba że wolisz asm ;)

  • #16 23 Kwi 2017 04:32
    R-MIK
    Poziom 35  

    niveasoft napisał:

    Myślałem nad zabezpieczeniem linii 1Wire, ale ten układ jest nieaktywny na linii dopóki nie uaktywni się go przynajmniej sekwencją "stan niski na wejściu >480us -<960us"

    Emulujesz więc musisz akceptować reset do 3,8ms.
    Czy pomiędzy bitami może być dowolnie długi stan wysoki i emulator nie przestanie w takiej sytuacji odpowiadać/interpretować ramki? Podobnie stan wysoki po reset i presence, czy moze byc dodolnie długi?

Szybka odpowiedź lub zadaj pytanie
Dziękuję Ci. Ta wiadomość oczekuje na moderatora.
 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME