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

[AVR] - [Bascom] Czas odczytu 15szt DS18B20

Jacek Rutkowski 04 Sty 2014 19:30 6831 47
  • #31
    Jacek Rutkowski
    Poziom 26  
    Nie mam jeszcze 15 sztuk, mam jednego DS-a i 5szt LM35.
    Nie oczekuję cudów tylko odpowiedzi jeśli ktoś używa DS-ów w większej ilości ile czasu trwa sama transmisja danych.
    Każdy powtarza 750ms a nie o to pytam.
    Jeśli miałbym chociaż z 5szt DS-ów bym sprawdził ale nie chciałem płacić za nie i kuriera żeby sprawdzić.
    Jednak to chyba będzie najszybsze, kupie 5szt i sam sprawdzę czas transmisji danych, chociaż odwlekałem ze względu na świąteczny czas i zapchanie poczty prezentami.
  • IGE-XAO
  • #32
    Milek79
    Poziom 15  
    Jak czas transmisji danych? Wysyłasz do wszystkich DS polecenie zmierzenia temperatury (kilka/kilkanaście ms albo mniej), czekasz 750 ms i odbierasz dane ze wszystkich (kilka/kilkanaście ms albo mniej). Dokładne czasy możesz wyliczyć na podstawie szybkości transmisji i ilości przesyłanych danych.
  • #33
    tank_driver
    Poziom 16  
    Cytat:
    Jak czas transmisji danych? Wysyłasz do wszystkich DS polecenie zmierzenia temperatury (kilka/kilkanaście ms albo mniej), czekasz 750 ms i odbierasz dane ze wszystkich (kilka/kilkanaście ms albo mniej). Dokładne czasy możesz wyliczyć na podstawie szybkości transmisji i ilości przesyłanych danych.


    No i właśnie o wyliczenie tych dokładnych czasów tutaj chodzi, jak obsłużyć DS-a to my już dawno wiemy. A to czy DS jest lepszy czy gorszy od LM, XX czy YY to też nas nie interesuje. Jest konkretny problem i może na nim się skupmy, bo będziemy się przekrzykiwać aż autor straci ochotę do dalszych prac.

    Co już wiemy:

    - Przewody na 1W (two-wire) możemy ciągnąć, przy zastosowaniu odpowiedniego przewodu aż do 500m (w/g MAXIMA).

    - Większość czasu zajmuje sprawdzenie 64 bitowego numeru układu, co jest do powtórzenia przy każdym odczycie tyle razy ile mamy układów. W tym czasie uP nie będzie robić nic innego bo nie może (szczególnie w BASCOM-ie gdzie tak naprawdę nie wiemy na jakie rozkazy ASM się to skompiluje i czy po wyjściu z przerwania program wskoczy gdzie powinien, z zawartością rejestrów jak być powinno i czy sam z siebie operacji nie powtórzy). Postaramy się ten czas skrócić do minimum, na przykład wykorzystując tylko jeden bajt z ośmiu tych numerów (8 bitów z 64), jeśli Basom/DS to obsłuży i jeśli ten bajt będzie dla każdego z układów unikatowy. W ten sposób będzie można teoretycznie obsłużyć do 256 układów * ilość nóżek uP wykorzystywanych do transmisji 1W.

    - Do sprawdzenia jest kontrola CRC, chociaż przy poprawnej instalacji czujników i zastosowaniu odpornego na zakłócenia przewodu nie powinno być problemu z zakłóceniami. Dodatkowo biblioteka Bascoma "mocno" steruje linią 1W (zmieniając stan pinu z wejścia na wyjście w zależności od potrzeb), co stanowi dodatkową linię obrony przez zakłóceniami.

    - Autor nie chce inwestować w dodatkowe uP które będą obsługiwać wyłącznie komunikację 1W, co notabene pozwoliłoby na łatwe usunięcie problemu długich czasów obsługi w przypadku wielu czujników.

    Najlepiej jak dokupisz te 5 DS-ów - zawsze do czegoś będzie można je wrzucić.

    Ja postaram się (w miarę możliwości z zakresu wiedza i czas) pomóc.

    Pozdrawiam,
    TD
  • #34
    Jacek Rutkowski
    Poziom 26  
    tank_driver napisał:
    No i właśnie o wyliczenie tych dokładnych czasów tutaj chodzi, jak obsłużyć DS-a to my już dawno wiemy.

    Dokładnie od początku o to pytam i nikt nie jest w stanie mi na to pytanie odpowiedzieć.
    Nie mam zbytnio zastosowania dla DS-ów ze względu na to iż używam namiętnie LM35 z powodu na łatwość diagnozowania analogowego sygnału i prostotę pomiaru.
    Kupię te kilka DS-ów i sam odpowiem sobie jak te czasy wyglądają.
  • #35
    vinetu_
    Poziom 12  
    Skoro to Atmega128, to masz 53linie I/O, jeśli podepniesz każdy czujnik do osobnej nogi, wrzucisz mocniejszy kwarc, to możesz odczytywać te DSy (pseudo)równolegle i łączny czas odczytu wyniesie Ci czas odczytu jednego DSa + kilka cykli na przełączenie, dodatkowo, jeśli chcesz odczytywać co 10sec stan temperatury, to po 8.5sec od ostatniego odczytu wydajesz polecenie konwersji równolegle na wszystkie piny.
    Oczywiście nie musisz łączyć każdego DSa do osobnej nogi, możesz je sparować po 2 (8 pinów), 3 (5 pinów), 5 (3piny), z tym że z każdą zaoszczędzoną nogą zwiększa Ci się czas odczytu.
    Wyliczanie CRC zajmie więcej czasu, bo tego już nie da się równolegle, trzeba lecieć szeregowo, ale masz prawie 16000 cykli na każda milisekundę.
    W kwestii kodu, masz 128kb pamięci, jeśli przeznaczysz max 4kb, to chyba Ci jej nie zabraknie, RAMu też Ci starczy.
    Mając 16MHz kwarc, masz czas na inne operacje podczas odczytu DSów.

    Tylko czy ten nieszczęsny Bascom da radę?
  • #36
    Milek79
    Poziom 15  
    Podłączanie każdego DS do osobnej nogi? Czego to ludzie nie wymyślą :P. Przecież (tylko chyba trzeba podłączyć wszystkie 3 piny w DS) można chyba wysłać do wszystkich DS polecenie odczytu, odczekać 750ms i odczytać ze wszystkich odczytaną wartość.
  • IGE-XAO
  • #37
    MArSTER_1
    Poziom 19  
    Czas odczytu 7 sztuk DS18B20 z pobraniem numeru czujnika z tablicy ze sprawdzeniem CRC wyniku ATmega kwarc 18,432 MHz 12,5 milisekundy.

    Dodano po 16 [minuty]:

    Koryguję czas podany poprzednio. Nie zauważyłem przeniesienia. Ten czas wynosi 26,8 milisekundy.
  • #38
    slx
    Poziom 18  
    @MArSTER_1
    A możesz powiedzieć jak to mierzyłeś? Bo wydaje mi się, że zakrzywiasz czasoprzestrzeń ;)

    Time slot wynosi min: 60us, max: 120us czyli ~0.5ms - ~1ms na bajt.
    [MATCH ROM]+8*[ROM CODE]+[READ SCRATCHPAD]+9*[SCRATCHPAD] i mamy 19 bajtów do przesłania po 1W + czas resetu ~1ms, co daje z grubsza od ~10ms do ~20ms na jeden czujnik.
    Jeżeli zrezygnujemy z CRC, mamy zamiast 9*[SCRATCHPAD] 2*[SCRATCHPAD], czyli ~7ms do ~13ms na czujnik. Odczytanie 15 czujek to minimum 100ms, licząc same time-sloty + reset, nie uwzględniajac odstępów miedzy bitami i narzutów bascoma.

    @Jacek Rutkowski
    Przysłowie mówi: Nie naprawiaj tego co nie zepsute. :)
    Jeżeli się sprawdza to co masz teraz, nie ma sensu zmieniać na DS18B20 - czasowo będzie dużo gorzej.
  • #39
    MArSTER_1
    Poziom 19  
    Liczyłem impulsy z Timera0. Częstotliwośc kwarcu dzielę przez 1024 co daje mi 18kHz taktujących Timer0. Przed wejściem w petlę odczytującą 7 czujników ustawiam w timerze wartość zero i zeruję zmienną odpowiedzialną za liczenie przepełnień Timera0 w przerwaniu. Zmienna licząca ilość przepełnień wyświetla się jako 1 a liczba impulsów w Timerze0 jako 226.
  • #40
    vinetu_
    Poziom 12  
    Milek79 napisał:
    Podłączanie każdego DS do osobnej nogi? Czego to ludzie nie wymyślą :P. Przecież (tylko chyba trzeba podłączyć wszystkie 3 piny w DS) można chyba wysłać do wszystkich DS polecenie odczytu, odczekać 750ms i odczytać ze wszystkich odczytaną wartość.


    Kolego, autor trąbi na dwóch stronach tego tematu że chodzi mu o odczyt, nie konwersję, proszę przeczytać WSZYSTKIE posty!
    ______________________________


    Swoją drogą, nadal nie rozumiem, dlaczego autor tematu, dysponując tak dużym procesorem, nie napisze sobie obsługi DSów w tle, wtedy czyta się tylko rejestry w SRAM i dostaje się aktualna temperaturę, no chyba ze ma jakiś dziwny dom i w nim potrafi się zmienić w ciągu 20ms o parę stopni :D
  • #41
    Jacek Rutkowski
    Poziom 26  
    vinetu_ napisał:
    Swoją drogą, nadal nie rozumiem, dlaczego autor tematu, dysponując tak dużym procesorem, nie napisze sobie obsługi DSów w tle, wtedy czyta się tylko rejestry w SRAM i dostaje się aktualna temperaturę, no chyba ze ma jakiś dziwny dom i w nim potrafi się zmienić w ciągu 20ms o parę stopni :D

    Kolego moja ATMega nie tylko czeka na odczyty z czujników temperatury ale będzie mieć wiele innych rzeczy do roboty w pętli głównej z flagami z przerwań i nie chcę zajmować jej na dłużej niż kilka ms jedną rzeczą.
    Skoro zauważyłeś że nie o czas konwersji mi chodzi to uściślę jeszcze że zmiany szybsze niż w 30s o 1 czy 2°C w powietrzu są niezauważalne dla tych czujników. Mi nie zależy na odczycie co 20ms tylko co np 10s i dane mogą pochodzić z przed 10s. Temperatury będą mierzone na piecu CO, CCWU, wewnątrz pomieszczeń, na zewnątrz itp ale poza nimi mierzone będzie nasłonecznienie, prędkość wiatru, zużycie prądu, wody, sterowanie częścią oświetlenia, pompami CO i CCWU, sterowany będzie alfanumeryczny LCD oraz obsługiwana klawiatura i komunikacja po USART.
    Po woli zaczynam się zastanawiać czy nie dać zewnętrznego ADC np. ADC121S021CIMF żeby "odzyskać" parę pinów, obecnie wszystkie kanały ADC wykorzystuje + 3 piny do CD4051. Rozdzielczość będzie lepsza przy większej szybkości odczytu. Z nadpróbkowaniem także mógłbym zejść np do 4 razy.
  • #42
    vinetu_
    Poziom 12  
    Dajesz analoga przy sterowniku, ciągniesz kable przez pół domu, niby nic, ale one też reagują na temperaturę, nie wiele ale wprowadzają przekłamania, w dodatku detekcja błędu jest trochę trudniejsza.

    Przy zastosowaniu mojego sposobu (proces w tle), jedynie podczas startu urządzenia masz przez 20ms brak danych z czujników, ale mijasz to w inicjalizacji.


    Wciąż nie wszyscy rozumieją mnie co mam na myśli, a mam na myśli WIELOWĄTKOWOŚĆ.
    Tak, na AVR, da się, tylko trzeba się troszkę wysilić (chociaż nie wiem jak to będzie w Bascomie, bo on to taki średnio elastyczny - ale to tylko moje wrażenie).

    Zaznaczam, przy 16MHz kwarcu, mamy 16 tysięcy(!) cykli na każdą milisekundę, większość poleceń wykonuje się w jednym cyklu.

    Inna opcja dla leniwych/nie mających zbyt wiele czasu lub umiejętności:
    AtMega8 kosztuje ~4 zł, taktowana zegarem 1MHz zużywa <3mA, jednocześnie oszczędzasz swój czas, przy produkcji seryjnej jest to nie ekonomiczne, natomiast dla jednej sztuki, niezauważalne, pozostaje pytanie: wolisz zapłacić ~4zł czy spędzić x godzin nad dopieszczaniem kodu? Wybór należy do Ciebie.
  • #43
    Użytkownik usunął konto
    Poziom 1  
  • #44
    Jacek Rutkowski
    Poziom 26  
    Mam w domu położone kable LAN cat 5e średnio po 2 w każdym pomieszczeniu, wszystkie w topologi gwiazdy schodzą się w pomieszczeniu gospodarczym (schowku przy kuchni na parterze, w przybliżeniu po środku domu). Dodatkowo dorzucone LAN-y do tunera SAT, TV, drukarki sieciowej oraz 3 LAN-y i 6 żył 1mm2 do kotłowni.
    Instalacja elektryczna nie jest przewidziana pod centralne sterowanie, po 1 obwodzie na gniazdka w pokojach, oświetlenie po 2 pomieszczenie na obwodzie.
    Chcę tylko monitorować temperatury oraz sterować kilka obwodów. Wydaje mi się iż rozbijanie tego na kilka procesorów jest bez większego sensu. W przypadku awarii grozi mi ręczne załączanie oświetlenia ewentualnie pomp. Piec do CO to tzw 'śmieciuch' bez nadmuch oraz bez podajnika z termostatycznym otwieraniem klapy nawiewowej oraz termostatycznym zaworem bezpieczeństwa służącym zabezpieczeniu instalacji przed przegrzaniem. Centralne działa w układzie otwartym z grawitacyjnym obiegiem ze zwiększonymi przekrojami rur. Układ działa poprawnie także przy zaniku zasilania jedynie konieczne będzie spuszczenie większej ilości wody aby uzyskać ciepłą w kranie oraz nie będzie grzała podłogówka w kuchni i łazienkach.
    Całość ma służyć głównie monitorowaniu więc uważam że powinien jeden procesor dać radę. W przypadku chęci zmian czy rozbudowy systemu infrastruktura może pozostać jedynie w poszczególnych pomieszczeniach zamiast samych czujników mogę dokładać czujniki ale nie przewiduję tego w najbliższym czasie.
  • #45
    vinetu_
    Poziom 12  
    Przy tak prostych zadaniach i nie obsługiwania krytycznych obwodów, jeden procesor AtMega128 spokojnie Ci wystarczy, nawet DSy nie wymagają równoległego odczytu.

    Pomyśl o wielowątkowości i zegarze 16MHz, spokojnie ze wszystkim się wygrzebiesz, a nawet śmiem przypuszczać że zostanie Ci wolny czas.

    Jedyne czego bym sie obawiał to to czy Ci bascom nie zapcha SRAMu
  • #46
    Mateusz@
    Poziom 17  
    Do realizacji 1-wire można wykorzystać USART.
  • #47
    Tom1988p
    Poziom 16  
    Cytat:
    ...Wydaje mi się iż rozbijanie tego na kilka procesorów jest bez większego sensu. W przypadku awarii grozi mi ręczne załączanie oświetlenia ewentualnie pomp. Piec do CO to tzw 'śmieciuch' bez nadmuch oraz bez podajnika z termostatycznym otwieraniem klapy nawiewowej oraz termostatycznym zaworem bezpieczeństwa służącym zabezpieczeniu instalacji przed przegrzaniem...


    Masz rację, wydaje Ci się. Popatrz z tej strony, awaria jednego układu a musisz już ręcznie włączać i wyłączać oświetlenie oraz pompy. Rozbij to na dwa procesorki, jeden to głównie obsługa kotła CO i ewentualnie wszystkich czujników, a drugi reszta domu. Po awarii jednego będziesz musiał tylko oświetlenie lub pompy ręcznie obsługiwać a nie wszystko.
    Nawet jak zbudujesz idealny układ "100 w 1" to jak przyjdzie czas wymiany kotła (a przyjdzie) i będziesz chciał dodać obsługę wentylatora czy podajnika, wtedy będziesz musiał od nowa zgrywać cały układ w całość co może zająć trochę czasu. Wiem że może być tak że nowy kocioł to razem ze sterownikiem zostanie zakupiony.
    Jest to moje skromne zdanie, mi zawsze mówiono że jak coś jest do wszystkiego to jest do niczego.

    Warto się zastanowić czy 15zł w okresie 3 lat (przykładowo) opłaci się oszczędzić.

    Wielowątkowość to na avr trzeba raczej rozumieć jako programy nie blokujące przez funkcje Waitms (_delay_ms() w C), Po prostu nie ma przestojów w miejscu (przykład z odczytem czujników podałem w tym temacie), a nie że dwa lub więcej wątków przetwarzanych jest równolegle.
  • #48
    vinetu_
    Poziom 12  
    Tom1988p: wtedy to wcale nie jest wielowątkowością.
    Przy moim przykładzie, namachasz sie semaforami niemiłosiernie, jest "trochę" więcej kodu do napisania, bardziej sztywne ramy czasowe, trochę cykli schodzi na przełączenie, ale uzyskujesz prawie system czasu rzeczywistego. Tak, to da się napisać na AVR (oczywiście trochę większe, pakowanie się z tym na mega8 jest masochizmem).


    Autor wyraźnie napisał do czego będzie mu służyło urządzenie (4 posty wyżej). Jeśli ma pełnić funkcję tylko monitora, to nie ma sensu pchać większej ilości procesorów i rozbijać to na moduły.
    Co do tego "w przyszłości" elektronika tanieje z roku na rok i wchodzą coraz to lepsze układy, jesli następna zmiana układu ma być za ~3 lata (i to nie jest pewne), to nie ma sensu teraz się pchać w koszta i robić wiele rzeczy na siłę.