Witam wszystkich,

mam mały problem z odczytem danych, męczę się już 2-gi dzień i nic.O co chodzi konkretnie.... Ostatnio miałem chęć dorobić sobie 2-gi termometr, który będzie w pokoju. Oczywiście sięgam do zasobów i co? jak na złość DS1621 na I2C, szkoda bo 1Wire jest świetnie opisany w książce naszego GURU .Pomyślałem, sobie skoro z STMPE811 na I2C dałem rade to spróbuję tutaj i okazało się, że jednak nie...

Note katalogową tego układu już znam prawie na pamięć , nie próbuję jeszcze konwertować tego zapisu bitów(dodatnie to znak moduł a ujemne U2) na np. wyświetlacz LCD lub 7-segmentowy. Dla testów chciałem uruchomić układ i do tego uruchomić rs232/usb żeby testować jakie bajty dokładnie odbieram. Wynik jaki otrzymałem jest dziwny bo pokazuję mi cały czas (temperatura ujemna ):
MSB: 10010001
LSB: 10010001
Mało tego, wyświetla mi tylko 6-7 razy i się zawiesza....a przecież jest pętla nieskończona ;/
Szukałem na forach rozwiązań i powiem szczerze, co kraj to obyczaj....
Poniżej przedstawiam główny program main.c, w niej mam całą inicjalizację układu. Jeżeli ktoś miał przyjemność zabawy z tym układem i go poprawnie uruchomił proszę o pomoc.

Przerobiłem(rozbudowałem) funkcję "TWI_read_buf" jednak nie wiem czy mogę wrzucić, bo jest to na bazie biblioteki Pana Mirka.
Co do samego układu DS1621 to oczywiście linie SDA i SCL podpięte pod rezystor 4,7k, wyjścia adresowe A0,A1 i A2 zwarte do masy.



Z góry dziękuję za pomoc i cenne uwagi.

Po tym co masz wysyłaj start, adres zapisu, read_temp, ponowny start, adres odczytu, i odczytujesz 2 bajty danych.
Aha, i usuń link bo niepotrzebnie stronę rozszerza, a jak każdy chce to to 10 sekund wstukać w google

------------------------ [ Dodano po: 6 minutach ]

Jeszcze jedna rzecz i to dużo ważniejsza.
Tablice bufor traktujesz jako 2-elementową, a deklarujesz jako 1-elementową, efekt - wyciek danych o którym niestety kompilator cię nie poinformuje.

