1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF_?=



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF_?=
Date: Mon, 10 Oct 2005 16:53:50 +0200


Witam!

Musze używać magistrali 1-Wire na AVR. Mam jednak następujące założenia:

1) Procedury 1-Wire nie mogą być aktywnie czekające w głównej pętli, bo
ta pętla ma co robić i robi to w dodatku niestabilnie czasowo.
2) W systemie jest już sporo przerwań (UART,Timer,Ext) które są
ważniejsze od 1-Wire (na którym jest mało ważny miernik temperatury, ale
być musi).
3) 1-Wire jest nie dość, że strasznie czuły na czasy to w dodatku sa to
czasy krótkie (15us to krócej niż 256 cykli zegara 14MHz - konkretnie
17us - więc timery się komplikują).
4) Wszystkie biblioteki jake znalazłem w necie sa aktywnie czekające w
głównej pętli.
5) Stosowanie dodatkowych scalaków jest chwilowo bez sensu, nawet jeśli
będa kosztowac 3zł/sztuka (ATTiny/etc).

No i co teraz ;) ?

Wykoncypowałem tak:

Wykorzystam jakiś timer, który jest skrócony (np. pi razy oko 5us) -
TIMER2 ma taką funkcję w ATMega8.
W przerwaniu zaimplementuje cały proces slotów Wite1/Read1 albo
Write0/Read0 czy Reset. Główny program bedzie zlecał przerwaniom
wykonanie tego pojedynczego elementu. Reszta algorytmu (wybieranie
poszczególnych bitów) zrealizuje już z głownej pętli.

Najwazniejsze elementy do przeskoczenia to chyba stałośc czasów dla
1-Wire jednocześnie bez mocnego blokowania pozostałych przerwań.
(przerwanie 1-Wire było by jedynym nieprzerywalnym, reszta może byc
przerwana).

No i teraz pytanie:

a) Czy istnieje taka biblioteka już napisana - nie mam po co robić,
jesli jest gotowe.
b) Czy mogę pomiędzy poszczególnymi slotami dawać dowolnie długie
przerwy (nie mam zasilania z lini danych dla miernika temp, normalnie
przez Vcc) ?
c) Czy mam słuszną koncepcję ;) ?

Poprzedni Następny
Wiadomość
Spis treści
From: Grzegorz Kurczyk <grzegorz.usun.to_at_nospam_control.slupsk.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 17:52:18 +0200


Użytkownik Sebastian Bialy napisał:
Najwazniejsze elementy do przeskoczenia to chyba stałośc czasów dla
1-Wire jednocześnie bez mocnego blokowania pozostałych przerwań.
(przerwanie 1-Wire było by jedynym nieprzerywalnym, reszta może byc
przerwana).

No i teraz pytanie:

a) Czy istnieje taka biblioteka już napisana - nie mam po co robić,
jesli jest gotowe.
b) Czy mogę pomiędzy poszczególnymi slotami dawać dowolnie długie
przerwy (nie mam zasilania z lini danych dla miernika temp, normalnie
przez Vcc) ?
c) Czy mam słuszną koncepcję ;) ?

Witam
Istotny jest tylko czas trwania stanu niskiego na magistrali 1-Wire.
Stan wysoki w przerwie miedzy slotami nie jest krytyczny (a z
doświadczenia - może trwac dowolnie długo). Robię to w ten sposób, że
mam procedury wysyłające bity 0, 1, reset i one blokują przerwania.
Pętla wysyłająca poszczególne bity w bajcie może juz być spokojnie
przerywana (zwiększy się tylko całkowity czas przesłania bajtu).
Zabawa z timerami nie przyniosła mi spodziewanego rezultatu ze względu
na brak wielopoziomowych przerwań w AVR-ach. Jeśli zaraz przed sygnałem
przerwania z timera dostaniesz inne przerwanie, którego obsługa będzie
dość długa to i tak procek nie obsłuży przerwania timera dopóki nie
zakończy bieżącej obsługi co zaowocuje "odmierzeniem" znacznie dłuższego
czasu niż wynikałoby to z ustawień timera.

Pozdrawiam
Grzegorz

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 17:58:51 +0200


Grzegorz Kurczyk wrote:
Zabawa z timerami nie przyniosła mi spodziewanego rezultatu ze względu
na brak wielopoziomowych przerwań w AVR-ach.

Owszem, ale w AVR (chyba ;) można mieć przerwanie przerywalne i nie
przerywalne (SIGNAL albo INTERRUPT w gcc).

Konkretnie: Jesli przerwanie zrobi CLI na początku, to nikt go nie
przerwie. Jeśli nie zrobi - to może być przerwane przez inne.

Mozna by wszystkie przerwania mieć bez CLI za wyjątkiem tego od timera
1-Wire. W ten sposób on bedzie zawsze obsłużony, ale jego już nikt nie
przerwie.

Poprzedni Następny
Wiadomość
Spis treści
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:20:53 +0200


Konkretnie: Jesli przerwanie zrobi CLI na początku, to nikt go nie
przerwie. Jeśli nie zrobi - to może być przerwane przez inne.


Odwrotnie, przerwanie blokuje inne przerwania, o ile procedura obslugi
jawnie ich nie odblokuje.

Mozna by wszystkie przerwania mieć bez CLI za wyjątkiem tego od timera
1-Wire. W ten sposób on bedzie zawsze obsłużony, ale jego już nikt nie
przerwie.

No to juz wiemy, ze odwrotnie:) Ale nie wazne - po pierwsze zdecyduj sie
co chcesz miec - mastera czy slave na AVR? Jesli mastera to sprawa nie
jest trudna, zasadnioczo nawet b. latwa, szczegolnie jesli masz do
dyspozycji jakis hardwarowy UART, lub chociazby timer (wyjscie timera
mozesz podpiac do pinu IO, a timer wykorzystywac do generacji impulsu
ujemnego o zaprogramowanym czasie trwania). Jesli chcesz oprogramowac
slave - to jest to nieco trudniejsze, ale mozliwe, tu moge sie z toba
podzielic kodem, ktory wlasnie skonczylem. Zla wiadomosc jest taka, ze w
przypadku slave masz max 15us na wystawienie odpowiedniego bitu, a w
praktyce mniej (pewne egzemplasze DS18B20 chcialy, zeby poprawny bit byl
max. po 8us i nie dalo im sie wytlumaczyc inaczej).
Jednakze w kazdym przypadku jesli inne procedury obslugi przerwan nie sa
krytyczne czasowo i moga byc przerywane to problem jest raczej prosty, w
przeciwnym wypadku jego rozwiazanie graniczy z niemoznoscia:)


