Układ DS18b20 - czas pomiędzy poleceniami 1Wire [bascom]

monokrysztal12 napisał:

Witam
Obsługuję czujnik DS18B20 w Bascomie.
Czy czas pomiędzy kolejnymi poleceniami, tj. 1wreset , potem 1wwrite &H55 , potem 1wwrite &HCC ... itd. może być dowolnie długi, przykładowo -np 6 minut; 5 godzin; 10godzin czy też 10dni .... ? Oczywiście wysyła 1 polecenie, czeka, wysyła drugie itd. do końca... Czy są ograniczenia?

NIE!
Te czasy (timingi) są ściśle określone w postaci ' time slots' (okienek czasowych) i wyrażane w µs.
Zapoznaj się z datasheet począwszy od str.14 i paragrafu "INITIALIZATION PROCEDURE: RESET AND PRESENCE PULSES" i dalsze paragrafy. Dodatkowo, bardzo przejrzyście jest to objaśnione na digramach tam umieszczonych dla każdej operacji.

Prestudiuj także te dwa przykłady: (1) pełnej komunikacji dla układu z wieloma DS oraz (2)z pojedynczym czujnikiem. Zauważ, że każda nowa transakcja/komenda jest inicjowana przez processor w postaci "Reset", po czym jest odpowiedź gotowości układu DS. Sygnały te muszą mieścić się w tych wyznaczonych przedziałach czasowych (slots). Tu następuje włściwa kommenda wpisu/odczytu, cokolwiek (jest ich tylko kilka), Jeżeli komunikacja nie jest kontynuowana, układ DS przechodzi w 'idle mode'.

Cytat:

Oczywiście będzie to pracowało w konfiguracji 2-Wire [zasilanie, masa, linia danych], bo 1Wire to kondensator trzymający energię w układzie się rozładuje.

Tu należy się mała poprawka:
Niezależnie jakiego rodzaju wybierzesz zasilanie (parasite czy zewnętrzne) to w dalszym ciągu jest to 1-Wire protocol.
DS18x20 jest urządzeniem obsługiwanym przez system 1-wire wyłącznie.

2-Wire jest zupełnie innego rodzaju kommunikacja (linia danych i clk). Tu nie ma linii 'clk' (zegara) dlatego timingi są tak istotne.

e marcus

monokrysztal12 napisał:

czyli jak przykładowo dam:
....
czyli flaga zmienia stan co ok. 1s,.....

Z przedstawionej informacji wynika że masz w systemie tylko jeden układ DS, więc nie ma potrzeby go adresować (&H55-match ROM). wystarczy 'skip ROM'.
Jeżeli flaga jest używana tylko do obsługi odczytu temperatury, to nie ma potrzeby aż tylu jej stanów (0/1/2/3; -wystarczy 0/1).
Jak to w praktyce by wyglądało:
Jeżeli masz postawioną flagę (1) 'idziesz' do dowolnie nazwanej subrytyny gdzie:
Zerujesz flagę.
W zwyczjny sposób nawiązujesz komunikacje z DS.
Odczytujesz (&HBE) do zadeklarowanej zmiennej pierwsze dwa bajty ze scratchpad.
Dajesz polecenie konversji temperatury (&H44), którą będziesz czytał w następnej sesji.
Opuszczasz sesje komunikacji z DS i Return z subrutyny.
Aby nie nastąpiła przypadkowa korupcja danych , możesz na czas komunikacji "zawiesić" wystąpienie ewntualnych interruptów (zależy co masz dodatkowo w programie).
Dalszą interpretacje odcztu i wyświetlenie wyniku umieścisz w głównej części programu.
Licz się z tym że wynik może posiadać pewne błedy - nie jest sprawdzany CRC
Pełniejszy przykład do przeanalizowania znajdziesz w publikacj AN#111.
Jest też wiele wątków na ten temat tu na tej grupie - średnio 2x w miesiącu.

e marcus

monokrysztal12 napisał:

Czy tak może być?

Nie.
Po komendzie:
"1wwrite &H55"
Spodziewana jest komenda wpisu adresu adresu device do której odnoszą się dalsze komendy, ponadto:
Błędem jest stosowanie tejsamej flagi (niby stopniowej) do wielu operacji bez jej kasowania. Zauważ że flaga=1, lub flaga =2 utrzymuje sie przez dłuższy czas, o wiele dłuzszy niż 'przewinięcie 'pętli głównej "Do..Loop", i za każdym razem wszystkie instrukcje powodowane tą flagą są wykonywane.
Daj oddzielna flage do obsługi odczytów temperatury i gdy wejdziesz w tą obsługę natychmiast ją kasuj, w ten sposów jest pewność że ta operacja będzie wykonana tylko jeden raz.

e marcus