Wył±czanie przerwań 'na chwilę'
Masz problem? Zapytaj na forum elektroda.pl
From: "Wojtek" <pirat320_at_nospam_cutit.interia.pl>
Subject: Wył±czanie przerwań 'na chwilę'
Date: Tue, 18 Oct 2005 17:21:51 +0200
Przegl±daj±c dokumentacje kompilatora AVR-GCC
(i nie tylko) można natrafić na przykłady, w których
tu i ówdzie występuje OPERACJA KRYTYCZNA,
w czasie której nie może wyst±pić przerwanie, więc
sobie na chwilkę wył±czamy wszystkie przerwania.
Dalej mamy t± OPERACJĘ KRYTYCZNˇ,
(zazwyczaj kilka instrukcji maszynowych) i potem
odblokowujemy przerwania. Przy tym wszystkim ani
słowa o możliwo¶ci błędnego zadziałania systemu
z powodu wył±czenia przerwań.
A co je¶li wyst±pi przerwanie wyzwalane zboczem z
enkodera zamontowanego na silniku? Jestem
przekonany, że stracimy informację o dokładnym
położeniu silnika.
We wszelkiej ma¶ci systemach czasu rzeczywistego
dla AVR jest to wręcz na porz±dku dziennym.
Strasznie denerwuje mnie, że to wył±czanie przerwań
'na chwilę' jest robione w przykładach bez słowa o
konsekwencjach.
A może ja czego¶ nie wiem??? Proszę o komentarze.
Pozdrawiam
Wojtek
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: =?ISO-8859-2?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
Date: Tue, 18 Oct 2005 17:34:53 +0200
A może ja czego¶ nie wiem??? Proszę o komentarze.
Tak, nie wiesz:)
AVR "pamieta", ze bylo przerwanie i zaraz po odblokowaniu zostanie ono
zgloszone. Oczywiscie jesli sekcja krytyczna trwa dluzej niz odstep
pomiedzy kolejnymi przerwaniami TEGO SAMEGO TYPU to kolejne przerwania
zostana zgubione.
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
From: "Wojtek" <pirat320_at_nospam_cutit.interia.pl>
Subject: Re: Wył±czanie przerwań 'na chwilę'
Date: Wed, 19 Oct 2005 12:11:43 +0200
Użytkownik "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl> napisał w wiadomo¶ci
news:n9hf23-1fh.ln1_at_nospam_hermes.wizzard...
AVR "pamieta", ze bylo przerwanie i zaraz po odblokowaniu zostanie ono
zgloszone. Oczywiscie jesli sekcja krytyczna trwa dluzej niz odstep
pomiedzy kolejnymi przerwaniami TEGO SAMEGO TYPU to kolejne przerwania
zostana zgubione.
Dzięki za odpowiedzi a za Tˇ szczególnie.
Pozdrawiam
Wojtek
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: =?ISO-8859-2?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
Date: Tue, 18 Oct 2005 19:04:07 +0200
T.M.F. przemówił ludzkim głosem:
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie
obslugi przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne. A
No niekoniecznie. Prosty przyklad - odczytujesz na 8-bitowcu zmienna
wielobajtowa, ktorej zawartosc jest modyfikowana w procedurze obslugi
przerwan. Jesli nie zablokujesz przerwan na czas odczytu calej zmiennej
grozi ci, ze odczytasz smieci (jesli pomiedzy odczytami wystapilo
przerwanie modyfikujace wartosc zmiennej). A to tylko pierwszy z brzegu
przyklad.
To ja dorzucę do tego przykładu jeszcze wszelkie operacje wykonywane na
SFR 16-bitowych w AVR. Je¶li jakie¶ przerwanie także korzysta z SFR
16-bitowych , to istnieje spora szansa odczytania poza przerwaniem nie
tej zawarto¶ci rejestru po¶redniego, o któr± nam chodziło :-)
From: "Ukaniu" <L99ukaszWYWALTO_at_nospam_gazeta.pl>
Subject: =?iso-8859-2?Q?Re:_Wy=B3=B1czanie_przerwa=F1_'na_chwil=EA'?=
Date: Tue, 18 Oct 2005 20:49:54 +0200
Użytkownik "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl> napisał w wiadomo¶ci
news:lqpf23-45o.ln1_at_nospam_hermes.wizzard...
No ok, ale co to zmienia? Istnienie sekcji programu, ktore wymagaja
wylaczenia przerwan nic nie zmienia. Przeciez to nie sa sekcje, ktore
wykonuja sie 1 sekunde, tylko kilkuinstrukcjowe fragmenty, jak wiec maja
one wplynac na WD?
Wła¶nie, o to chodzi, coprawda ja dopiero zaczynam praktykę, ale nie da się
w 2kb (2313) upchn±ć semaforów, zaawansowanych procesów sterowania itd. A
przerwania s± i działaj± dobrze.
Pozatym w tak małym kodzie zazwyczaj potem nie wprowadza się wielkich
poprawek które mogły by wpłyn±ć na zbyt długie wył±czenie obsługi przerwań,
no i ogarn±ć go łatwo.
Pozdrawiam Łukasz
Date: Tue, 18 Oct 2005 12:37:01 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?ISO-8859-1?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
Wojtek wrote:
Przegl±daj±c dokumentacje kompilatora AVR-GCC
(i nie tylko) można natrafić na przykłady, w których
tu i ówdzie występuje OPERACJA KRYTYCZNA,
w czasie której nie może wyst±pić przerwanie, więc
sobie na chwilkę wył±czamy wszystkie przerwania.
Dalej mamy t± OPERACJĘ KRYTYCZNˇ,
(zazwyczaj kilka instrukcji maszynowych) i potem
odblokowujemy przerwania. Przy tym wszystkim ani
słowa o możliwo¶ci błędnego zadziałania systemu
z powodu wył±czenia przerwań.
A co je¶li wyst±pi przerwanie wyzwalane zboczem z
enkodera zamontowanego na silniku? Jestem
przekonany, że stracimy informację o dokładnym
położeniu silnika.
We wszelkiej ma¶ci systemach czasu rzeczywistego
dla AVR jest to wręcz na porz±dku dziennym.
Strasznie denerwuje mnie, że to wył±czanie przerwań
'na chwilę' jest robione w przykładach bez słowa o
konsekwencjach.
A może ja czego¶ nie wiem??? Proszę o komentarze.
Pozdrawiam
Wojtek
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie obslugi
przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne. A
poza tym normalnie uklady z mikrokontrolerem powiny miec WatchDog jesli
jest o cos wbudowane w procek to czasem unieszkodliwiasz i to tez.
Jjesli zewnetrzny to ryzykujesz ze zadziala w nieodpowiednim momencie.
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze rowniez
powszechnie daje to fatalne rezultaty.
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: =?ISO-8859-1?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
Date: Tue, 18 Oct 2005 18:48:13 +0200
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie obslugi
przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne. A
No niekoniecznie. Prosty przyklad - odczytujesz na 8-bitowcu zmienna
wielobajtowa, ktorej zawartosc jest modyfikowana w procedurze obslugi
przerwan. Jesli nie zablokujesz przerwan na czas odczytu calej zmiennej
grozi ci, ze odczytasz smieci (jesli pomiedzy odczytami wystapilo
przerwanie modyfikujace wartosc zmiennej). A to tylko pierwszy z brzegu
przyklad.
poza tym normalnie uklady z mikrokontrolerem powiny miec WatchDog jesli
jest o cos wbudowane w procek to czasem unieszkodliwiasz i to tez.
Jjesli zewnetrzny to ryzykujesz ze zadziala w nieodpowiednim momencie.
Pytanie dotyczylo AVR, a ich watchdogowi nie szkodzi blokowanie przerwan
(byloby to swoiste kuriozum). Zewnetrzne WD tez chyba bazuja na sygnale
RESET, bo zglaszanie prockowi przerwania z sugestia "cos ci sie stary
poknocilo, wiec sie zresetuj" byloby chyba nie na miejscu;P
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze rowniez
powszechnie daje to fatalne rezultaty.
Przyklad prosze?
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
Date: Tue, 18 Oct 2005 13:16:42 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?ISO-8859-1?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
T.M.F. wrote:
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie
obslugi przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne. A
No niekoniecznie. Prosty przyklad - odczytujesz na 8-bitowcu zmienna
wielobajtowa, ktorej zawartosc jest modyfikowana w procedurze obslugi
przerwan. Jesli nie zablokujesz przerwan na czas odczytu calej
zmiennej grozi ci, ze odczytasz smieci (jesli pomiedzy odczytami
wystapilo przerwanie modyfikujace wartosc zmiennej). A to tylko
pierwszy z brzegu przyklad.
O tylen wstrzymywanie przerwn nie jest konieczne ze normalnie program
obslugi przerwan powinien ustawiac odpowiednie semafory kture tez sam
potem sprawdza. Jak ma zapisywac ta liczbe to musi wiedziec ze w tym
momencie nie jest ona czytana.
poza tym normalnie uklady z mikrokontrolerem powiny miec WatchDog
jesli jest o cos wbudowane w procek to czasem unieszkodliwiasz i to
tez. Jjesli zewnetrzny to ryzykujesz ze zadziala w nieodpowiednim
momencie.
Pytanie dotyczylo AVR, a ich watchdogowi nie szkodzi blokowanie
przerwan (byloby to swoiste kuriozum).
Mas racje to co napisalem o WD i przerwaniach mija sie z prawda.
Rozpedzilem sie.
Zewnetrzne WD tez chyba bazuja na sygnale RESET, bo zglaszanie
prockowi przerwania z sugestia "cos ci sie stary poknocilo, wiec sie
zresetuj" byloby chyba nie na miejscu;P
To widze ze nie uzywales takowego kolego. Jet odwrotnie. Procek musi
periodycznie podac do WD sygnal, impuls ze ciagle jest zywy. Jak nie
poda tego sygnalu przez sekunde to znaczy ze sie gdzies zapedzil w
martwy punkt i nalezy go resetowac.
Kawalek programu ktory daje kpniaga do WD powinien byc wsadzony w takim
miejscu w programie przez kture musi przechodzic regularnie zazwyczaj w
glownej petli (Main Loop) systemu. Ludzie robia blad wsadajac to w
wielu miejscach Czasem to sie wydaje konieczne ale nie powinno miec
miejsca. Wtedy pogram zapetlony jakiejs "bocznej petli" moze dawac
sygnal ze jest w porzadku podczas gdy w rzeczywistosci nie jest.
Bardzo fajne sa ukladziki Dallas'a ktore maja w sobie uklad resetu przy
zalaczniu, WD a takze rozpoznanie spadku zasilania i wtedy generuja
przerwanie a pozniej reset.
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze
rowniez powszechnie daje to fatalne rezultaty.
Przyklad prosze?
Tu chodzi glownie o to ze pogram moze sie zapetlic i nie zreaktywowac
przerwan. Wiem. Powiesz ze jak dobrze napisany to sie nie zapetli. Ale
to nie zawsze ma miejsce (dobre napisanie) a poza tym program sie
zapetla w z powodu zaklocen i to znacznie czesciej niz niektorzy mysla.
Mam z tym troche praktyke i dlatego to mowie.
Glownym jednak problemem jest wlasnie to ze najpierw sie mysli ze
zatrzymuje przerwania na malenka chwilke a potem ktos inny modyfikuje
program i ta chwilka sie robi troche wieksza. No i czasem dochodzi do
problemu z przeoczonymi przerwaniami.
Wiele programistow zaklada ze to tylko on bedzie tworzyl i modyfikowal
program a czasem zreszta swidomi pisza tak zeby nikt tego nie mogl
zrozumiec. Ale czesto jednak jest tak ze ktos inny to potem porawia i
przerabia i wlasnie te zle obyczaje programistyczne i brak dyscypliny w
strukturze programu przynosi fataln skutki.
Po paru modyfikacjach program jest juz nie do naprawienia przez nikogo.
To mnij wiecej tyle co mi teraz przyszlo do glowy w tym temacie.
Pozdro
grzechu
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Tue, 18 Oct 2005 19:56:56 +0200
Greg wrote:
O tylen wstrzymywanie przerwn nie jest konieczne ze normalnie program
obslugi przerwan powinien ustawiac odpowiednie semafory kture tez sam
potem sprawdza. Jak ma zapisywac ta liczbe to musi wiedziec ze w tym
momencie nie jest ona czytana.
Operacja odczytaj-zapisz semafor powinna być atomowa. Podobnie mutexu.
Chyba nie da się jej na AVRach zrobić bez wyłaczania przerwań. A może
siÄ™ mylÄ™ ?
Tu chodzi glownie o to ze pogram moze sie zapetlic i nie zreaktywowac
przerwan. Wiem. Powiesz ze jak dobrze napisany to sie nie zapetli. Ale
to nie zawsze ma miejsce (dobre napisanie) a poza tym program sie
zapetla w z powodu zaklocen i to znacznie czesciej niz niektorzy mysla.
Mam z tym troche praktyke i dlatego to mowie.
Na zakłucenia nic nie pomoże, czy wyłaczysz czy nie przerwania to
przestawienie jednego bitu w pamięci może wywołać dowolne efekty. IMHO
zastanawianie się co wtedy zrobić nie ma zupełnie sensu. Jesli nastapił
błąd obliczeń procesora to nalezy do niego niedopuścić następnym razem i
juĹĽ.
Glownym jednak problemem jest wlasnie to ze najpierw sie mysli ze
zatrzymuje przerwania na malenka chwilke a potem ktos inny modyfikuje
program i ta chwilka sie robi troche wieksza. No i czasem dochodzi do
problemu z przeoczonymi przerwaniami.
Hmmm jedyne co mi przychodzi do głowy to stawiać instrukcjie CLI/SEI jak
najbliżej siebie. Choć akurat grzebanie w sekcjach krytycznych nie
powinno byc częste, prawda ? Jak dla mnie to nie jest argument.
Date: Tue, 18 Oct 2005 16:46:18 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Sebastian Bialy wrote:
Greg wrote:
O tyle wstrzymywanie przerwan nie jest konieczne, ze normalnie
program obslugi przerwan powinien ustawiac odpowiednie semafory ktore
tez sam potem sprawdza. Jak ma zapisywac ta liczbe to musi wiedziec
ze w tym momencie nie jest ona czytana.
Operacja odczytaj-zapisz semafor powinna być atomowa. Podobnie mutexu.
Chyba nie da się jej na AVRach zrobić bez wyłaczania przerwań. A może
siÄ™ mylÄ™ ?
Nie widze problemu.
Np semafor "Dane Gotowe" ustawiasz w czasei obslugi przerwania. Tam
gdzie dane sa czytane mozesz go zerowac po przeczytaniu i jest ok.
Jesli przychodza nastepne dane a semafor nie jest wyzerowany to ustawia
sie sygnal ze jest "overflow"
Tu chodzi glownie o to ze pogram moze sie zapetlic i nie zreaktywowac
przerwan. Wiem. Powiesz ze jak dobrze napisany to sie nie zapetli. Ale
to nie zawsze ma miejsce (dobre napisanie) a poza tym program sie
zapetla w z powodu zaklocen i to znacznie czesciej niz niektorzy
mysla. Mam z tym troche praktyke i dlatego to mowie.
Na zakłucenia nic nie pomoże, czy wyłaczysz czy nie przerwania to
przestawienie jednego bitu w pamięci może wywołać dowolne efekty. IMHO
zastanawianie się co wtedy zrobić nie ma zupełnie sensu. Jesli
nastapił błąd obliczeń procesora to nalezy do niego niedopuścić
następnym razem i już.
Nie zrozumielismy sie moze.
Jak przerwania sa utrupione to latwiej o calkowita zakorkowanie sie
programu.
Wurzadzeniah ktore chodza same i nie powinny wumagac interwencji
czlowieka to jest raczej katastrofa.
Masz np. streownik ogrzewania i musisz do niego dojsc i zresetowac
recznie albo sprawdzac co jest bo nie chodzi
Glownym jednak problemem jest wlasnie to ze najpierw sie mysli ze
zatrzymuje przerwania na malenka chwilke a potem ktos inny modyfikuje
program i ta chwilka sie robi troche wieksza. No i czasem dochodzi do
problemu z przeoczonymi przerwaniami.
Hmmm jedyne co mi przychodzi do głowy to stawiać instrukcjie CLI/SEI
jak najbliżej siebie. Choć akurat grzebanie w sekcjach krytycznych nie
powinno byc częste, prawda ? Jak dla mnie to nie jest argument.
Nie powinno byc, jako rzekles
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Tue, 18 Oct 2005 23:06:37 +0200
Greg wrote:
Operacja odczytaj-zapisz semafor powinna być atomowa. Podobnie mutexu.
Chyba nie da się jej na AVRach zrobić bez wyłaczania przerwań. A może
siÄ™ mylÄ™ ?
Nie widze problemu.
Np semafor "Dane Gotowe" ustawiasz w czasei obslugi przerwania. Tam
gdzie dane sa czytane mozesz go zerowac po przeczytaniu i jest ok.
Jesli przychodza nastepne dane a semafor nie jest wyzerowany to ustawia
sie sygnal ze jest "overflow"
To o czym piszesz to raczej odmiana mutexu (a i to nie do końca) niż
semaforu - semafory służą raczej do podziału zadań między wątki a nie do
synchronizacji 2 procesĂłw.
Taki przykład miałby sens większy, gdybysmy mieli do czynienia z
przełaczaniem kontekstu dwóch watków w nieoczekiwanych miescach. A AVR
raczej chyba nie stosowane ze względu na spory narzut samego przełaczania.
IMHO stosowanie mutexĂłw/semaforĂłw na AVR jest bez sensu a tego typu
proste machanizmy jak opisujesz są dość oczywiste.
Natomaist dalej będe się upierał, że semafor wymaga operacji atomowej
złożonej (dekrementacja/inkrementacja semafora).
Na zakłucenia nic nie pomoże, czy wyłaczysz czy nie przerwania to
przestawienie jednego bitu w pamięci może wywołać dowolne efekty. IMHO
zastanawianie się co wtedy zrobić nie ma zupełnie sensu. Jesli
nastapił błąd obliczeń procesora to nalezy do niego niedopuścić
następnym razem i już.
Nie zrozumielismy sie moze.
Jak przerwania sa utrupione to latwiej o calkowita zakorkowanie sie
programu.
Myśle, że urzadzenie, które się "korkuje" samo z siebie nie nadaje się
do uĹĽywania w dowolnej formie ;)
Wurzadzeniah ktore chodza same i nie powinny wumagac interwencji
czlowieka to jest raczej katastrofa.
Masz np. streownik ogrzewania i musisz do niego dojsc i zresetowac
recznie albo sprawdzac co jest bo nie chodzi
) Nie wiem, czy uzywanie watchdoga jest dobrym pomysłem do łatania
programu :)
From: jerry1111 <nie_chce_wiecej_spamu_jerry1111_wytnij_to__at_nospam_wp.pl.cholera>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 09:43:22 +0100
Sebastian Bialy wrote:
To o czym piszesz to raczej odmiana mutexu (a i to nie do końca) niż
semaforu - semafory służą raczej do podziału zadań między wątki a nie do
synchronizacji 2 procesĂłw.
Oboje macie racje ;-)
Ale w momencie jak chcemy uzyc jakiegos RTOSa, to Sebastian ma racje -
bez blokowania przerwan w sekcjach krytycznych za duzo nie nawojujemy.
Po prostu trzeba wiedziec jak pisac takie programy. A trzeba to
robic naprawde starannie ;-)
Nie zrozumielismy sie moze.
Jak przerwania sa utrupione to latwiej o calkowita zakorkowanie sie
programu.
Myśle, że urzadzenie, które się "korkuje" samo z siebie nie nadaje się
do uĹĽywania w dowolnej formie ;)
Wurzadzeniah ktore chodza same i nie powinny wumagac interwencji
czlowieka to jest raczej katastrofa.
) Nie wiem, czy uzywanie watchdoga jest dobrym pomysłem do łatania
programu :)
Program ma byc pisany i testowany bez WD. Ja WD uzywam dopiero w
finalnej wersji programu - wczesniej nie ma sensu, bo moge nie zauwazyc
ze czasami idzie wszystko w maliny.
--
Jerry
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 11:22:04 +0200
Użytkownik jerry1111 napisał:
Program ma byc pisany i testowany bez WD. Ja WD uzywam dopiero w
finalnej wersji programu - wczesniej nie ma sensu, bo moge nie zauwazyc
ze czasami idzie wszystko w maliny.
Otóż właśnie. Program powinien działać pewnie i stabilnie bez
zabezpieczeń, przy wszystkich możliwych kombinacjach czasowych zdarzeń.
Zabezpieczenia są lekiem tylko na szczególne przypadki. Oczywiście nie
liczÄ…c trickĂłw specjalnego przeznaczenia, jak np okresowe wzbudzanie
programu przez wd.
Poza tym nieumiejętne użycie resetu krytycznego też może nieźle
namieszać w urządzeniu, którym steruje nasz program.
--
Pozdrawiam,
A. Grodecki
Date: Wed, 19 Oct 2005 10:47:35 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
... nie liczÄ…c trickĂłw specjalnego przeznaczenia, jak np okresowe
wzbudzanie programu przez wd.
Co to za ciekawostka ?
Ja zawsze uwazalem ze WD ma powodowac restart kompletnie od zera i tyle.
Nie stosuje sie go do nieczego innego jak do zapobierzenia
nieprzewidzanym sytuacjom gdzie program przestaje dzialac prawidlowo z
jakiegos powodu.
Poza tym nieumiejętne użycie resetu krytycznego też może nieźle
namieszać w urządzeniu, którym steruje nasz program.
Reset jest zawsze zlem koniecznym i oczywiscie trzeba uwzglednic co sie
steruje. Urzadzenie w ruchu, jakas mszyna moze byc poszkodowane/na w
takeij sytuacji.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 17:12:08 +0200
Użytkownik Greg napisał:
... nie liczÄ…c trickĂłw specjalnego przeznaczenia, jak np okresowe
wzbudzanie programu przez wd.
Co to za ciekawostka ?
Żadna ciekawostka, jeden ze sposobów okresowego wyciągania procesora z
uśpienia jub pętli do której został (celowo) wprowadzony.
Manewrowanie peryferiami daje bardzo ciekawe możliwości. Oczywiście
używa się takich rzeczy tylko w razie potrzeby i dostępności peryferiów.
--
Pozdrawiam,
A. Grodecki
Date: Wed, 19 Oct 2005 11:46:53 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
Użytkownik Greg napisał:
... nie liczÄ…c trickĂłw specjalnego przeznaczenia, jak np okresowe
wzbudzanie programu przez wd.
Co to za ciekawostka ?
Żadna ciekawostka, jeden ze sposobów okresowego wyciągania procesora z
uśpienia jub pętli do której został (celowo) wprowadzony.
No to to jest nieczyste zagranie. Domyslam sie ze procek nie musi caly
czas pracowac. Robilem so takiego do radiotelefony chodzacego na baterii
slonecznej. Chodzilo o to zeby spal jak najdluzej i tylko co jakis czas
sie budzil i sprawdzal czy czegos od niego nie chca. Ale na to mialem
tajmerek z 555 ktory wysylal przerwanie co jakis czas.
WD powinien byc tylko dla bezpiecznstwa i ma robic Reset kompletny.
Regularne, okresowe robienie resetu to raczej nonsens.
Przynajmniej w urzadzeniach ktore robile to nie mialoby sensu. Jak
inicjalizacja trwa 300 ms to nie moge sobie pozwalac na robienie tego
bez potrzeby.
Ale jak robisz maly programik to moze to miec jakis sens.
Manewrowanie peryferiami daje bardzo ciekawe możliwości. Oczywiście
używa się takich rzeczy tylko w razie potrzeby i dostępności peryferiów.
Napisales ogolnikowo wiec to znaczy wszytko i nic.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 19:35:11 +0200
Użytkownik Greg napisał:
Żadna ciekawostka, jeden ze sposobów okresowego wyciągania procesora z
uśpienia jub pętli do której został (celowo) wprowadzony.
No to to jest nieczyste zagranie.
Co to znaczy nieczyste zagranie? Element, choćby i procesor, ma być tak
uzyty aby nie przekraczać parametrów granicznych. A czy używamy różnych
wybiegĂłw, stosujÄ…c normalnie rozwiÄ…zania przeznaczone W ZASADZIE do
czego innego, to już sprawa projektanta. Byle działało i działało dobrze.
Microchip np wydaje takie małe książeczki z serii "Tips and Tricks" w
których sa opisane różne metody nietypowego wykorzystania "typowych"
peryferiów albo uzyskania zaskakujących możliwości tych peryferiów. Np
jak zrobić wzmacniacz operacyjny z wewnetrznego komparatora.
Domyslam sie ze procek nie musi caly
czas pracowac. Robilem so takiego do radiotelefony chodzacego na baterii
slonecznej. Chodzilo o to zeby spal jak najdluzej i tylko co jakis czas
sie budzil i sprawdzal czy czegos od niego nie chca. Ale na to mialem
tajmerek z 555 ktory wysylal przerwanie co jakis czas.
WD powinien byc tylko dla bezpiecznstwa i ma robic Reset kompletny.
Regularne, okresowe robienie resetu to raczej nonsens.
ZaleĹĽy.
Przynajmniej w urzadzeniach ktore robile to nie mialoby sensu. Jak
inicjalizacja trwa 300 ms to nie moge sobie pozwalac na robienie tego
bez potrzeby.
Ale jak robisz maly programik to moze to miec jakis sens.
Jak napisałem - to szczególny przypadek.
Co do "prostych" i "skomplikowanych" programĂłw - zazwyczaj prosty
program kosztuje mnie dużo więcej wysiłku. W zasobnych procesorach
zrobienie czegokolwiek nie stanowi problemu. SÄ… szybkie, majÄ… zasoby,
duże pamięci. Nawet pisać w C i nie martwic się, że kod jest "odległy od
optymalnego" i że zabraknie pamięci. Ale zrobienie czegoś trudnego real
time na małym procesorze, gdzie wszystko jest ograniczone, a czasem
potrzebnych rzeczy nie ma, i z szacunków wynika że się nie powinno udać
- to jest dopiero wyzwanie :)
Ja robię urządzenia, które gdyby się inicjalizowały 300ms, wiele osób
straciłoby zdrowie lub nawet życie przebywając w ich pobliżu :)
A największy jaki napisałem przekracza 32k słów. Wszystko w pięknym
języku assemblera oczywiście :)
Napisales ogolnikowo wiec to znaczy wszytko i nic.
Bo to jest nieogĂłlnikowe dopiero w konkretnym przypadku.
--
Pozdrawiam,
A. Grodecki
Date: Wed, 19 Oct 2005 10:41:50 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
jerry1111 wrote:
Sebastian Bialy wrote:
To o czym piszesz to raczej odmiana mutexu (a i to nie do końca) niż
semaforu - semafory służą raczej do podziału zadań między wątki a nie
do synchronizacji 2 procesĂłw.
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
Nie jestem z zawofu specjalista od software pomimo ze to robie (z malymi
przerwami) od 30 lat.
) Nie wiem, czy uzywanie watchdoga jest dobrym pomysłem do łatania
programu :)
Program ma byc pisany i testowany bez WD. Ja WD uzywam dopiero w
finalnej wersji programu - wczesniej nie ma sensu, bo moge nie
zauwazyc ze czasami idzie wszystko w maliny.
A ktorz mowi ze WD ma program latac. Tyle ze program ktory programista
mniemal zrobic dobrze nie koniecznie przewiduje wszytkie mozliwosci
ktore moga sie zdarzyc. Poza tym jak powiedzilem maga sie zdarzac rozne
nieprzewidzane zaklocenia ktore powoduja nierawidlowy bieg programu.
WD nigdy sie nie uzywa przy uruchamianiu. Jak mozna by uruchamiac jak WD
robilby Reset jak program sie zatrzymuje na jakims Breakpoint'cie.
Pozdro
Grzechu
From: jerry1111 <nie_chce_wiecej_spamu_jerry1111_wytnij_to__at_nospam_wp.pl.cholera>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 17:06:21 +0100
Greg wrote:
A ktorz mowi ze WD ma program latac. Tyle ze program ktory programista
mniemal zrobic dobrze nie koniecznie przewiduje wszytkie mozliwosci
ktore moga sie zdarzyc.
Najgorsze co moze sie zdarzyc, to za krotki time-to-market.
Bylem swiadkiem rozmowy w pewnej firmie (nie powiem jakiej), gdzie
bylem zaproszony jako konsultant do rozwiazania pewnego problemu.
Prezes-idiota powiedzial (po uslyszeniu, ze software wymaga jeszcze
testowania) ze trzeba wstawic WD i juz. Co najsmieszniejsze tak sie
uparl, ze produkt z blednym softem poszedl do sprzedazy ;-))
Potem firma stracila duzo... oj duzo... ;-))
--
Jerry
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 19:42:46 +0200
Użytkownik jerry1111 napisał:
Najgorsze co moze sie zdarzyc, to za krotki time-to-market.
Bylem swiadkiem rozmowy w pewnej firmie (nie powiem jakiej), gdzie
bylem zaproszony jako konsultant do rozwiazania pewnego problemu.
Prezes-idiota powiedzial (po uslyszeniu, ze software wymaga jeszcze
testowania) ze trzeba wstawic WD i juz. Co najsmieszniejsze tak sie
uparl, ze produkt z blednym softem poszedl do sprzedazy ;-))
Potem firma stracila duzo... oj duzo... ;-))
Ja kiedyś napisałem na zlecenie program, który zgodnie z umową miał być
przetestowany na hardware przez zamawiającego (było to przed epoką ICSP
i sprzętowych debuggerów). Ale nikomu się tam OCZYWIŚCIE nie chciało,
sprawdzili po Ĺ‚ebkach, jeszcze mniej niĹĽ ja sam, i od razu
zaprogramowali 500 procesorów OTP i nawet zdążyli je wlutować. A ceny
tych rzeczy były wtedy relatywnie wielokrotnością obecnych... Potem się
okazało, że program ma błąd numeryczny ujawniający się w pewnym
szczególnym przypadku... Musieli kombinowac jak to sprzedać, żeby błąd
nie wyszedł u klienta za szybko...
--
Pozdrawiam,
A. Grodecki
Date: Wed, 19 Oct 2005 15:47:30 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
...(było to przed epoką ICSP i sprzętowych debuggerów).
Byla taka epoka ?
Odkad istnieja mikroprocesory o chyba niedlugo potem zaistnialy ICE (In
Circuit Emulator).
Do microcontrolerow zdaje sie od samego poczatku producenci proponowali
takie rzeczy.
Nie bylo to tanie wiec moze niektorzy probowali dlubac bez tego.
We wczesnych latach 80 uzywalem takowych osobiscie.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 22:32:30 +0200
Użytkownik Greg napisał:
...(było to przed epoką ICSP i sprzętowych debuggerów).
Byla taka epoka ?
Powinienem napisać "ogólnodostępnych" :)
Kilka tysięcy złotych to były wtedy bardzo konkretne pieniądze.
--
Pozdrawiam,
A. Grodecki
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 18:26:47 +0200
Greg przemówił ludzkim głosem:
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
NajkrĂłcej mowiÄ…c semafor binarny :-)
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 19:45:37 +0200
Użytkownik Zbych napisał:
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
NajkrĂłcej mowiÄ…c semafor binarny :-)
Elokwencja podstawÄ… projektu ;)
To dobrze, że wiem jak to się nazywa, bo oczywiście bez tej wiedzy nijak
się nie da użyć... :)
--
Pozdrawiam,
A. Grodecki
Date: Wed, 19 Oct 2005 15:42:57 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
Użytkownik Zbych napisał:
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
NajkrĂłcej mowiÄ…c semafor binarny :-)
A skad sie taka nazwa wziela. Ze to niby "mutacja exportowa"
Przy okazji niech moze mi kto powie skad nazwa imbus sie wziela uzywalem
klucze heksagonalne (w Polsce w latach 70-tych) jak jeszcze niektorzy z
grupowiczow sikali w pieluszki i uzywam tego dalej i dopiero niedawno
dowiedzilem sie ze w Polsce sie tak na to mowi, bo w Ameryce to sie to
nazywa klucz Allena.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 21:50:07 +0200
Greg przemówił ludzkim głosem:
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
NajkrĂłcej mowiÄ…c semafor binarny :-)
A skad sie taka nazwa wziela. Ze to niby "mutacja exportowa"
mutex to skrĂłt od mutual exclusion.
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Wed, 19 Oct 2005 22:41:55 +0200
Greg wrote:
Szczerze mowiac to nie wiem co to jest mutex, moglby ktos odkryc te
tajemnice.
Nazwe już koledzy wyjaśnili a praktyka jest taka:
a) Mutex - do ochorny zasobu krytycznego - tylko jeden proces może zająć
mutex, pozostałe muszą albo się zawiesić w oczekiwaniu na zwolnienie
blokady, albo zapytać za chwile.
Operacja "sprawdz czy wolny i jesli wolny to zablokuj" musi być
atomowa. Zdaje mi siÄ™ ze niektĂłre CPU majÄ… nawet do tego specjalne
instrukcji "check and write". Jak nie majÄ… to nalezy blokowac przerwania
(a nawet równoległośc, jesli taka jest).
Przykład: dwa procesy chcą zapisac rejestr dwubajtowy. Wtedy dorzuca się
mutex kontrolujący ten proces. Zapewnie on, że operacja pomiędzy blokadą
mutexu i zwolnieniem będzie atomowa.
b) Semafor - do podziału zadań miedzy wiele wątków wykonawczych. Semafor
można podnieć np. 4 razy i w ten sposób obudzić 4 watki do wykonania zadań.
Przykład: N procesorów równoległych oczekuje na zadania do wykonania od
procesora głównego. Albo wątków czy procesów.
Twoja koncepcja flagi binarnej jest z definicji atomowa. BliĹĽej jej
jednak do mutexu niĹĽ semafora. Ale nie jest ani jednym ani drugim, bo
obydwa mechanizmy sa silnie wspierane przez system operacyjny (ktĂłry
zawiesza wÄ…tek podczas czekania na semafor). A u Ciebie "wÄ…tki" aktywnie
oczekujÄ… na jej zmianÄ™.
IMHO sporadyczne sa sytuacje, kiedy semafor albo mutex da się zrobić bez
zawieszania przerwań. A już raczej nie na AVR.
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Wy?±czanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 01:25:17 +0200
On Wed, 19 Oct 2005 22:41:55 +0200, Sebastian Bialy wrote:
Nazwe już koledzy wyja¶nili a praktyka jest taka:
a) Mutex - do ochorny zasobu krytycznego - tylko jeden proces może zaj±ć
mutex, pozostałe musz± albo się zawiesić w oczekiwaniu na zwolnienie
blokady, albo zapytać za chwile.
Operacja "sprawdz czy wolny i jesli wolny to zablokuj" musi być
atomowa. Zdaje mi się ze niektóre CPU maj± nawet do tego specjalne
instrukcji "check and write". Jak nie maj± to nalezy blokowac przerwania
(a nawet równoległo¶c, jesli taka jest).
A w dzisiejszych czasach to jeszcze bardziej skomplikowane, jak sie
okaze ze procesorow kilka a pamiec cachowana.
b) Semafor - do podziału zadań miedzy wiele w±tków wykonawczych. Semafor
można podnieć np. 4 razy i w ten sposób obudzić 4 watki do wykonania zadań.
Przykład: N procesorów równoległych oczekuje na zadania do wykonania od
procesora głównego. Albo w±tków czy procesów.
Hm .. za moich czasow to ten "mutex" nazywal sie jednak semaforem..
Bo wlasnie semafor sluzy do blokowania wejscia do sekcji krytycznej.
A w szczegolnym przypadku mozna faktycznie podniesc kilka razy
i wpuscic kilka, ale nie wiecej, procesow.
Do zwalniania watkow ... hm, za pozno zeby myslec, moze i sie tez
nadaje ..
Przy czym realizacja semafora tez wymaga podobnych zabiegow.
IMHO sporadyczne sa sytuacje, kiedy semafor albo mutex da się zrobić bez
zawieszania przerwań. A już raczej nie na AVR.
Dokladnie. Najprosciej zawiesic przerwania na ten krotki moment.
J.
From: "William" <nie_at_nospam_ma.mnie.pl>
Subject: Re: Wy?±czanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 08:27:58 +0200
atomowa. Zdaje mi się ze niektóre CPU maj± nawet do tego specjalne
instrukcji "check and write". Jak nie maj± to nalezy blokowac przerwania
(a nawet równoległo¶c, jesli taka jest).
A w dzisiejszych czasach to jeszcze bardziej skomplikowane, jak sie
okaze ze procesorow kilka a pamiec cachowana.
Wówczas i tak nie korzystaj± z cache tylko z pamięci systemowej. Tak ma
na pewno Intel 386 i poĽniejsze. Po to jest specjalny rozkaz, żeby nie mieć
wła¶nie problemów z cache / wielow±tkowo¶ci± w rdzeniu itp.
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?ISO-8859-2?Q?Wy=3F=B1czanie_przerwa=3F_=27na_chwil=3F?=
Date: Thu, 20 Oct 2005 10:05:13 +0200
J.F. wrote:
b) Semafor - do podziału zadań miedzy wiele w±tków wykonawczych. Semafor
można podnieć np. 4 razy i w ten sposób obudzić 4 watki do wykonania zadań.
Przykład: N procesorów równoległych oczekuje na zadania do wykonania od
procesora głównego. Albo w±tków czy procesów.
Hm .. za moich czasow to ten "mutex" nazywal sie jednak semaforem..
Bo wlasnie semafor sluzy do blokowania wejscia do sekcji krytycznej.
A w szczegolnym przypadku mozna faktycznie podniesc kilka razy
i wpuscic kilka, ale nie wiecej, procesow.
Do zwalniania watkow ... hm, za pozno zeby myslec, moze i sie tez
nadaje ..
Zerknij do unixowej biblioteki pthreads dostępnej również w windowsie.
Jest to do¶c dokładnie opisane. W ogólno¶ci mutex uniemożliwia dostęp
więcej niż jednemu, a semafor pozwala "wpu¶cić po kolei" odpowiedni±
liczbę w±tków.
Oczywi¶cie maj±c mutex można zrobić semafor i odwrotnie, ale sa to na
tyle różne podej¶cia do sprawy, że zdecydowano się na osobne funkcje.
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Wy?ączanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 11:36:49 +0200
On Thu, 20 Oct 2005 10:05:13 +0200, Sebastian Bialy wrote:
J.F. wrote:
Hm .. za moich czasow to ten "mutex" nazywal sie jednak semaforem..
Bo wlasnie semafor sluzy do blokowania wejscia do sekcji krytycznej.
A w szczegolnym przypadku mozna faktycznie podniesc kilka razy
i wpuscic kilka, ale nie wiecej, procesow.
Do zwalniania watkow ... hm, za pozno zeby myslec, moze i sie tez
nadaje ..
Zerknij do unixowej biblioteki pthreads dostępnej również w windowsie.
Jest to do¶c dokładnie opisane. W ogólno¶ci mutex uniemożliwia dostęp
więcej niż jednemu, a semafor pozwala "wpu¶cić po kolei" odpowiedni±
liczbę w±tków.
Oczywi¶cie maj±c mutex można zrobić semafor i odwrotnie, ale sa to na
tyle różne podej¶cia do sprawy, że zdecydowano się na osobne funkcje.
A bylo tak od razu.
W takiej ogolnej postaci [kto to wymyslil - Dijkstra ?] to semafor jak
najbardziej nadaje sie do do wpuszczania jednego procesu. Kwestia
tylko wartosci poczatkowej. Zreszta od tego nazwa pochodzi -
wpuszczanie pociagow na jeden tor.
Moze wpuszczac i kilka, w implementacji Dijkstry [?] roznica
praktycznie zadna. Czy kiedykolwiek byla wykorzystywana praktycznie ..
dobre pytanie.
Po przemysleniu - nie bardzo widze zastosowania do zwalniania
procesow, np obslugujacych costam, tak jak to sugerowales.
W Unixie semafory [systemowe] sa:
-bardzo rozbudowane, czesto niepotrzebnie
-generalnie: na poziomie procesow a nie watkow.
Dla watkow trzeba bylo wymyslec cos innego.
J.
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?ISO-8859-2?Q?Wy=3F=B9czanie_przerwa=3F_=27na_chwil=3F?=
Date: Thu, 20 Oct 2005 11:49:13 +0200
J.F. wrote:
Moze wpuszczac i kilka, w implementacji Dijkstry [?] roznica
praktycznie zadna. Czy kiedykolwiek byla wykorzystywana praktycznie ..
dobre pytanie.
Po przemysleniu - nie bardzo widze zastosowania do zwalniania
procesow, np obslugujacych costam, tak jak to sugerowales.
Ależ ja stosuje to wyj±tkowo powszechnie :) Prosty przykład:
Strona główna wyszukiwarki. Wpisujesz hasło i główny w±tek wyszukiwarki
podnosi semafor [*] o jeden. Jeden z 1000 wolnych w±tków wyszukuj±cych
który wła¶nie stoi w kolejce zostaje obudzony i zabiera się za szukanie.
Pozostałem w±tki z tych 1000 s± albo w stanie szukania, albo w stanie
czekania na zlecenie.
Masz relację jeden nadzorca tysi±c robotników i jedno biurko.
Bardzo fajne, jesli masz maszynke wieloprocesorow±/wielordzeniow±.
Nie wiem jak można by to zrezliwoać zgrabnie na jednym mutexie.
W Unixie semafory [systemowe] sa:
-bardzo rozbudowane, czesto niepotrzebnie
4 funkcje raptem może :)
-generalnie: na poziomie procesow a nie watkow.
Ojoj, nie tak szybko. Poczytaj o semaforach w Linuxie, pojęcie proces a
w±tek mocno się im rozmyło.
Dla watkow trzeba bylo wymyslec cos innego.
Dlaczego dla w±tków co¶ innego ? Wszak własnie to w±tek ma możliwo¶ć w
grzebaniu w pamięci sasiada i przez to możliwo¶ć używania semaforów. W
przypadku prcesu to jest zasadniczo utrudnione ze względu na brak
wspólnej pamięci (acz zalezy od implementacji, np. na Amidze procesy nie
miały oddzielonej pamięci ...).
[*] Może też opuszczać, zależy od szkoły ...
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Wy?šczanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 15:32:56 +0200
On Thu, 20 Oct 2005 11:49:13 +0200, Sebastian Bialy wrote:
J.F. wrote:
Po przemysleniu - nie bardzo widze zastosowania do zwalniania
procesow, np obslugujacych costam, tak jak to sugerowales.
Ależ ja stosuje to wyj±tkowo powszechnie :) Prosty przykład:
Strona główna wyszukiwarki. Wpisujesz hasło i główny w±tek wyszukiwarki
podnosi semafor [*] o jeden. Jeden z 1000 wolnych w±tków wyszukuj±cych
który wła¶nie stoi w kolejce zostaje obudzony i zabiera się za szukanie.
Pozostałem w±tki z tych 1000 s± albo w stanie szukania, albo w stanie
czekania na zlecenie.
Tylko ze:
- nie przekazuje to danych do watkow/procesow,
- przyjdzie przerwanie zaraz po podniesieniu semafora -
watki sie pogryza przy dostepie do danych przekazanych
innymi sposobami - trzeba to zabezpieczac dodatkowo.
- wpisujemy 1001 haslo, operacja podniesienia sie udala,
glowny watek nic nie wie ze zaden proces nie wystartowal.
Naprawde - sa znacznie lepiej nadajace sie do tego zadania
mechanizmy.
Przemyslalem ! :-)
W Unixie semafory [systemowe] sa:
-bardzo rozbudowane, czesto niepotrzebnie
4 funkcje raptem może :)
Ale jaka mnogosc parametrow :-)
-generalnie: na poziomie procesow a nie watkow.
Ojoj, nie tak szybko. Poczytaj o semaforach w Linuxie, pojęcie proces a
w±tek mocno się im rozmyło.
Owszem - watki maja swoje semafory, ale generalnie co U*X to
inne podejscie do problemu watkow.
Dla watkow trzeba bylo wymyslec cos innego.
Dlaczego dla w±tków co¶ innego ? Wszak własnie to w±tek ma możliwo¶ć w
grzebaniu w pamięci sasiada i przez to możliwo¶ć używania semaforów.
No i o to chodzi - czesto nie mozesz uzyc tego "miedzyprocesowego",
bo ci zatrzyma proces wraz ze wszystkimi jego watkami i na tym sie
skonczy.
J.
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?UTF-8?B?V3k/77+9Y3phbmllIHByemVyd2E/ICduYSBjaHdpbD8n?=
Date: Thu, 20 Oct 2005 20:34:50 +0200
J.F. wrote:
- nie przekazuje to danych do watkow/procesow,
Nawet lepiej, diabli wiedzą jak ja sobie to obmyśalem i systemowi nic do
tego.
- przyjdzie przerwanie zaraz po podniesieniu semafora -
watki sie pogryza przy dostepie do danych przekazanych
innymi sposobami - trzeba to zabezpieczac dodatkowo.
Nie rozumiem "przerwanie" - podniesienie semafora wpuszacza jakiĹ› watek
do roboty - jesli chcesz mu przekazać jakieś dane to np., blokujesz
kolejkÄ™ danych mutexem, pobierasz sobie i odblokowujesz. Nie ma prawa
być problemu. Ten problem jest skomplikowany tylko pozornie. Uzywasz
mechanizmu zlecania roboty (semafor) i mechanizmu kontroli kolejki
zleceń (mutex). Nic prostszego.
- wpisujemy 1001 haslo, operacja podniesienia sie udala,
glowny watek nic nie wie ze zaden proces nie wystartowal.
No to co, wstawił do kolejki to jak jakiś się zwolni od razu weźmie robotę.
Semafory nic nie robiÄ… w sprawie przekazywania danych. Ich zadaniem jest
tylko umożliwienie wątkom pracowników możliwośc "zawieszania"
wykonywania i automatycznego ich budzenia. O parametrach nie ma mowy.
Naprawde - sa znacznie lepiej nadajace sie do tego zadania
mechanizmy.
A jakie :) ?
W Unixie semafory [systemowe] sa:
-bardzo rozbudowane, czesto niepotrzebnie
4 funkcje raptem moĹĽe :)
Ale jaka mnogosc parametrow :-)
O a to ciekawe. Np. mutex:
http://www.cs.nmsu.edu/~jcook/Tools/pthreads/library.html
albo semafor:
http://www.cs.cf.ac.uk/Dave/C/node26.html#SECTION002640000000000000000
obydwa z pthread, nie uĹĽywam innych bibliotek.
Nie wiem czy można prościej, choć ja to obudowałem akurat klasą sobie.
Dlaczego dla wątków coś innego ? Wszak własnie to wątek ma możliwość w
grzebaniu w pamięci sasiada i przez to możliwość używania semaforów.
No i o to chodzi - czesto nie mozesz uzyc tego "miedzyprocesowego",
bo ci zatrzyma proces wraz ze wszystkimi jego watkami i na tym sie
skonczy.
Na procesy sa inne techniki komunikacji (choćby sockety/rurki). W
przypadku wÄ…tkĂłw nie ma chyba nic szybszego niĹĽ prosty semafor i mutex.
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Wy??czanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 22:33:19 +0200
On Thu, 20 Oct 2005 20:34:50 +0200, Sebastian Bialy wrote:
J.F. wrote:
- przyjdzie przerwanie zaraz po podniesieniu semafora -
watki sie pogryza przy dostepie do danych przekazanych
innymi sposobami - trzeba to zabezpieczac dodatkowo.
Nie rozumiem "przerwanie" - podniesienie semafora wpuszacza jaki¶ watek
do roboty - jesli chcesz mu przekazać jakie¶ dane to np., blokujesz
kolejkę danych mutexem, pobierasz sobie i odblokowujesz. Nie ma prawa
być problemu.
Oczywiscie, ale tez semafor niewiele upraszcza - zalatwia tylko
minimalna czesc problemu.
Naprawde - sa znacznie lepiej nadajace sie do tego zadania
mechanizmy.
A jakie :) ?
Message, sockety, pipe ?
W Unixie semafory [systemowe] sa:
-bardzo rozbudowane, czesto niepotrzebnie
4 funkcje raptem może :)
Ale jaka mnogosc parametrow :-)
O a to ciekawe. Np. mutex:
http://www.cs.nmsu.edu/~jcook/Tools/pthreads/library.html
albo semafor:
http://www.cs.cf.ac.uk/Dave/C/node26.html#SECTION002640000000000000000
obydwa z pthread, nie używam innych bibliotek.
I o to chodzi - zapominasz o sys/sem.h.
To sa "prawdziwe" "unixowe" semafory [IPC].
Na procesy sa inne techniki komunikacji (choćby sockety/rurki). W
przypadku w±tków nie ma chyba nic szybszego niż prosty semafor i mutex.
Ale to trzeba bylo pisac ze ograniczasz sie do kontekstu pthread :-)
J.
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: Wy??czanie przerwa? 'na chwil?'
Date: Thu, 20 Oct 2005 23:01:18 +0200
J.F. wrote:
Message, sockety, pipe ?
Spory narzut ze storny oprogamowania. Taki socket i przesłanie 1 bajta
to tragicznie dużo roboty. Taki mutex/semafor czesto kompiluje się do
kilku instrukcji. Z reszt± jak zrobić to co opisałem socketami ? Masa
roboty ;) Sockety sa ¶wietne, ale nie do tego ...
I o to chodzi - zapominasz o sys/sem.h.
To sa "prawdziwe" "unixowe" semafory [IPC].
E tam prawdziwe. pthreads sa prostackie i w zasadzie nie trzeba wiele
wiedzieć zeby z nich skorzystać. A o prawdziwo¶ci mozna sobie
podyskutowac na advocacy ;) Ważne jest jak szybko się da napisac program ...
Na procesy sa inne techniki komunikacji (choćby sockety/rurki). W
przypadku w±tków nie ma chyba nic szybszego niż prosty semafor i mutex.
Ale to trzeba bylo pisac ze ograniczasz sie do kontekstu pthread :-)
Ehhh nie tylko do pthreads, ale do tej filozofii - proste semafory i
mutexy. Cało¶ć automatyki zawiera się w systemie i dostajesz pare
wygodnych i poręczych funkcji.
From: Tom <tom_at_nospam_nospam.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 08:16:43 +1000
Greg wrote:
WD nigdy sie nie uzywa przy uruchamianiu. Jak mozna by uruchamiac jak WD
robilby Reset jak program sie zatrzymuje na jakims Breakpoint'cie.
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli taka
sytuacje i mozna zatrzymywac program z aktywnym WD.
Tomek
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 01:19:30 +0200
Użytkownik Tom napisał:
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli taka
sytuacje i mozna zatrzymywac program z aktywnym WD.
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
--
Pozdrawiam,
A. Grodecki
From: jerry1111 <nie_chce_wiecej_spamu_jerry1111_wytnij_to__at_nospam_wp.pl.cholera>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 09:58:46 +0100
A.Grodecki wrote:
Użytkownik Tom napisał:
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli
taka sytuacje i mozna zatrzymywac program z aktywnym WD.
Ciekawe jacy? Daj przyklad, bo mi sie nic nie kojarzy.
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego co
procek.
--
Jerry
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 14:34:08 +0200
Użytkownik jerry1111 napisał:
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego co
procek.
Nie mam tego problemu, w PIC wd mają własne oscylatory.
--
Pozdrawiam,
A. Grodecki
From: jerry1111 <nie_chce_wiecej_spamu_jerry1111_wytnij_to__at_nospam_wp.pl.cholera>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Fri, 21 Oct 2005 10:10:25 +0100
A.Grodecki wrote:
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego co
procek.
Nie mam tego problemu, w PIC wd mają własne oscylatory.
A ja czasami mam - bo roznych prockow od cholery uzywam. Juz nie
pamietam w jakim procku zegar do WD byl zza pll ;-)
--
Jerry
Date: Thu, 20 Oct 2005 14:58:23 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
jerry1111 wrote:
A.Grodecki wrote:
Użytkownik Tom napisał:
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli
taka sytuacje i mozna zatrzymywac program z aktywnym WD.
Ciekawe jacy? Daj przyklad, bo mi sie nic nie kojarzy.
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego co
procek.
Znam taki sprytny patent zeby to obejsc. Ladujesz przez diode
kondensator z oscylatora glownego, wprost z kwarcu przez oporniczek..
Przy braku oscylacji kondensator sie rozladuje i zrobi reset.
Mysle ze sprawa jasna bez podawania szczegolowego schematu.
Uklad byl stosowana i dziala fajnie z wieloma prockami
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 21:50:11 +0200
Użytkownik Greg napisał:
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego co
procek.
Znam taki sprytny patent zeby to obejsc. Ladujesz przez diode
kondensator z oscylatora glownego, wprost z kwarcu przez oporniczek..
Przy braku oscylacji kondensator sie rozladuje i zrobi reset.
Mysle ze sprawa jasna bez podawania szczegolowego schematu.
Uklad byl stosowana i dziala fajnie z wieloma prockami
Ale jesteĹ› pewien, ĹĽe jego istnienie cokolwiek daje?
Żeby zatrzymać główny zegar, trzeba się BARDZO wysilić (o ile taka
mozliwośc istnieje - nie w najprostszych procesorkach) i wykonać CELOWO
specjalnÄ… instrukcjÄ™. A wtedy przecieĹĽ raczej nie chcemy, ĹĽeby sam siÄ™
włączył bez kontroli???
Jesli zegar gaśnie sam z siebie, to niby dlaczego reset miałby w
czymkolwiek pomóc. Zegar gaśnie jeśli jest wada w układzie generatora,
albo procesor jest walnięty.
I na koniec - wdogi w procesorach godnych stosowania są napędzane
niezależnymi oscylatorami wewnętrznymi.
--
Pozdrawiam,
A. Grodecki
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 21:59:56 +0200
A.Grodecki przemówił ludzkim głosem:
Jesli zegar gaśnie sam z siebie, to niby dlaczego reset miałby w
czymkolwiek pomóc. Zegar gaśnie jeśli jest wada w układzie generatora,
albo procesor jest walnięty.
Gdyby było tak jak mowisz, to uC nie wyposażanoby w układy nadzorujące
oscylator. Podpowiem ci, ĹĽe rozwiÄ…zania takie stosuje takĹĽe producent
twoich ulubionych procesorĂłw :-)
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Thu, 20 Oct 2005 22:50:55 +0200
Użytkownik Zbych napisał:
Jesli zegar gaśnie sam z siebie, to niby dlaczego reset miałby w
czymkolwiek pomóc. Zegar gaśnie jeśli jest wada w układzie generatora,
albo procesor jest walnięty.
Gdyby było tak jak mowisz, to uC nie wyposażanoby w układy nadzorujące
oscylator. Podpowiem ci, ĹĽe rozwiÄ…zania takie stosuje takĹĽe producent
twoich ulubionych procesorĂłw :-)
Wiem, aczkolwiek nie wiem po co. Sam nigdy nie stwierdziłem takiej
sytuacji i utrzymujÄ™, ĹĽe reset nie rozwiÄ…zuje sprawy. Tak samo jak
wewnętrzny brown-out nie jest całkowicie skuteczny. Są to dodatkowe
gadżety poprawiające bezpieczeństwo, ale nie zapewniające go.
--
Pozdrawiam,
A. Grodecki
From: jerry1111 <nie_chce_wiecej_spamu_jerry1111_wytnij_to__at_nospam_wp.pl.cholera>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Fri, 21 Oct 2005 10:13:48 +0100
A.Grodecki wrote:
Wiem, aczkolwiek nie wiem po co. Sam nigdy nie stwierdziłem takiej
sytuacji
A ja tak mialem. Najgorszy problem byl ze wzbudzaniem sie kwarcow
na mrozie. Jak juz wystartowal, to tylko czasami stawal.
Aha - wszystkie elementy na -40 stopni byly (oprocz pieprzonego kwarcu...)
i utrzymujÄ™, ĹĽe reset nie rozwiÄ…zuje sprawy.
Siedzial zewnetrzny timer na 555. Jak procesor go nie zablokowal (a to
znaczylo ze pracuje), to 10x na sekunde odlaczal zasilanie.
Tak samo jak
wewnętrzny brown-out nie jest całkowicie skuteczny. Są to dodatkowe
gadżety poprawiające bezpieczeństwo, ale nie zapewniające go.
--
Jerry
Date: Fri, 21 Oct 2005 19:16:53 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
Użytkownik Greg napisał:
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
A bo to mniej wiecej tak, jak z zasilaniem WD z zegara tego samego
co procek.
Znam taki sprytny patent zeby to obejsc. Ladujesz przez diode
kondensator z oscylatora glownego, wprost z kwarcu przez oporniczek..
Przy braku oscylacji kondensator sie rozladuje i zrobi reset.
Mysle ze sprawa jasna bez podawania szczegolowego schematu.
Uklad byl stosowana i dziala fajnie z wieloma prockami
Ale jesteĹ› pewien, ĹĽe jego istnienie cokolwiek daje?
Żeby zatrzymać główny zegar, trzeba się BARDZO wysilić (o ile taka
mozliwośc istnieje - nie w najprostszych procesorkach) i wykonać
CELOWO specjalnÄ… instrukcjÄ™. A wtedy przecieĹĽ raczej nie chcemy, ĹĽeby
sam się włączył bez kontroli???
Jesli zegar gaśnie sam z siebie, to niby dlaczego reset miałby w
czymkolwiek pomóc. Zegar gaśnie jeśli jest wada w układzie generatora,
albo procesor jest walnięty.
I na koniec - wdogi w procesorach godnych stosowania są napędzane
niezależnymi oscylatorami wewnętrznymi.
Konkretny przypadek kiedy to jest porzebne.
Pracowalem w firmie ktora kobila elektronike do systemow
klimatyzacyjnych. Poniewaz od czasu do czasu wlacza sie duzej mocy
wentylator lub grzjnik, ponadto maszyny przmyslowe w okolicy powodowaly
od czasu do czasu takie zakorkowanie prockow w termostatach i innych
modulach ze chlopcy (moi porzednicy) wymyslili to rozwiazanie.
Pozwalalo to na bezpieczne usywanie Watch Doga wewnetrznego. Zeewnetrzy
zawsze jest pewniejczy moznaby powiedziec.
Niestety w tym przypadku koszt i wymiary byly krytyczne. Ponadto w
produkci masowej niespecjalnie lubi sie uklady produkowane przez jednego
producenta. Wtedy chipy Dallasa nie mialyl jeszcze swoich podrobek.
From: Tom <ttp_at_nospam_nospam.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Fri, 21 Oct 2005 07:41:32 +1000
jerry1111 wrote:
A.Grodecki wrote:
Użytkownik Tom napisał:
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli
taka sytuacje i mozna zatrzymywac program z aktywnym WD.
Ciekawe jacy? Daj przyklad, bo mi sie nic nie kojarzy.
Motorola HC12
To znaczy ĹĽe jest sposĂłb na zawieszenie WD - do bani!
Mozna to wylaczyc w wersji produkcyjnej
Tomek
Date: Thu, 20 Oct 2005 14:53:23 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Tom wrote:
Greg wrote:
WD nigdy sie nie uzywa przy uruchamianiu. Jak mozna by uruchamiac jak
WD robilby Reset jak program sie zatrzymuje na jakims Breakpoint'cie.
Niekoniecznie, niektorzy (a moze wszyscy?) producenci przewidzieli
taka sytuacje i mozna zatrzymywac program z aktywnym WD.
Nie rozsmieszaj mnie. Taki Watch Dog to co on wart.
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: =?ISO-8859-1?Q?Wy=B3=B1czanie_przerwa=F1_=27na_chwil=EA?=
Date: Tue, 18 Oct 2005 20:00:27 +0200
No niekoniecznie. Prosty przyklad - odczytujesz na 8-bitowcu zmienna
wielobajtowa, ktorej zawartosc jest modyfikowana w procedurze obslugi
przerwan. Jesli nie zablokujesz przerwan na czas odczytu calej
zmiennej grozi ci, ze odczytasz smieci (jesli pomiedzy odczytami
wystapilo przerwanie modyfikujace wartosc zmiennej). A to tylko
pierwszy z brzegu przyklad.
O tylen wstrzymywanie przerwn nie jest konieczne ze normalnie program
obslugi przerwan powinien ustawiac odpowiednie semafory kture tez sam
potem sprawdza. Jak ma zapisywac ta liczbe to musi wiedziec ze w tym
momencie nie jest ona czytana.
Ale przeciez to jest bez sensu. Na 32-bitowym procku, przy dostepie do
jakis poteznych struktur danych mozna sie bawic w semafory, ale nie na
malym AVR, gdzie kazdy bajt jest cenny, szczegolnie przy odczycie
zmiennej typu np. WORD.
Zreszta w niektorych przypadkach (np. odczyt/zapis EEPROM) sama
architektura AVR narzuca istnienie takich sekcji krytycznych.
Zewnetrzne WD tez chyba bazuja na sygnale RESET, bo zglaszanie
prockowi przerwania z sugestia "cos ci sie stary poknocilo, wiec sie
zresetuj" byloby chyba nie na miejscu;P
To widze ze nie uzywales takowego kolego. Jet odwrotnie. Procek musi
periodycznie podac do WD sygnal, impuls ze ciagle jest zywy. Jak nie
poda tego sygnalu przez sekunde to znaczy ze sie gdzies zapedzil w
martwy punkt i nalezy go resetowac.
Kawalek programu ktory daje kpniaga do WD powinien byc wsadzony w takim
miejscu w programie przez kture musi przechodzic regularnie zazwyczaj w
glownej petli (Main Loop) systemu. Ludzie robia blad wsadajac to w
wielu miejscach Czasem to sie wydaje konieczne ale nie powinno miec
miejsca. Wtedy pogram zapetlony jakiejs "bocznej petli" moze dawac
sygnal ze jest w porzadku podczas gdy w rzeczywistosci nie jest.
No ok, ale co to zmienia? Istnienie sekcji programu, ktore wymagaja
wylaczenia przerwan nic nie zmienia. Przeciez to nie sa sekcje, ktore
wykonuja sie 1 sekunde, tylko kilkuinstrukcjowe fragmenty, jak wiec maja
one wplynac na WD?
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze
rowniez powszechnie daje to fatalne rezultaty.
Przyklad prosze?
Tu chodzi glownie o to ze pogram moze sie zapetlic i nie zreaktywowac
przerwan. Wiem. Powiesz ze jak dobrze napisany to sie nie zapetli. Ale
to nie zawsze ma miejsce (dobre napisanie) a poza tym program sie
zapetla w z powodu zaklocen i to znacznie czesciej niz niektorzy mysla.
Mam z tym troche praktyke i dlatego to mowie.
No ale jesli sie zapetli to WD go zresetuje, co to ma wspolnego z
przerwaniami? Zreszta jesli sie zapetli to pewnie dlatego, ze poszedl w
maliny, co ci wiec zagwarantuje, ze w miedzyczasie nie wykona jakiejs
przypadkowej instrukcji CLI?
Glownym jednak problemem jest wlasnie to ze najpierw sie mysli ze
zatrzymuje przerwania na malenka chwilke a potem ktos inny modyfikuje
program i ta chwilka sie robi troche wieksza. No i czasem dochodzi do
problemu z przeoczonymi przerwaniami.
No ale to nie jest argument. Kazdy program mozna zle napisac.
Ja tylko pokazuje, ze jakkolwiek trzeba uwazac to jednak istnienie
takich sekcji jest konieczne (vide przyklad z EEPROM, czytania
wielobajtowych zmiennych, czy np. zmiana kontekstu procesora w systemach
z implementacja wielowatkowosci). W tych przypadkach w architekturze AVR
po prostu nie da sie tego zrobic inaczej zachowujac efektywnosc kodu.
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
Date: Tue, 18 Oct 2005 19:01:38 +0200
Użytkownik Greg napisał:
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie obslugi
przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne. A
poza tym normalnie uklady z mikrokontrolerem powiny miec WatchDog jesli
jest o cos wbudowane w procek to czasem unieszkodliwiasz i to tez.
Jjesli zewnetrzny to ryzykujesz ze zadziala w nieodpowiednim momencie.
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze rowniez
powszechnie daje to fatalne rezultaty.
Stek bzdur.
--
Pozdrawiam,
A. Grodecki
Date: Tue, 18 Oct 2005 13:18:07 -0400
From: Greg <greg_at_nospam_somewhere.net>
Subject: Re: =?UTF-8?B?V3nCs8KxY3phbmllIHByemVyd2HDsSAnbmEgY2h3aWzDqic=?=
A.Grodecki wrote:
Użytkownik Greg napisał:
Wylaczanie obslugi przerwan sie robi normalnie tylko w programie
obslugi przerwan (samo sie robi) albo przy inicjacji systemu.
Wszelkie inne zatrzymywanie rpzerwan jest potencjalnie niebezpieczne.
A poza tym normalnie uklady z mikrokontrolerem powiny miec WatchDog
jesli jest o cos wbudowane w procek to czasem unieszkodliwiasz i to
tez. Jjesli zewnetrzny to ryzykujesz ze zadziala w nieodpowiednim
momencie.
Wiem ze mimo to te rzeczy sie praktykuje powszechnie ale wiem ze
rowniez powszechnie daje to fatalne rezultaty.
Stek bzdur.
To sie nazywa rzeczowa dyskusja