--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:30:31 +0200


T.M.F. wrote:
Odwrotnie, przerwanie blokuje inne przerwania, o ile procedura obslugi
jawnie ich nie odblokuje.

Ok, pomyłka, ale idea taka sama.

No to juz wiemy, ze odwrotnie:) Ale nie wazne - po pierwsze zdecyduj sie
co chcesz miec - mastera czy slave na AVR? Jesli mastera to sprawa nie
jest trudna, zasadnioczo nawet b. latwa, szczegolnie jesli masz do
dyspozycji jakis hardwarowy UART, lub chociazby timer (wyjscie timera
mozesz podpiac do pinu IO, a timer wykorzystywac do generacji impulsu
ujemnego o zaprogramowanym czasie trwania).

Założenie jest takie, ze nie ma UART'a (walczy na RS485), mam timer, ale
wolałbym sterować tym pinem jednak programowo. I oczywiście mam mastera.

Nie twierdze, że to trudne, widze sam, że trywialne, jednak zastanawia
mnie sens pisania tego od zera, bo może jest akurat gotowiec na sieci.
jesli nie ma, to zabieram się za robotę.

Jesli chcesz oprogramowac
slave - to jest to nieco trudniejsze, ale mozliwe, tu moge sie z toba
podzielic kodem, ktory wlasnie skonczylem.

Dzięki, ale Slave nie jest mi potrzebny do czegokolwiek.

Jednakze w kazdym przypadku jesli inne procedury obslugi przerwan nie sa
krytyczne czasowo i moga byc przerywane to problem jest raczej prosty,

Nie są aż tak krytyczne, chodzi mi tylko o to, że wszystkie gotowce to
oczekiwanie w pustej pętli z wyłaczonymi przerwaniami co jest głupotą i
mi przeszkadza. Dlatego kombinuje inaczej.

Poprzedni Następny
Wiadomość
Spis treści
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:46:05 +0200


Założenie jest takie, ze nie ma UART'a (walczy na RS485), mam timer, ale
wolałbym sterować tym pinem jednak programowo. I oczywiście mam mastera.

To moze procek z 2 UARTami?

Jednakze w kazdym przypadku jesli inne procedury obslugi przerwan nie
sa krytyczne czasowo i moga byc przerywane to problem jest raczej prosty,

Nie są aż tak krytyczne, chodzi mi tylko o to, że wszystkie gotowce to
oczekiwanie w pustej pętli z wyłaczonymi przerwaniami co jest głupotą i
mi przeszkadza. Dlatego kombinuje inaczej.

No tak, ale zauwaz, ze jesli masz jakas krytyczna procedure, ktora
blokuje przerwania, i jesli dlugosc zablokowanej sekcji jest
porownywalna do owych 15us (lacznie z czasem wejscia do twojej procedury
obslugi 1-wire) to masz problem. W losowych momentach bedziesz gubil
bity, cholernie trudne do diagnostyki, kiedys cos zmienisz w programie i
nagle zacznie sie zachowywac magicznie.
Oczywiscie sam czas mozesz liczyc za pomoca timera, czyli wykonujesz
skok do procedury np. Read-1-Wire-Bit, ona odczytuje licznik timera,
odblokowywuje przerwania i czeka sobie az licznik przekroczy owe 15us,
nastepnie odczytuje stan lini IO i konczy dzialanie. Dzieki temu
procedura moze byc przerywana, ale przez procedury odslugi przerwan,
ktore szybko koncza swoja dzialalnosc. Inne podejscie - w procedurze
programujesz timer, tak, zeby po okreslonym czasie zglosil przerwanie, w
proc. obslugi przerwania zczytujesz stan pinu IO. Tylko tu znowu problem
sekcji krytycznych - jesli sa i do tego dluzsze niz pojedyncze
mikrosekundy to lezysz.
Jeszcze inne rozwiazanie, ale wrazliwe na zaklocenia - robisz timer
taktowany z pinu IO. Dajesz readslot, nastepnie czekasz dowolny czas i
kiedy ci wygodnie sprawdzasz stan timera. Jesli nic nie zliczyl to
znaczy, ze nie bylo zadnego impulsu ujemnego (urzadzenie wyslalo 1),
jesli zmienil stan to urzadzenie w miedzyczasie wyslalo 0. Ta koncepcja
mi sie najbardziej podoba:)


--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:56:00 +0200


T.M.F. wrote:
To moze procek z 2 UARTami?

Odpada, w prototypie będzie DIP a DIPy sa ogromne, jak mają 2xUART
(chyba ze jest coś w gabarytach ATMega8 DIP ?)

No tak, ale zauwaz, ze jesli masz jakas krytyczna procedure, ktora
blokuje przerwania, i jesli dlugosc zablokowanej sekcji jest
porownywalna do owych 15us (lacznie z czasem wejscia do twojej procedury
obslugi 1-wire) to masz problem. W losowych momentach bedziesz gubil
bity, cholernie trudne do diagnostyki, kiedys cos zmienisz w programie i
nagle zacznie sie zachowywac magicznie.

Pozostałe przerwania mogą być przerywalne i same nie są bardzo krytyczne
czasowo za wyjątkiem sytuacji wyłączenia przerwań na całą operację
odczytu rejestrów DS1820. To już by było przegięcie i zaczęły by się
problemy poważne.

Oczywiscie sam czas mozesz liczyc za pomoca timera, czyli wykonujesz
skok do procedury np. Read-1-Wire-Bit, ona odczytuje licznik timera,
odblokowywuje przerwania i czeka sobie az licznik przekroczy owe 15us,
nastepnie odczytuje stan lini IO i konczy dzialanie. Dzieki temu
procedura moze byc przerywana, ale przez procedury odslugi przerwan,
ktore szybko koncza swoja dzialalnosc. Inne podejscie - w procedurze
programujesz timer, tak, zeby po okreslonym czasie zglosil przerwanie, w
proc. obslugi przerwania zczytujesz stan pinu IO. Tylko tu znowu problem
sekcji krytycznych - jesli sa i do tego dluzsze niz pojedyncze
mikrosekundy to lezysz.