_________________
sig off ;(

dzieki krafin na szybką odpowiedź, z tablicą faktycznie dałem ciała, zmieniłem i jednak dalej to samo...
Co do funkcji TWI_read_buf to wykonuje w niej:
- start
- zapis adresu urządzenia // bez tego wyświetla mi same 0
- adres zapisu
- read_temp
- start
- zapis adresu urządzenia
- adres odczytu
- odczytuje 2 bajty z TWDR do tablicy
- stop

Nie wiem dalej gdzie leży błąd....ponadto układ wysyła tablice z 6-7 razy i zawieszenie...

Zaraz, zaraz powoli


rozumiem tu zaszła pomyłka, z tymi dwoma zapisami adresu?
Drugie to:


Jak odczytujesz z TWDR, a zapis ack do DSa

Użyj zamiast tego funkcji do odczytu z twi, nie mam greenbook'a dlatego nie wiem czy jest ale na 99% będzie.
Teraz do 1 komórki tablicy odczytujesz z potwierdzeniem ack, do drugiej nack i stop.
Teraz powinno wszystko wrócić do normy

------------------------ [ Dodano po: 7 minutach ]

Jeszcze jedno, pomiędzy start conversion a read_temp, powinna być przerwa (można czytać rejestr konfiguracyjny ds, i czekać na ustawienie bitu done) albo zaczekać (nie wiem ile - w nocie nie piszą, na początek spróbuj 1s) i dopiero odczytywać temperaturę.

_________________
sig off ;(

Dzięki wielkie krafin, faktycznie miałem błąd już na początku adresowałem 2 razy....
Co do odczytu TWDR to korzystam z funkcji odczytu TWI z greenbooka wiec wszystko już działa w 100%

Martwi mnie tylko jeden fakt, po dokonaniu 10 pomiarów transmisja rs232/usb się zacina i nic nie wysyła .... co jest dziwne bo jak usunę oczekiwanie 1s to wysyła wszystko poprawnie (szybko co 0,2 s)


Co do "zawiechy" to zauważyłem moment w którym się to dzieje, mianowicie kiedy temperatura się zmienia i nadpisywane są te 2 bajty danych w tablicy....coś jak by się działo z buforem RSa ... gdy temp zmienia się np. z 23->22 albo 22->23 to własnie się tak dzieje...

1. Inicjalizację zmiennych LSB, MSB, bufor[] wywal z petli głównej do maina, oraz zadeklaruj wszystko jako uint8_t.
2. Czy dodałeś jakieś opóźnienie przed odczytem temperatury?

_________________
sig off ;(

Zrobiłem tak jak napisałeś, zmienne wrzuciłem do maina i zadeklarowałem jako uint8_t
Mam opóźnienie 1s przed odczytem temperatury. Myślałem, że to coś z buforem RSa jednak dla testów sprawdzam program diodą LED. W każdym cyklu while() dioda zmienia swój stan, niestety po kilku odczytach dioda się zawiesza.... nie jest to ciągle ten sam cykl, np. 14, 2, 5. Naprawdę nie wiem co tu jest nie tak. Poniżej przedstawiam poprawiony main():

Właśnie też kiedyś miałem problem z i2c ale z zegarkiem pcf8583, ale nie pamiętam już jak to rozwiązałem, ale wiem, że blokowało się przy twi_stop(), dlatego lekko ją zmodyfikowałem, aby wiedzieć w którym momencie się blokuje (ale sama w sobie nie zablokuje procesora).


Jeśli więc zablokuje się w tym miejscu będziemy o tym wiedzieć (wysyłaj wartość zwracaną przez tą funkcje na rs), jeśli wszystko będzie ok zwróci 1 inaczej 0.

_________________
sig off ;(

Zrobiłem tak jak napisałeś, pętla popracowała trochę dużej niż dotychczas ale i tak się w końcu zawiesza.
Wyświetlam sobie tak:
1 // 1 z TWI_stop
MSB: 25
LSB: 10000000

wyświetlał cały czas tą 1 aż w końcu się zawiesił, ostatnie wyświetlenie było już tylko:
1, bez MSB i LSB, tak jakby nie źle odczytywał bajty....

A tą 1 z twi_stop(), to wyświetlałeś w którym miejscu? Przy start conversion?
Ale gdzie by to nie było ta pętla powinna się skończyć, kurcze to coś innego blokuje.
No i jedna rzecz mi nie pasuje - MSB=25 oraz LSB=128 oznacza temperaturę 3264 C.
Więc wygląda na to, że źle czyta temperaturę.

Wrzuć tylko jeszcze zaraz przed pętla główna taki kod

i zobacz czy się poprawi.

Włączy to tryb 1shot w którym każda konwersję trzeba inicjalizować (czyli tak jak masz teraz) domyślnie jest tryb ciągłej konwersji.

_________________
sig off ;(

Co do 1 to tak, wyświetlana była przy start conversion.
Co do odczytów wydaje mi się, ze pokazuje dobrze bo wynik
MSB: 25
LSB: 10000000
to MSB czesc całkowita 25 C i 1 na lewo w LSB mówi o tym, że jest to dokładnosc 0,5 C
wiec łacznie 25,5 C

Spróbowałem tak jak mówiłes tryb 1shot i pętla wykonuje się też tylko kilka razy..

Mam jeszcze jedną sugestie, bo bajty odczytywane są bardzo dziwne, według mnie w domowych warunkach gdzie robie testy zawsze powinno być :
MSB 000xxxx i LSB x0000000 a po rs'ie jak widzę czasami pokazują się dziwne wartości bo np.
dla MSB są czasami 11111111 co wskazuje "nic" i przy LSB czasami są 11111111 gdzie dla mnie to duży błąd odczytu bo powinno być tylko albo 10000000 lub 00000000 dla LSB.Zauważyłem, że dzieje się tak gdy temp się zmienia np. z 25->24 i wtedy pokazują się te dziwactwa i się zawiesza....
Nie wiem już naprawdę jak tą temp odczytać....

Oooo przepraszam bardzo, zapomniałem się, że tutaj temp. jest inaczej podawana, i liczyłem tak jak dla ds18s20.

Kurcze, naprawdę nic mi do głowy nie przychodzi, jedyne to dodaj do każdej funkcji twi, w miejscu pętli while taki prosty mechanizm który zabezpieczy przed zawieszaniem się procka i zobacz co wtedy się stanie.

_________________
sig off ;(

no tak ale nie wiem jaki, podpowiesz?

Dokładnie taki jak podałem ci do funkcji twi_stop(), czyli prosty licznik w dół jeśli się wyzeruje, to wyjdzie z funkcji i zwróci 0 czy jak ci tam wygodniej

Możesz tylko jeszcze pokazać kod z twi_read_buf() co tam dokładnie w niej robisz.

_________________
sig off ;(

Zrobiłem tak jak mówiłeś i dokładnie pokazało w którym momencie mikrokontroler się zawiesza. Do każdej funkcji, z której korzystam z biblioteki i2c_twi dodałem ten mechanizm sprawdzający, jeżeli wyświetliło 1 to znaczy że funkcja się wykonała oraz poprawnie odliczyło 250 w pętli. Uruchomiłem program i okazało się, że zawiesza się w funkcji TWI_read_buf().

Poniżej wklejam kod tej funkcji oraz podfunkcji TWI_read, z której korzystam (mam nadziej, że Mirek nie będzie miał nic przeciwko)

Aaaa coś czuję, że znalazłem winowajcę



Ta pętla w funkcji read_buf nic nie da musi być w podstawowych funkcjach (tj. twi_read(), twi_write() itp.) razem z pętla while w nich.
W kodzie brakowało twi_stop(), oraz nie byłem pewien co do wskaźnika buf, dlatego zmieniłem trochę.

_________________
sig off ;(

Niestety z wielkim żalem stwierdzam, że nadal się zawiesza już mam powoli tego dość... coś wyjątkowo brudzi w tej funkcji TWI_read_buf()

Kurcze już nie mam pomysłu wygląda, że wszystko powinno być ok.

Możesz jeszcze obniżyć częstotliwość, oraz zobaczyć na jakimś innym układzie np. rtc czy transmisja dobrze działa.
Jeśli będzie ok. (z rtc) to znaczy coś z termometrem nie tak

_________________
sig off ;(

krafin testowałem układ jeszcze w róźnych kombinacjach, dodawałem te liczniki do funkcji, zmieniałem taktowanie procka oraz taktowanie magistrali I2C i nic, zrobiłem jednak pewną małą rzecz i PROSZĘ układ już działa ponad 2,5 h ...
Śmiać mi się chce bo to w sumie głupota, mianowicie co zrobiłem:
-> pousuwałem wszystkie liczniki z funkcji o których mowa wyżej
-> zrezygnowałem z funkcji TWI_read_buf() i wpisałem ją krok po kroku w while()
-> pododawałem za każdą funkcją w pętli głównej while() wypisywanie przez USART komunikatu, że dana funkcja została wykonana, w ten sposób chciałem sprawdzić, w którą w ogóle nie chce wejść....I TO WSZYSTKO układ działa...czyli tak jakby potrzebował opóźnienia ? Kombinowałem później z tymi wypisywaniami, żeby trafić może w jakieś konkretne miejsce aby tylko tam dać jakiegoś "deley'a" ale układ działa tylko jak dam wszystkie wypisywania.... Dziwne, może sumarycznie pętla while() potrzebuje jakiegoś czasu aby podjąć kolejną konwersję?
Czytałem notę katalogową i nie ma żadnej wzmianki o innym opóźnieniu niż 1s po "START_CONVERT". Co ty na to ?

Poniżej kod mojej obecnej funkcji main():

Czyli co jeśli pousuwasz te uart_puts() to układ przestaje działać

Dziwne, bardzo dziwne Dobrze, że działa ale bardzo mnie to dziwi, tym bardziej, że te wysyłanie na uart wykonuje się bardzo szybko, tylko wpisanie do bufora cyklicznego, i reszta sama na przerwaniach już leci w tle.

_________________
sig off ;(

Testuje dalej ten układ bo wierzyć mi się nie chce, i co się okazało jeśli nie wpiszę nic w funkcję uart_puts() to program się zawiesza, musi być "coś" wpisane oraz bezpośrednio po tej funkcji muszę wpisać uart_puts("\r\n"), bo bez tego TEŻ SIĘ ZAWIESZA ?!
O co tu chodzi?, może faktycznie to jest jakaś podpowiedź, ale tak jak wspomniałeś ta funkcje wykonuje się bardzo szybko i poza tym cała reszta wykonuje się na przerwaniach....

Próbowałem zamiast tej funkcji dać np. deley'a 500ms i to samo, BŁĄD, więc chyba nie chodzi o opóźnienie...ewidentnie program działa łącznie z funkcją uart_puts("cos") i uart_puts("\r\n"). Może faktycznie potrzeba tutaj jakiś przerwań?!.....

No nie to coś baaardzo dziwnego się tam dzieje, może spróbuj jeszcze, zakomentować includ uarta, oraz nie włączać przerwań, tylko mignięcie diody co 1 obieg pętli.
Kurcze to musi być coś nie tak, w tych funkcjach twi nie ma żadnej magii, to powinno działać.

_________________
sig off ;(

krafin wyłączyłem całego uarta, przerwania i działa poprawnie Czyli wniosek z tego taki, że układ już pracował pewnie normalnie odkąd dopisałem twi_stop() tak jak mi podpowiadałeś. Czyli z Twi i DS1621 wszystko OK Coś się dzieje jak do programu wchodzi usart ?!

Więc to przerwania w czymś przeszkadzają, odpal jakiś timer (ale tak aby dość szybko się wywoływało przerwanie) i w jego przerwaniu zrób jakieś tam dzielenie jednej zmiennej przez drugą - jeśli twi będzie działało poprawnie to nie wina przerwań tylko uartu, inaczej przerwań choć nie mam pojęcia czemu, w końcu twi to osobne peryferie działające niezależnie od reszty programu.

_________________
sig off ;(

podłączę się pod temat, wyskrobałem taki kod do odczytu temperatury z tego czujnika


odczytuję teraz co sekundę temperaturę z dokładnością do 0,5 stopnia (jeszcze nie sformatowałem wyświetlania tej części ułamkowej, muszę najstarszy bit przesunąć w miejsce najmłodszego, ale nie o to teraz chodzi). Mianowicie odczytuję te dwa rejestry pozwalające wg wzoru obliczać temperaturę z większą dokładnością. Prosiłbym autora o podzielenie się metodą obliczania tego wzoru bo jak na razie oprócz niechcianych floatów nic mi nie przychodzi do głowy:)

krafin podasz mi przykładową funkcję z tym timerem(przerwanie z dzieleniem), którą mam wpisać?, bo jak sam napiszę to nie będę miał pewności czy jest dobrze... nie jestem aż tak dobry jeszcze z timerów/liczników. Z góry dzięki.

Na początek inicjalizacja (gdzieś w mainie, dla 16MHz, jeśli masz inny to napisz):


do tego deklaracja zmiennej globalnej volatile uint8_t zm_div;

Potem procedura obsługi przerwania:


Jeśli po tym twi będzie działać zmniejsz OCR0 w inicjalizacji o połowę i jeśli nadal będzie działać to znaczy, że uart sam w sobie przeszkadza ale nie mieć pojęcia czemu

_________________
sig off ;(

krafin zrobiłem tak jak mówiłeś i faktycznie przerwania wykonują się poprawnie, nie ma żadnej zawiechy, mało tego przeniosłem czujnik do małego ATtiny2313 gdzie miałem wyświetlacz 7-segmentowy i pięknie pokazuje temperaturę co 1sek a wiadomo, że w tle także działa przerwanie dla wyświetlaczy 7-segmenetowych. Tak więc układ działa poprawnie na sprzętowej jak i programowej szynie I2C. Wstępnie dziękuję za pomoc i zainteresowanie się tym tematem. Pozostał fakt, jeżeli będę chciał w przyszłości przesłać temperaturę RS'em do komputera to przeanalizować dokładnie biblioteki dla USARTU i znaleźć przyczynę. Ewentualne pomysły i propozycje mile widziane.

Kolego "swierku" kończe własnie pisać fragment kodu dla pełnej rozdzielczości 0,1 C oczywiście bez floatów. Wszystko niedługo wrzucę wytłumaczone oraz wkleję kod.
Pozdrawiam

Gdybym nie widział kodu to bym powiedział STOS!, ale w tym kodzie nie ma żadnych wielkich tablic, struktur więc to nie może być to

Zaraz odpalę zegarek pcf, i wysyłanie do pc godziny, co prawda, na bibliotekach z bluebook ale wydaje mi się po ich nazwach, że to jedno i to samo (aczkolwiek jeśli się mylę to mnie popraw)

_________________
sig off ;(

Spoko, będę bardzo wdzięczny jak sprawdzisz, ja także korzystam z bibliotek Mirka z bluebook'a