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

do góry

Marek pisze:
> 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...

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

do góry

"AlexY" <a...@i...pl> wrote in message news:m65eq1$nav$1@dont-email.me...
> A problemem z czujnikami temperatury 1-wire jest niedostateczne ich
> 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?

do góry

On Tue, 09 Dec 2014 00:13:04 +0000, AlexY <a...@i...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.

>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.

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

do góry

W dniu 09.12.2014 o 08:57, Marek pisze:
> On Tue, 09 Dec 2014 00:13:04 +0000, AlexY <a...@i...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.

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.

>> 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.

Ten egzotyczny sprzęt nazywa się UART.
http://www.maximintegrated.com/en/app-notes/index.mv
p/id/214

do góry

On Tue, 09 Dec 2014 09:07:59 +0100, Zbych <a...@o...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)?


> Ten egzotyczny sprzęt nazywa się UART.
> http://www.maximintegrated.com/en/app-notes/index.mv
p/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.

--
Marek

do góry

W dniu 2014-12-09 00:12, Marek pisze:
> 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.
i całe mnóstwo analogów

do góry

On Tue, 9 Dec 2014, Marek wrote:

> Ale może niepotrzebnie upieram się przy
> cyfrowym.

Mierzysz tylko temperaturę czy coś jeszcze? Bo obecnie z większości
cyfrowych barometrów, akceleratorów/gyro można też odczytywać temperaturę.


> 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

do góry

W dniu 09.12.2014 o 10:32, Marek pisze:
> On Tue, 09 Dec 2014 09:07:59 +0100, Zbych <a...@o...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 to do dallasa napisz, żeby ci zrobił krzem z wolniejszą transmisją.

> 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)?

Oczywiście że są, np. LM35 itp.

>> Ten egzotyczny sprzęt nazywa się UART.
>> http://www.maximintegrated.com/en/app-notes/index.mv
p/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ę?

do góry

On Tue, 09 Dec 2014 12:12:56 +0100, Zbych <a...@o...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.

--
Marek

do góry