Nie ma sekcji krytycznych (prawie nie ma, mają po pare instrukcji,
konkretnie aktualizacja licznika 32 bit).

Jeszcze inne rozwiazanie, ale wrazliwe na zaklocenia - robisz timer
taktowany z pinu IO. Dajesz readslot, nastepnie czekasz dowolny czas i
kiedy ci wygodnie sprawdzasz stan timera. Jesli nic nie zliczyl to
znaczy, ze nie bylo zadnego impulsu ujemnego (urzadzenie wyslalo 1),
jesli zmienil stan to urzadzenie w miedzyczasie wyslalo 0. Ta koncepcja
mi sie najbardziej podoba:)

Nie jest to zła orange, tfu, idea i zastanowie się nad tym jeszcze, choć
dalej pozostaje problem zrobienia odpowieniej długości bitu '0' przez
mastera. Ale zastanwie się i dziękuje za pomysł.

Poprzedni Następny
Wiadomość
Spis treści
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 19:46:51 +0200



Odpada, w prototypie będzie DIP a DIPy sa ogromne, jak mają 2xUART
(chyba ze jest coś w gabarytach ATMega8 DIP ?)

Nie znam, ale dlaczego uparles sie na DILe?

Pozostałe przerwania mogą być przerywalne i same nie są bardzo krytyczne
czasowo za wyjątkiem sytuacji wyłączenia przerwań na całą operację
odczytu rejestrów DS1820. To już by było przegięcie i zaczęły by się
problemy poważne.

No to nie ma problemu. Pomysl z programowym generowaniem impulsu
niskiego przez timer wydaje sie byc najlepszy.

Jeszcze inne rozwiazanie, ale wrazliwe na zaklocenia - robisz timer
taktowany z pinu IO. Dajesz readslot, nastepnie czekasz dowolny czas i
kiedy ci wygodnie sprawdzasz stan timera. Jesli nic nie zliczyl to
znaczy, ze nie bylo zadnego impulsu ujemnego (urzadzenie wyslalo 1),
jesli zmienil stan to urzadzenie w miedzyczasie wyslalo 0. Ta
koncepcja mi sie najbardziej podoba:)

Nie jest to zła orange, tfu, idea i zastanowie się nad tym jeszcze, choć
dalej pozostaje problem zrobienia odpowieniej długości bitu '0' przez
mastera. Ale zastanwie się i dziękuje za pomysł.

To co napisalem dobre jest przy odczycie, do zapisu z kolei wykorzystaj
mozliwosc generacji impulsu o zadanym czasie trwania przez timer. Dzieki
temu programujesz timer i na tym rola procedury sie konczy. W obsludze
przerwania timera zmienias zpoziom ponownie na wysoki i juz.
Zeby calosc zrobic juz w ogole bajerancko to moze jakis maly bufor FIFO
i w procedurze obslugi przerwania sprawdzac czy jest cos do wyslania i
ew. wyslac.


--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:11:59 +0200


T.M.F. wrote:
Nie znam, ale dlaczego uparles sie na DILe?

Prototyp przechodzi ciągłą ewolucję i stąd montaż przewlekany jest
zbawienny.

To co napisalem dobre jest przy odczycie, do zapisu z kolei wykorzystaj
mozliwosc generacji impulsu o zadanym czasie trwania przez timer. Dzieki
temu programujesz timer i na tym rola procedury sie konczy. W obsludze
przerwania timera zmienias zpoziom ponownie na wysoki i juz.

Dokładnie tak zamierzam, choć do tej pory kombinowałem nico głebiej: w
procedurze timera zaimplementować prostą maszynkę stanów, która krok po
kroku wykona wszystkie czynności związane ze slotem i odczyta bit.

Zeby calosc zrobic juz w ogole bajerancko to moze jakis maly bufor FIFO
i w procedurze obslugi przerwania sprawdzac czy jest cos do wyslania i
ew. wyslac.

Fifo zbedne, jak powiedziałem procedura w głównym programie może być
wywoływana ręcznie, taki sposób programowania jest "w moim stylu" i
raczej zrobie to tak właśnie.

Poprzedni Następny
Wiadomość
Spis treści
From: Grzegorz Kurczyk <grzegorz.usun.to_at_nospam_control.slupsk.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:16:25 +0200


Użytkownik Sebastian Bialy napisał:


Pozostałe przerwania mogą być przerywalne i same nie są bardzo krytyczne
czasowo za wyjątkiem sytuacji wyłączenia przerwań na całą operację
odczytu rejestrów DS1820. To już by było przegięcie i zaczęły by się
problemy poważne.

Ale dlaczego chcesz blokowac przerwania na czas przesyłania/odczytu
całych bajtów z DS-a ? Jak wspominałem wystarczy zablokować przerwania
na czas "odmierzania" jednego bitu. W momencie gdy na magistrali wraca
stan wysoki możesz już obsłużyć co innego.

Pozdrawiam
Grzegorz


Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:15:56 +0200


Grzegorz Kurczyk wrote:
Ale dlaczego chcesz blokowac przerwania na czas przesyłania/odczytu
całych bajtów z DS-a ? Jak wspominałem wystarczy zablokować przerwania
na czas "odmierzania" jednego bitu. W momencie gdy na magistrali wraca
stan wysoki możesz już obsłużyć co innego.

Owszem, ale wszystkie gotowce używają aktywnego czekania w przypadku
sygnału RESET który sam z siebie trwa już dość długo. Stąd napisanie
własnego zestawu procedur mnie nie minie, a skoro tak, to może lepiej
nie czekać aktywnie nawet na pojedyncze bity. W końcu narzut
programistyczny duży nie bedzie.

Poprzedni Następny
Wiadomość
Spis treści
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:24:00 +0200


Sebastian Bialy napisał(a):
Owszem, ale wszystkie gotowce używają aktywnego czekania w przypadku
sygnału RESET który sam z siebie trwa już dość długo. (...)

po co w ogóle czekać na odpowiedź resetu? jeśli układ nie odpowie i tak
nic nie poradzisz, a równie dobrze możesz polegać na sumie CRC
odczytanych danych.

