NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Cyfrowe czujniki temperatury z jednoprzewodowym interfejsem jako alternatywa dla DS18B20
Marek
Guest
Guest
Tue Dec 09, 2014 12:12 am
Obok jest wątek o problemach z tymi układami. Czy jest jakaś cyfrowa
alternatywa dla nivh, co miałaby prosty interfejs, najlepiej
jednoprzewodowy? Używając 1wire na słabych mcu, jest problem w
zmieszczeniem się w slotach czasowych gdy akurat w trakcie
komunikacji 1wire przychodzi przerwanie z innego peryferium...
--
Marek
AlexY
Guest
Guest
Tue Dec 09, 2014 1:13 am
Marek pisze:
Quote:
Obok jest wątek o problemach z tymi układami. Czy jest jakaś cyfrowa
alternatywa dla nivh, co miałaby prosty interfejs, najlepiej
jednoprzewodowy? Używając 1wire na słabych mcu, jest problem w
zmieszczeniem się w slotach czasowych gdy akurat w trakcie komunikacji
1wire przychodzi przerwanie z innego peryferium...
alternatywa dla nivh, co miałaby prosty interfejs, najlepiej
jednoprzewodowy? Używając 1wire na słabych mcu, jest problem w
zmieszczeniem się w slotach czasowych gdy akurat w trakcie komunikacji
1wire przychodzi przerwanie z innego peryferium...
Przerwanie można zablokować, rozwiązaniem byłby interfejs sprzętowy, a
te już raczej wielożyłowe.
A problemem z czujnikami temperatury 1-wire jest niedostateczne ich
zabezpieczenie przed wpływem warunków pogodowych.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Pszemol
Guest
Guest
Tue Dec 09, 2014 7:00 am
"AlexY" <alexy@irc.pl> wrote in message news:m65eq1$nav$1@dont-email.me...
Quote:
A problemem z czujnikami temperatury 1-wire jest niedostateczne ich
zabezpieczenie przed wpływem warunków pogodowych.
zabezpieczenie przed wpływem warunków pogodowych.
Co masz na myśli, konkretnie?
I dlaczego czujniki z innym interface miałyby być łatwiejsze do
zabezpieczenia?
Marek
Guest
Guest
Tue Dec 09, 2014 8:57 am
On Tue, 09 Dec 2014 00:13:04 +0000, AlexY <alexy@irc.pl> wrote:
Quote:
Przerwanie można zablokować,
Wiedziałem, że ktoś zaraz coś takiego napisze. Nie po to są
przerwania, żeby je blokować, dla mnie jest to niedopuszczalne
pójście na łatwiznę, świadczące o bezradności programisty albo
sprzętu.
Quote:
rozwiązaniem byłby interfejs sprzętowy, a
te już raczej wielożyłowe.
te już raczej wielożyłowe.
Jedno nie detrminuje drugiego. Zdaje się, są jakieś egzotyczne mcu ze
sprzętowym 1wire.
A wystarczyłoby aby okna transmisyjne w 1wire były w ms a nie us. O
ile w trybie pasożytniczym jest zrozumiałe użycie us, to w trybie z
normalnym zasilaniem okna mogłyby być dłuższe. Czy naprawdę wszyscy
muszą mieć odczytaną temp. poniżej 1ms? Szczególnie to jest nonsens,
gdy i tak trzeba czekać na konwersję w liczoną w ms (tak wiem, 1wire
to nie tylko termometry).
--
Marek
Zbych
Guest
Guest
Tue Dec 09, 2014 9:07 am
W dniu 09.12.2014 o 08:57, Marek pisze:
Quote:
On Tue, 09 Dec 2014 00:13:04 +0000, AlexY <alexy@irc.pl> wrote:
Przerwanie można zablokować,
Wiedziałem, że ktoś zaraz coś takiego napisze. Nie po to są przerwania,
żeby je blokować, dla mnie jest to niedopuszczalne pójście na łatwiznę,
świadczące o bezradności programisty albo sprzętu.
Przerwanie można zablokować,
Wiedziałem, że ktoś zaraz coś takiego napisze. Nie po to są przerwania,
żeby je blokować, dla mnie jest to niedopuszczalne pójście na łatwiznę,
świadczące o bezradności programisty albo sprzętu.
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów? Jak przerwań nie jest za dużo i są w miarę
przewidywalne (np. od timera) to możesz jeszcze próbować synchronizować
wysyłanie bitów z przerwaniem tak żeby mieć pewność, że przerwanie nie
wlezie w środek bitu.
Quote:
rozwiązaniem byłby interfejs sprzętowy, a te już raczej wielożyłowe.
Jedno nie detrminuje drugiego. Zdaje się, są jakieś egzotyczne mcu ze
sprzętowym 1wire.
Jedno nie detrminuje drugiego. Zdaje się, są jakieś egzotyczne mcu ze
sprzętowym 1wire.
Ten egzotyczny sprzęt nazywa się UART.
http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Marek
Guest
Guest
Tue Dec 09, 2014 10:32 am
On Tue, 09 Dec 2014 09:07:59 +0100, Zbych <abuse@onet.pl> wrote:
Quote:
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów?
generowania bitów?
Napisałem propozycję, dłuższe okno. Ale może niepotrzebnie upieram
się przy cyfrowym. Może są tanie i proste analogi V=f(T)?
Quote:
Wiedziałem, ze ktoś to zaproponuje
. Uart potrzebny mi jest do
czegoś innego. To ma być propozycja do małych mcu, gdzie z reguły
jest tylko jeden uart.
--
Marek
Jawi
Guest
Guest
Tue Dec 09, 2014 11:58 am
W dniu 2014-12-09 00:12, Marek pisze:
Quote:
Obok jest wątek o problemach z tymi układami. Czy jest jakaś cyfrowa
alternatywa dla nivh, co miałaby prosty interfejs, najlepiej
jednoprzewodowy? Używając 1wire na słabych mcu, jest problem w
zmieszczeniem się w slotach czasowych gdy akurat w trakcie komunikacji
1wire przychodzi przerwanie z innego peryferium...
no czy lepszym to nie wiem, ale alternatywą może być tmp102, też cyfrowy.
alternatywa dla nivh, co miałaby prosty interfejs, najlepiej
jednoprzewodowy? Używając 1wire na słabych mcu, jest problem w
zmieszczeniem się w slotach czasowych gdy akurat w trakcie komunikacji
1wire przychodzi przerwanie z innego peryferium...
no czy lepszym to nie wiem, ale alternatywą może być tmp102, też cyfrowy.
i całe mnóstwo analogów
Marek Wodzinski
Guest
Guest
Tue Dec 09, 2014 12:07 pm
On Tue, 9 Dec 2014, Marek wrote:
Quote:
Ale może niepotrzebnie upieram się przy
cyfrowym.
cyfrowym.
Mierzysz tylko temperaturę czy coś jeszcze? Bo obecnie z większości
cyfrowych barometrów, akceleratorów/gyro można też odczytywać temperaturę.
Quote:
Może są tanie i proste analogi V=f(T)?
LM35 i podobne.
Pozdrawiam
Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg
Zbych
Guest
Guest
Tue Dec 09, 2014 12:12 pm
W dniu 09.12.2014 o 10:32, Marek pisze:
Quote:
On Tue, 09 Dec 2014 09:07:59 +0100, Zbych <abuse@onet.pl> wrote:
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów?
Napisałem propozycję, dłuższe okno.
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów?
Napisałem propozycję, dłuższe okno.
Ale to do dallasa napisz, żeby ci zrobił krzem z wolniejszą transmisją.
Quote:
Napisałem propozycję, dłuższe okno. Ale może niepotrzebnie upieram się
przy cyfrowym. Może są tanie i proste analogi V=f(T)?
przy cyfrowym. Może są tanie i proste analogi V=f(T)?
Oczywiście że są, np. LM35 itp.
Quote:
Ten egzotyczny sprzęt nazywa się UART.
http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Wiedziałem, ze ktoś to zaproponuje. Uart potrzebny mi jest do czegoś
innego. To ma być propozycja do małych mcu, gdzie z reguły jest tylko
jeden uart.
http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Wiedziałem, ze ktoś to zaproponuje
. Uart potrzebny mi jest do czegoś
innego. To ma być propozycja do małych mcu, gdzie z reguły jest tylko
jeden uart.
Impuls możesz generować czymkolwiek np. timerem, spi itd.
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo odległość
między bitami nie jest krytyczna. Masz taką aplikację, że opóźnienie
przerwania o max. 60us zrobi ci różnicę?
Marek
Guest
Guest
Tue Dec 09, 2014 2:32 pm
On Tue, 09 Dec 2014 12:12:56 +0100, Zbych <abuse@onet.pl> wrote:
Quote:
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przy wysyłaniu owszem, ale przy odczycie nie wiem czy czujnik chce
nadać 0 czy 1, stąd przerwania musiałyby być blokowane też w czasie
odczytu.
Jeśli w trakcie komunikacji 1wire zdaży mi przerwanie mam bzdety na
1wire bo crc się nie zgadza. Na razie rozwiązałem to tak, że ignoruję
taką błędna transmisję i korzystam z prawidłowej wartości odczytanej
poprzednio. System kontroluje liczbę błędnych transmisji i jeśli
zdarzają się pod rząd zbyt dużą ilość razy to sygnalizowany jest
problem.
--
Marek
as
Guest
Guest
Tue Dec 09, 2014 2:37 pm
Quote:
Wiedziałem, ze ktoś to zaproponuje
. Uart potrzebny mi jest do
czegoś innego. To ma być propozycja do małych mcu, gdzie z reguły
jest tylko jeden uart.
Jeśli w systemie masz przerwanie zegarowe np. co 1ms, to możesz tam
obsługiwać 1-wire po jednym bicie na przerwanie. Impuls resetu też można
załączać na określoną ilość taktów. Warunkiem jest to aby to przerwanie
miało najwyższy priorytet. Metoda sprawdzona praktycznie.
Atlantis
Guest
Guest
Tue Dec 09, 2014 3:16 pm
W dniu 2014-12-09 01:13, AlexY pisze:
Quote:
Przerwanie można zablokować, rozwiązaniem byłby interfejs sprzętowy, a
te już raczej wielożyłowe.
te już raczej wielożyłowe.
Istnieją sprzętowe interfejsy 1-wire. Układy takie produkuje Dallas.
Podłączasz to z jednej strony do I2C, z drugiej masz 1wire.
Największą zaletą jest możliwość postawienia galwanicznej izolacji
pomiędzy takim układem a MCU.
Zbych
Guest
Guest
Tue Dec 09, 2014 3:55 pm
W dniu 09.12.2014 o 14:32, Marek pisze:
Quote:
On Tue, 09 Dec 2014 12:12:56 +0100, Zbych <abuse@onet.pl> wrote:
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przy wysyłaniu owszem, ale przy odczycie nie wiem czy czujnik chce
nadać 0 czy 1, stąd przerwania musiałyby być blokowane też w czasie
odczytu.
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przy wysyłaniu owszem, ale przy odczycie nie wiem czy czujnik chce
nadać 0 czy 1, stąd przerwania musiałyby być blokowane też w czasie
odczytu.
Odczyt bitu możesz zrobić w połowie maksymalnej długości, czyli po 30us
i tylko na tyle zablokować przerwania. Kolejne 30us do końca bitu możesz
czekać już przy włączonych przerwaniach.
AlexY
Guest
Guest
Tue Dec 09, 2014 6:12 pm
Marek pisze:
Quote:
On Tue, 09 Dec 2014 12:12:56 +0100, Zbych <abuse@onet.pl> wrote:
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przy wysyłaniu owszem, ale przy odczycie nie wiem czy czujnik chce
nadać 0 czy 1, stąd przerwania musiałyby być blokowane też w czasie
odczytu.
Jeśli w trakcie komunikacji 1wire zdaży mi przerwanie mam bzdety na
1wire bo crc się nie zgadza. Na razie rozwiązałem to tak, że ignoruję
taką błędna transmisję i korzystam z prawidłowej wartości odczytanej
poprzednio. System kontroluje liczbę błędnych transmisji i jeśli
zdarzają się pod rząd zbyt dużą ilość razy to sygnalizowany jest problem.
Spojrzałem jeszcze na czasy w 1wire. Impulsy są od 1us do max 60us.
Przerwania blokujesz tylko na czas trwania stanu niskiego, bo
odległość
między bitami nie jest krytyczna.
Przy wysyłaniu owszem, ale przy odczycie nie wiem czy czujnik chce
nadać 0 czy 1, stąd przerwania musiałyby być blokowane też w czasie
odczytu.
Jeśli w trakcie komunikacji 1wire zdaży mi przerwanie mam bzdety na
1wire bo crc się nie zgadza. Na razie rozwiązałem to tak, że ignoruję
taką błędna transmisję i korzystam z prawidłowej wartości odczytanej
poprzednio. System kontroluje liczbę błędnych transmisji i jeśli
zdarzają się pod rząd zbyt dużą ilość razy to sygnalizowany jest problem.
A co się stanie jeśli przerwanie zostanie odebrane te 60us później?
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
AlexY
Guest
Guest
Tue Dec 09, 2014 6:13 pm
Marek pisze:
Quote:
On Tue, 09 Dec 2014 09:07:59 +0100, Zbych <abuse@onet.pl> wrote:
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów?
Napisałem propozycję, dłuższe okno. Ale może niepotrzebnie upieram się
przy cyfrowym. Może są tanie i proste analogi V=f(T)?
A jakiej rady się spodziewałeś skoro nie przewidziałeś sprzętowego
generowania bitów?
Napisałem propozycję, dłuższe okno. Ale może niepotrzebnie upieram się
przy cyfrowym. Może są tanie i proste analogi V=f(T)?
Masz dostępny konkretny standard którego nie zmienisz, nie walcz z tym,
dostosuj się/swój projekt, albo zmień magistralę.
Quote:
Ten egzotyczny sprzęt nazywa się UART.
http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Wiedziałem, ze ktoś to zaproponuje. Uart potrzebny mi jest do czegoś
innego. To ma być propozycja do małych mcu, gdzie z reguły jest tylko
jeden uart.
http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Wiedziałem, ze ktoś to zaproponuje
. Uart potrzebny mi jest do czegoś
innego. To ma być propozycja do małych mcu, gdzie z reguły jest tylko
jeden uart.
Po kawałku i za kilka dni będziemy wiedzieć wszystko co powinno znaleźć
się w pierwszym poście.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
elektroda NewsGroups Forum Index - Elektronika Polska - Cyfrowe czujniki temperatury z jednoprzewodowym interfejsem jako alternatywa dla DS18B20