1-Wire na AVR i nieco inne =?ISO-8859-2?Q?podej=B6cie_ni=BF_?=
Masz problem? Zapytaj na forum elektroda.pl
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ę ;) ?
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
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.
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.
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.
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.
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ł.
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.
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.
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
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.
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.
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
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
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.
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
}
}
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 ;)
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
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.
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.
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.
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.
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.
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
------------------------------------------------
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
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.
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.
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.
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.
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.
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
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.
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
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Ĺ.