w.

Poprzedni Następny
Wiadomość
Spis treści
From: Grzegorz Kurczyk <grzegorz.usun.to_at_nospam_control.slupsk.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:38:26 +0200


Użytkownik Sebastian Bialy napisał:

Grzegorz Kurczyk wrote:

Ale dlaczego chcesz blokowac przerwania na czas przesyłania/odczytu
całych bajtów z DS-a ? Jak wspominałem wystarczy zablokować przerwania
na czas "odmierzania" jednego bitu. W momencie gdy na magistrali wraca
stan wysoki możesz już obsłużyć co innego.


Owszem, ale wszystkie gotowce używają aktywnego czekania w przypadku
sygnału RESET który sam z siebie trwa już dość długo. Stąd napisanie
własnego zestawu procedur mnie nie minie, a skoro tak, to może lepiej
nie czekać aktywnie nawet na pojedyncze bity. W końcu narzut
programistyczny duży nie bedzie.

Możnaby zrobić drobną hybrydę :) Czas impulsu RESET nie jest krytyczny
byleby więcej niż 480us. Możnaby tylko jego generować timerem. Jeśli w
międzyczasie wlezie jakieś inne przerwanie, to impuls się conajwyżej
przedłuży.

Wysyłanie bajtu zrobiłem w taki sposób (gotowce też mi się nie podobały
i naskrobałem to po swojemu)

#define tREC 1
#define tLOW0 70
#define tLOW1 10

// generowanie impulsu tREC
void onewire_trec(int us) {
// ustaw magistralę na wyjście i ustaw stan wysoki
sbi(onewire_port, onewire_bit);
sbi(onewire_ddr, onewire_bit);
// tREC;
udelay(tREC);
// stan aktywny master
cbi(onewire_port, onewire_bit);
// odczekaj zadany czas
udelay(us);
}

// wysłanie bitu
void onewire_write_bit(char bit) {
push_sfr(SREG);
cli();
if (bit)
onewire_trec(tLOW1); // generuj impuls "1"
else
onewire_trec(tLOW0); // generuj impuls "0"
// ustaw magistralę na STRONG PULLUP
sbi(onewire_port, onewire_bit);
// wyrównaj czas szczeliny dla impulsu "1"
if (bit)
udelay(tLOW0 - tLOW1);
pop_sfr(SREG);
}

// wysłanie bajtu
void onewire_write(char bajt) {
char i;
for (i = 1; i; i <<= 1)
onewire_write_bit(bajt & i);
}


Pozdrawiam
Grzegorz


Poprzedni Następny
Wiadomość
Spis treści
From: Grzegorz Kurczyk <grzegorz.usun.to_at_nospam_control.slupsk.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:27:27 +0200


Użytkownik Sebastian Bialy napisał:

Grzegorz Kurczyk wrote:

Zabawa z timerami nie przyniosła mi spodziewanego rezultatu ze względu
na brak wielopoziomowych przerwań w AVR-ach.


Owszem, ale w AVR (chyba ;) można mieć przerwanie przerywalne i nie
przerywalne (SIGNAL albo INTERRUPT w gcc).

Konkretnie: Jesli przerwanie zrobi CLI na początku, to nikt go nie
przerwie. Jeśli nie zrobi - to może być przerwane przez inne.

Mozna by wszystkie przerwania mieć bez CLI za wyjątkiem tego od timera
1-Wire. W ten sposób on bedzie zawsze obsłużony, ale jego już nikt nie
przerwie.

Tzn. chyba odwrotnie, aby przerwanie mogło zostać przerwane to trzeba na
początku dać sei(). Bo AVR standardowo po przyjeciu przerwania zeruje
flagę przerwań i odtwarza ją po rozkazie reti.

Pozdrawiam
Grzegorz


Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 18:31:10 +0200


Grzegorz Kurczyk wrote:
Tzn. chyba odwrotnie, aby przerwanie mogło zostać przerwane to trzeba na
początku dać sei(). Bo AVR standardowo po przyjeciu przerwania zeruje
flagę przerwań i odtwarza ją po rozkazie reti.

Ok, moja pomyłka, racja oczywiście.

Poprzedni Następny
Wiadomość
Spis treści
From: =?ISO-8859-2?Q?Krzysztof_Szmur=B3o?= <ks123_at_nospam_tlen.do.wyciecia.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 20:37:01 +0200


Sebastian Bialy napisał(a):
Witam!

Musze używać magistrali 1-Wire na AVR. Mam jednak następujące założenia:

1) Procedury 1-Wire nie mogą być aktywnie czekające w głównej pętli, bo
ta pętla ma co robić i robi to w dodatku niestabilnie czasowo.
2) W systemie jest już sporo przerwań (UART,Timer,Ext) które są
ważniejsze od 1-Wire (na którym jest mało ważny miernik temperatury, ale
być musi).
3) 1-Wire jest nie dość, że strasznie czuły na czasy to w dodatku sa to
czasy krótkie (15us to krócej niż 256 cykli zegara 14MHz - konkretnie
17us - więc timery się komplikują).
4) Wszystkie biblioteki jake znalazłem w necie sa aktywnie czekające w
głównej pętli.
5) Stosowanie dodatkowych scalaków jest chwilowo bez sensu, nawet jeśli
będa kosztowac 3zł/sztuka (ATTiny/etc).

No i co teraz ;) ?

Wykoncypowałem tak:

Wykorzystam jakiś timer, który jest skrócony (np. pi razy oko 5us) -
TIMER2 ma taką funkcję w ATMega8.
W przerwaniu zaimplementuje cały proces slotów Wite1/Read1 albo
Write0/Read0 czy Reset. Główny program bedzie zlecał przerwaniom
wykonanie tego pojedynczego elementu. Reszta algorytmu (wybieranie
poszczególnych bitów) zrealizuje już z głownej pętli.

Ja to kiedyś na picu zrobiłem swego rodzaju interpreter. Chodziło toto w
przerwaniu od timera, odczytywało rozkaz ze stosu, daną i wykonywaną.
Zresztą sam zerknij. Proszę nie krytykować... to stare jest już :) i
powycinane są rzeczy zbędne.
Aha można korzystać do woli, jak się komuś przyda.

Pozdrawiam
Krzysztof Szmurło

#define TRUE 1
#define FALSE 0
#define W1_RESET 1
#define W1_READ 2
#define W1_WRITE 3
#define W1_DELAY 4
#define W1_END 5
#define W1_DONE 6

bank1 unsigned char W1_Buffer[4];
const unsigned char stosProgram[20] =
{W1_RESET, // wysyła sygnał resetu
W1_WRITE,0xCC, // rozkaz SkipRom
W1_WRITE,0x44,
W1_DELAY,75,
W1_RESET,
W1_WRITE,0xCC,
W1_WRITE,0xBE,
W1_READ,0,
W1_READ,1,
W1_DONE,
W1_DELAY,25,
W1_END};
const unsigned char * ptrProgram = stosProgram;
bank1 unsigned char DeviceConfigured = 0;
bank1 bit jesttemp = FALSE;
bank1 bit zezwolenie = FALSE;
bank1 bit suspended = FALSE;

void main (void)
{
while(1);
}

/********************************************************************************
void interrupt isr(void)
{
static bank1 unsigned char T1Counter;
static bit DelayProgress = FALSE;

// obsluga przerwania od T1
if (TMR1IF) {

// obsluga urzadzen 1-wire - procedura interpretera
switch (*ptrProgram++) { // odczytywany jest
rozkaz i zwiększany licznik programu
case W1_RESET: // około 1ms
D_Reset();
break;
case W1_READ: // około 0,6ms
W1_Buffer[*ptrProgram]= D_Read();
ptrProgram++;
break;
case W1_WRITE: // około 0,6ms
D_Write(*ptrProgram);
ptrProgram++;
break;
case W1_DELAY: // pare us
// ustawiany jest znacznik DelayProgress
// licznik programu ptrProgram nie zostaje zwiększony
// do momentu kiedy licznik opóźnienia T1Counter się nie wyzeruje
// da to w przybliżeniu opóźnienie równe 10ms*T1Counter
if (!DelayProgress) {
T1Counter = *ptrProgram;
DelayProgress = TRUE; }
if (!T1Counter--) {
ptrProgram++;
DelayProgress = FALSE; }
else ptrProgram--;
break;
case W1_END:
ptrProgram = stosProgram;
break;
case W1_DONE:
jesttemp = TRUE;
default:
break;
}
// koniec obslugi 1-wire
TMR1H = 231; // przerwanie co 10ms
TMR1L = 15; //
freqcnt3 = 0; // zerujemy do następnego pomiaru
TRISA5 = 1; // odblokowujemy tmr0
TMR1IE = 1;
TMR1IF = 0; // odblokowanie przerwan
}
}

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 21:04:40 +0200


Krzysztof Szmurło wrote:
Ja to kiedyś na picu zrobiłem swego rodzaju interpreter. Chodziło toto w
przerwaniu od timera, odczytywało rozkaz ze stosu, daną i wykonywaną.
Zresztą sam zerknij. Proszę nie krytykować... to stare jest już :) i
powycinane są rzeczy zbędne.
Aha można korzystać do woli, jak się komuś przyda.
> [ciach]

Akurat dokładnie tak samo pisze sobie maszynkę stanów w przerwaniu w tej
chwili ;) Też ze stosem ;)

Poprzedni Następny
Wiadomość
Spis treści
From: =?ISO-8859-2?Q?Krzysztof_Szmur=B3o?= <ks123_at_nospam_tlen.do.wyciecia.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 21:18:09 +0200


Sebastian Bialy napisał(a):
Krzysztof Szmurło wrote:

Ja to kiedyś na picu zrobiłem swego rodzaju interpreter. Chodziło toto w
przerwaniu od timera, odczytywało rozkaz ze stosu, daną i wykonywaną.
Zresztą sam zerknij. Proszę nie krytykować... to stare jest już :) i
powycinane są rzeczy zbędne.
Aha można korzystać do woli, jak się komuś przyda.

[ciach]

Akurat dokładnie tak samo pisze sobie maszynkę stanów w przerwaniu w tej
chwili ;) Też ze stosem ;)

No to życzę miłego programowania :)

EOT
Pozdrawiam
Krzysztof Szmurło

Poprzedni Następny
Wiadomość
Spis treści
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 22:36:25 +0200


Krzysztof Szmurło wrote:

Akurat dokładnie tak samo pisze sobie maszynkę stanów w przerwaniu w tej
chwili ;) Też ze stosem ;)

No to życzę miłego programowania :)

Mam nadzieję, że powstanie z tego ładna darmowa publiczna bilioteka
komunikacji na timerze przez 1-Wire. Oby tylko nie GNU. Wystarczy
licencja LGPL albo lepiej BSD.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.

Poprzedni Następny
Wiadomość
Spis treści
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 22:41:51 +0200


Mam nadzieję, że powstanie z tego ładna darmowa publiczna bilioteka
komunikacji na timerze przez 1-Wire. Oby tylko nie GNU. Wystarczy
licencja LGPL albo lepiej BSD.

GNU? Miales na mysli GPL?
Wbrew pozorom GPL wcale nie powoduje takiego zatrucia kodu jak pisza
oponenci. Z drugiej strony ja uwazam, ze normalne jest, ze skoro ktos
udostepnia ci za darmo swoja prace, to ty wprowadzajac do niej
modyfikacje rowniez ja udostepniasz.
Ale podpisuje sie obiema rekami i czekam na sliczna biblioteke:)



--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Poprzedni Następny
Wiadomość
Spis treści
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 22:48:28 +0200


T.M.F. przemówił ludzkim głosem:
Wbrew pozorom GPL wcale nie powoduje takiego zatrucia kodu jak pisza
oponenci. Z drugiej strony ja uwazam, ze normalne jest, ze skoro ktos
udostepnia ci za darmo swoja prace, to ty wprowadzajac do niej
modyfikacje rowniez ja udostepniasz.

To o czym piszesz zapewnia LPGL. A GPL dodatkowo "zmusza" cię do ujawnia
własnego kodu nawet jeśli nie nanosiłeś poprawek do czyjegoś kodu.
Myślę, że słowo zatrucie jest tu jak najbardziej na miejscu.

Poprzedni Następny
Wiadomość
Spis treści
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 23:23:51 +0200


Wbrew pozorom GPL wcale nie powoduje takiego zatrucia kodu jak pisza
oponenci. Z drugiej strony ja uwazam, ze normalne jest, ze skoro ktos
udostepnia ci za darmo swoja prace, to ty wprowadzajac do niej
modyfikacje rowniez ja udostepniasz.

To o czym piszesz zapewnia LPGL. A GPL dodatkowo "zmusza" cię do ujawnia
własnego kodu nawet jeśli nie nanosiłeś poprawek do czyjegoś kodu.
Myślę, że słowo zatrucie jest tu jak najbardziej na miejscu.

Nieprawda. Co prawda wielu madrych ludzi toczy o to spory i ja nie
podejmuje sie z tym polemizowac, jednak powszechnie uwaza sie, ze
ujawnic nalezy tylko ta czesc w ktorej wykorzystuje sie dany modul na
GPLu, tak wiec jesli np. wykorzystujesz OpenSSL jako DLL dolaczany do
swojego programu to samego kodu programu nie musisz ujawniac. Jesli
integrujesz cos z OpenSLL w jednej bibliotece to jak najbardziej taki
kod nalezy ujawnic.
Mozna polemizowac z tym, ale chyba zgodzisz sie ze mna, ze jesli
korzystasz za free z czyjejs pracy to samemu trzeba cos tez dac? Jesli
taka zasada komus sie nie podoba to jest przeciez mnostwo komercyjnych
programow, ktore nie maja takich warunkow.
Inbna sprawa to powszechne lamanie tej licencji - patrz chociazby
program Platnik, wykorzystujacy openSSL czy gg, ktory rowniez zawiera
ten modul, co zreszta autorzy cami pisza... No i co, mam pisac do Stallmana?


--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Poprzedni Następny
Wiadomość
Spis treści
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Mon, 10 Oct 2005 23:52:32 +0200


T.M.F. napisał(a):
Nieprawda. Co prawda wielu madrych ludzi toczy o to spory i ja nie
podejmuje sie z tym polemizowac, jednak powszechnie uwaza sie, ze
ujawnic nalezy tylko ta czesc w ktorej wykorzystuje sie dany modul na
GPLu, tak wiec jesli np. wykorzystujesz OpenSSL jako DLL dolaczany do
swojego programu to samego kodu programu nie musisz ujawniac.

jeśli mowa o GPL to musisz, nawet jeśli korzystasz z biblioteki
dynamicznej. za to OpenSSL jest licencji OpenSSL, podobne do licencji
BSD czy Apache, nie na GPL.

Jesli integrujesz cos z OpenSLL w jednej bibliotece to jak
najbardziej taki kod nalezy ujawnic.

nie musisz.

Inbna sprawa to powszechne lamanie tej licencji - patrz chociazby
program Platnik, wykorzystujacy openSSL czy gg, ktory rowniez zawiera
ten modul, co zreszta autorzy cami pisza... No i co, mam pisac do
Stallmana?

nie wiem jak Płatnik, ale GG wykorzystuje zgodnie OpenSSL z licencją --
w oknie informacji o programie informuje o pochodzeniu kodu.

w.

Poprzedni Następny
Wiadomość
Spis treści
From: =?ISO-8859-2?Q?=22Mi=B3osz_K=2E=22?= <news_at_nospam_miklobit.WYTNIJTO.com>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Tue, 11 Oct 2005 02:43:13 +0200


T.M.F. napisał(a):

Inbna sprawa to powszechne lamanie tej licencji - patrz chociazby
program Platnik, wykorzystujacy openSSL czy gg, ktory rowniez zawiera
ten modul, co zreszta autorzy cami pisza... No i co, mam pisac do
Stallmana?

Coś mi się zdaję, że jakby płatnik rzeczywiscie naruszał GPL, to Ci
, którzy od dawna walczą o udostepnienie go na inne OS, już by to
nagłośnili i wykorzystali.

--
Miłosz Kłosowicz

------------------------------------------------
AVR : ISP,JTAG,moduły prototypowe (USB,CAN)
TYPO3: projekty, webhosting, sklepy internetowe
-> http://www.miklobit.com
------------------------------------------------

Poprzedni Następny
Wiadomość
Spis treści
Date: Tue, 11 Oct 2005 02:51:10 +0200
From: RoMan Mandziejewicz <roman_at_nospam_pik-net.pl>
Subject: =?ISO-8859-2?B?UmU6IDEtV2lyZSBuYSBBVlIgaSBuaWVjbyBpbm5lIHBvZGVqtmNpZSBu?=


Hello Miłosz,

Tuesday, October 11, 2005, 2:43:13 AM, you wrote:

Inbna sprawa to powszechne lamanie tej licencji - patrz chociazby
program Platnik, wykorzystujacy openSSL czy gg, ktory rowniez zawiera
ten modul, co zreszta autorzy cami pisza... No i co, mam pisac do
Stallmana?
Coś mi się zdaję, że jakby płatnik rzeczywiscie naruszał GPL, to Ci
, którzy od dawna walczą o udostepnienie go na inne OS, już by to
nagłośnili i wykorzystali.

Naruszał i było to nagłosnione. Naruszeniem było nieprzyznanie się do
stosowania SSL, czyli brak odpowiednich (C). Ale było to na samym
początku, bo później już się bardzo pilnowali, że w 'credits' umieścić
wszystko, co potrzeba.

--
Best regards,
RoMan mailto:roman_at_nospam_pik-net.pl


Poprzedni Następny
Wiadomość
Spis treści
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Tue, 11 Oct 2005 18:01:09 +0200


T.M.F. przemówił ludzkim głosem:

Nieprawda.
[...]
tak wiec jesli np. wykorzystujesz OpenSSL jako DLL dolaczany do
swojego programu to samego kodu programu nie musisz ujawniac. Jesli
integrujesz cos z OpenSLL w jednej bibliotece to jak najbardziej taki
kod nalezy ujawnic.

W kontekście oprogramowania osadzonego ten wątek sprawy ma raczej
marginalne znaczenie (np. avr i dll :-) )

Mozna polemizowac z tym, ale chyba zgodzisz sie ze mna, ze jesli
korzystasz za free z czyjejs pracy to samemu trzeba cos tez dac?

No ba.

Poprzedni Następny
Wiadomość
Spis treści
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Tue, 11 Oct 2005 22:53:11 +0200


T.M.F. wrote:

Mam nadzieję, że powstanie z tego ładna darmowa publiczna bilioteka
komunikacji na timerze przez 1-Wire. Oby tylko nie GNU. Wystarczy
licencja LGPL albo lepiej BSD.

GNU? Miales na mysli GPL?
Wbrew pozorom GPL wcale nie powoduje takiego zatrucia kodu jak pisza
oponenci. Z drugiej strony ja uwazam, ze normalne jest, ze skoro ktos
udostepnia ci za darmo swoja prace, to ty wprowadzajac do niej
modyfikacje rowniez ja udostepniasz.

Oby tylko chodziło o bibliotekę to nie mam nic przeciwko. Ale jeżeli z
biblioteką do obsługi 1-Wire będę musiał opublikować kod źródłowy
wielkiego programu to ja dziękuję za taką bibliotekę.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.

Poprzedni Następny
Wiadomość
Spis treści
From: "William" <nie_at_nospam_ma.mnie.pl>
Subject: Re: 1-Wire na AVR i nieco inne podejście niż typowe
Date: Wed, 12 Oct 2005 09:11:31 +0200


Oby tylko chodziło o bibliotekę to nie mam nic przeciwko. Ale jeżeli z
biblioteką do obsługi 1-Wire będę musiał opublikować kod źródłowy
wielkiego programu to ja dziękuję za taką bibliotekę.

Nie opublikować tylko udostępnić. I nie wszystkim a jedynie nabywcy. On
co prawda może dalej opublikować twoje źródło np. w niecie, ale jest
wątpliwym by to zrobił bo przecież sam zapłacił za powstanie tego kodu
źródłowego. Ten model licencji uniezależnia tylko klienta od sprzedawcy w
kwestii dalszego rozwoju kodu.



Poprzedni Następny
Wiadomość
Spis treści
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Fri, 14 Oct 2005 12:06:12 +0200


William wrote:

Oby tylko chodziło o bibliotekę to nie mam nic przeciwko. Ale jeżeli z
biblioteką do obsługi 1-Wire będę musiał opublikować kod źródłowy
wielkiego programu to ja dziękuję za taką bibliotekę.

Nie opublikować tylko udostępnić. I nie wszystkim a jedynie nabywcy. On
co prawda może dalej opublikować twoje źródło np. w niecie, ale jest
wątpliwym by to zrobił bo przecież sam zapłacił za powstanie tego kodu
źródłowego. Ten model licencji uniezależnia tylko klienta od sprzedawcy w
kwestii dalszego rozwoju kodu.

Nabywcy/zleceniodawcy to i tak z założenia daję pełny kod źródłowy
całości. Łącznie z oryginalnymi plikami używanych obcych bibliotek. Ale
chodziło mi o to, że używając kod np. na licencji GNU muszę się moim
całym programem podzielić z resztą świata. A to jest w tym przypadku dla
mnie niedopuszczalne. Licencja BSD tego nie wymaga, na szczęście.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.

Poprzedni Następny
Wiadomość
Spis treści
From: "William" <nie_at_nospam_ma.mnie.pl>
Subject: Re: 1-Wire na AVR i nieco inne podejście niż typowe
Date: Fri, 14 Oct 2005 15:16:43 +0200


Nabywcy/zleceniodawcy to i tak z założenia daję pełny kod źródłowy
całości. Łącznie z oryginalnymi plikami używanych obcych bibliotek. Ale
chodziło mi o to, że używając kod np. na licencji GNU muszę się moim
całym programem podzielić z resztą świata. A to jest w tym przypadku dla
mnie niedopuszczalne. Licencja BSD tego nie wymaga, na szczęście.


A ja ci właśnie mówię, że nie. Na GNU nie udostępniasz źródeł całemu
światu tylko odbiorcy.



Poprzedni Następny
Wiadomość
Spis treści
From: Marek Michalkiewicz <spamtrap_at_nospam_amelek.gda.pl.invalid>
Subject: Re: 1-Wire na AVR i nieco inne podej?cie ni? typowe
Date: Fri, 14 Oct 2005 21:37:57 +0200 (CEST)


William <nie_at_nospam_ma.mnie.pl> wrote:

A ja ci w?a?nie mówi?, ?e nie. Na GNU nie udost?pniasz ?róde? ca?emu
?wiatu tylko odbiorcy.

Ale teoretycznie odbiorca powinien udostepnic zrodla dalej swoim
klientom, ktorym sprzedaje swoj wyrob z oprogramowaniem GPL.

Tyle teorii... Praktycznie to na Tajwanie nic sobie nie robia
z GPL - niech ktos bogaty w koncu wygra proces przykladowo z taka
firma Realtek o udostepnienie (zgodnie z GPL) kompletnego kodu
zrodlowego kernela SDK dla RTL8181 (Linux 2.4.18 + binarny driver
WLAN, linkowany statycznie a nie jako modul). Naruszenia GPL
dopuszczaja sie tak samo rowniez kolejni dystrybutorzy/sprzedawcy
tego sprzetu (chyba, ze sprzedawaliby goly sprzet, a klient ma
sobie sam znalezc i wgrac firmware :). Z nowym RTL8186 podobno
wcale nie jest lepiej... http://online.pl/pages/?q=node/374

Co do bibliotek dla AVR w zastosowaniach komercyjnych, to polecam
licencje BSD (jak w avr-libc), lub GPL + wyjatek (jak w libgcc).
Licencje to sliska sprawa, potrafia byc ze soba niekompatybilne
(nawet gdy kazda z osobna jest OK), wiec im prostsze i jest ich
mniej roznych tym lepiej :)

Marek

Poprzedni Następny
Wiadomość
Spis treści
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: 1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF?=
Date: Tue, 11 Oct 2005 00:13:07 +0200


Adam Dybkowski napisał(a):
Mam nadzieję, że powstanie z tego ładna darmowa publiczna bilioteka
komunikacji na timerze przez 1-Wire. Oby tylko nie GNU. Wystarczy
licencja LGPL albo lepiej BSD.

pisałem już wcześniej, że LGPL w przypadku statycznego łączenia kodu
nie różni się w praktyce od GPL. jeśli udostępnienie kodu źródłowego nie
ma być jedynie chwytem marketingowym, lepiej sobie darować tą licencję i
zrobić ludzkości przysługę zaprzyjaźniając się z BSD.

w.

Poprzedni Następny
Wiadomość
Spis treści
From: Slawomir Sidor <slawek_at_nospam_graficomp.com.pl>
Subject: Re: 1-Wire na AVR i nieco inne podejście niż typowe
Date: Mon, 10 Oct 2005 17:29:50 +0200


1) Procedury 1-Wire nie mogą być aktywnie czekające w głównej pętli, bo
ta pętla ma co robić i robi to w dodatku niestabilnie czasowo.

Ale 1-Drut nie musi czekać. Przecież to procesor decyduje kiedy
odczytuje dane. Czujniki nie mają na to wpływu.

2) W systemie jest już sporo przerwań (UART,Timer,Ext) które są
ważniejsze od 1-Wire (na którym jest mało ważny miernik temperatury, ale
być musi).

Temperatury nie ma sensu czytać zbyt często. Może co jakiś długi czas
możesz wyłączyć pozostałe przerwania?
Jeśli nie możesz to żaden problem. Odczyt temperatury zostanie
przerwany, wykona się następnym razem.

3) 1-Wire jest nie dość, że strasznie czuły na czasy to w dodatku sa to
czasy krótkie (15us to krócej niż 256 cykli zegara 14MHz - konkretnie
17us - więc timery się komplikują).

No jeśli przerwanie timera który musi działać jest częstrze niż czas
potrzebny na odczytanie temperatury to pora zmienić projekt układu.

4) Wszystkie biblioteki jake znalazłem w necie sa aktywnie czekające w
głównej pętli.

Tyle, że to nie ma sensu.

(przerwanie 1-Wire było by jedynym nieprzerywalnym, reszta może byc
przerwana).

Tylko czy jest sens czytać temperaturę co sekundę naprzykład?

b) Czy mogę pomiędzy poszczególnymi slotami dawać dowolnie długie
przerwy (nie mam zasilania z lini danych dla miernika temp, normalnie
przez Vcc) ?

Nie sprawdzałem, ale co pisze Dallas w swoich dokumentach?

c) Czy mam słuszną koncepcję ;) ?

Koncepcji słusznych może być dużo.
Jeśli zadziała to jest słuszna :)
--
Slawomir Sidor N 51 58.1385 E020 09.1966


Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: 1-Wire na AVR i nieco inne =?UTF-8?B?cG9kZWrvv71jaWUgbmnFvCB0?=
Date: Mon, 10 Oct 2005 17:47:40 +0200


Slawomir Sidor wrote:
1) Procedury 1-Wire nie mogą być aktywnie czekające w głównej pętli, bo
ta pętla ma co robić i robi to w dodatku niestabilnie czasowo.
Ale 1-Drut nie musi czekać. Przecież to procesor decyduje kiedy
odczytuje dane. Czujniki nie mają na to wpływu.

Obawiam się, że to magistrala asynchroniczna i w przypadku odczytu bitów
musze to zrobić w szczelinie czasowej 15us co oznacza koło 200 cykli
zegarowych. Z drugiej strony użycie delay(200); i kręcenie się bez sensu
w pętli jest głupotą bo bym musiał wyłączyć przerwania na ten czas (a
wolałbym nie).

2) W systemie jest już sporo przerwań (UART,Timer,Ext) które są
ważniejsze od 1-Wire (na którym jest mało ważny miernik temperatury, ale
być musi).

Temperatury nie ma sensu czytać zbyt często. Może co jakiś długi czas
możesz wyłączyć pozostałe przerwania?

Nie mogę. Jedno z przerwań jest periodyczne i musi być obsługiwane z
częstotliwością większą niż pełny cykl odczytu DS1820.

Jeśli nie możesz to żaden problem. Odczyt temperatury zostanie
przerwany, wykona się następnym razem.

Niestety w tym przypadku zostanie przerwany za kaĹźdym razem. A takie
przerwanie spowoduje zakłucenie "czasowosci" magistrali 1-Wire i utratę
bitu.

3) 1-Wire jest nie dość, że strasznie czuły na czasy to w dodatku sa to
czasy krĂłtkie (15us to krĂłcej niĹź 256 cykli zegara 14MHz - konkretnie
17us - więc timery się komplikują).

No jeśli przerwanie timera który musi działać jest częstrze niż czas
potrzebny na odczytanie temperatury to pora zmienić projekt układu.

Nie rozumiesz - 15us to minimalna jednostka czsowa 1-Wire - w przypadku
ektremalnym musze własnie w tym czasie odczytać bit z magistrali inaczej
go stracę. MUSZĘ. To jest priorytet. Ale na szczęscie dotyczy to odczytu
pojedynczego bitu. Dlatego za marnotrawstwo uznaje zabieranie głównej
pętli progamu na odczyt 64 bitów. Wolałbym żeby krytyczna czasowo
operacja odczytu/zapisu bitu była na przerwaniach. Reszta już lajtowo w
głównej pętli na zasadzie procedury onewire_next_step() która może to
robić bit po bicie przez godzinę. Nie zależy mi na szybkości.

4) Wszystkie biblioteki jake znalazłem w necie sa aktywnie czekające w
głównej pętli.
Tyle, Ĺźe to nie ma sensu.

Te biblioteki nie mają sensu ? Czy mój pomysł nie ma sensu ?

(przerwanie 1-Wire było by jedynym nieprzerywalnym, reszta może byc
przerwana).
Tylko czy jest sens czytać temperaturę co sekundę naprzykład?

Nie - jak napisałem wyżej mogę co godzinę. Nie mogę jednak zablokowac
głównej pętli na czas odczytu oraz nie mogę zablokowac przerwań na czas
odczytu. Chciałbym jednak zablokować przerwania na czas odczytu
pojedynczego bitu (też nie do końca, teoretycznie inne przerwania
mogły by być przerywalne przez timer 1-Wire a on sam już nie - zapewnia
mi to namiastkę priorytetów) a resztę logiki zrobić na zasadzie maszynki
stanów z głównej pętli.

Nie sprawdzałem, ale co pisze Dallas w swoich dokumentach?

Wydaje mi sie, że tak, jednak w prost nie znalazłem stwierdzenia. Gdyby
się nie dało (napisane by było w prost) w ogóle bym ten pomysł porzucił.