Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Wiele wątków a jedno Arduino

Factisek 31 Dec 2017 02:02 4743 115
SterControl
  • #31
    oloam
    Level 22  
    es2 wrote:
    W jaki sposób wyłączasz przerwanie po wyjściu z niego?

    Naprawde? Musze czytac przez ciebie datasheet od atmegi. Ostatnie instrukcja w przerwaniu to ustawienie 0 w EIMSK .
    Sorry, nie zrozum mnie zle ale takie rzeczy to mozemy popisac sobie na pw a nie w tym temacie. Autor dostal kilka rozwiazan a dywagowanie nad teoretycznymi nie ma sensu.

    es2 wrote:
    Jak rozwiążesz ten problem to masz drugi, zwiazany z kolejnym zapalaniem led, czujnik ma zapalac kilka led w jakis tam odstępach czasowych.

    Ale gdzie tu problem?

    Po raz ostatni, nie bede juz pisal odpowiedzi na takie proste podstawowe rzeczy.
  • SterControl
  • #32
    es2
    Level 16  
    Nie chcesz pisać to nie. W każdym razie, twój program, w przerwach pomiędzy przerwaniami gdy będzie ono aktywne, będzie wykonywał pętle główną.

    Autor chce, aby po uaktywnieniu czujnika, pojawiła się fala led. Ja zaprzęgnę do tego przerwanie od timera, ty penie też. U mnie po wystąpieniu zbocza, ustawie flage, przertwania od timera zrobia fale swiatła.
    Reagujesz na poziom,. Wchodzisz w IRQ, ustawiasz flagę dla przerwań timera, wychodzisz z IRQ, blokujesz przerwania od czujników (wszystkich). Cos tam robisz w pęli głównej, timery robia falę, w petli głównej nic nie było do roboty wiec szybko ustawisz przerwania od czujników, które natychmiast sie wykona. W przerwaniu ustawisz flage dla timera aby generował falę. IRQ od timera zacznie generowac flage od poczatku. Czyli dopóki czujnik wystawia poziom aktywny, timery generuja pierwszy element fali.


    Pokaż mi normalny program, który czasem , łaskawie pozwala petli głównej działać.
    A co sie stanie jak linia od jednego z czujników, uszkodzi sie i bedzie miała zwarcie? W moim programie raz zrobi sie fala (raz) reszta działa normalnie. W twoim w nieskończoność bedzie wykonywało sie przerwanie naprzemiennie z jednym obiegiem petli głównej, i cały czas bedzie pierwsza faza fali, w konsekwencji diody cały czas beda sie świecić.


    Nie wiem jak ocenia twoje rozwiązanie inni, ale u mnie za taki algorytm oblałbyś egzamin.
  • #33
    oloam
    Level 22  
    es2 wrote:
    Pokaż mi normalny program, który czasem , łaskawie pozwala petli głównej działać.
    A co sie stanie jak linia od jednego z czujników, uszkodzi sie i bedzie miała zwarcie? W moim programie raz zrobi sie fala reszta działa normalnie. W twoim w nieskończoność bedzie wykonywało sie przerwanie naprzemiennie z jednym obiegiem petli głównej, i cały czas bedzie pierwsza faza fali, w konsekwencji diody cały czas beda sie świecić.

    Musze jeszcze odpowiedziec na ta zaczepke. Chyba lepiej przy awarii jak diody beda sie caly czas swiecic (wtedy latwiej znalezc usterke), niz czujnik ma nie dzialac i np w nocy nie zapalac swiatla. Nie wspomne ze przy twoim rozwiazaniu jak ktos stanie na tyle dlugo przed czujnikiem (np wda sie w rozmowe) zeby zakonczyc cykl swiecenia , to swiatlo zgasnie ...
    Co do programu - przeciez moj algorytm pozwala wykonywac petle glowna. Jak myslisz jak czesto beda wywolywane przerwania? Tak czesto zeby spowolnic petle glowna? Nawet biegajace po schodach dzieciaki nie sa w stanie wywolywac tylu przerwan.
  • #34
    es2
    Level 16  
    Napisałeś:
    oloam wrote:

    Nie wskoczy bo po wyjsciu z przerwania nie wlaczam znowu przerwania.


    Dalej mamy:
    oloam wrote:

    Ostatnie instrukcja w przerwaniu to ustawienie 0 w EIMSK .

    Czyli wyłączasz przerwania po wyjściu z niego, tylko przed opuszczeniem przerwania.

    Dlaczego więc sie oburzasz pisząc:
    oloam wrote:
    es2 wrote:
    W jaki sposób wyłączasz przerwanie po wyjściu z niego?

    Naprawde? Musze czytac przez ciebie datasheet od atmegi.

    ?
    Czy wykonanie czegoś w przerwaniu a po wyjściu z niego to jedno i to samo?

    Spotkałem sie z programami czekającymi w przerwaniu na zwolnienie przycisku. Różnica od twojego, to że nie skakał pomiędzy przerwaniem a pętlą główną tylko siedział w przerwaniu. Działał. Życzę powodzenia w modyfikacji takiego tworu. Gdy rozmawiałem o takim kodzie z kilkoma osobami, to pukały się w czoło jak można tak napisać obsługę klawiatury.
    Idę o zakład, że na temat twojego algorytmu zareagowali by tak samo.

    Dodano po 2 [minuty]:

    oloam wrote:
    . Chyba lepiej przy awarii jak diody beda sie caly czas swiecic (wtedy latwiej znalezc usterke), niz czujnik ma nie dzialac i np w nocy nie zapalac swiatla. Nie wspomne ze przy twoim rozwiazaniu jak ktos stanie na tyle dlugo przed czujnikiem (np wda sie w rozmowe) zeby zakonczyc cykl swiecenia , to swiatlo zgasnie ...

    Sytuacje awaryjna mogę wykrywać w pętli głównej. W praktyce, w przerwaniach od timera, sprawdzałbym stan czujnika, jeśli za długo jest w stanie aktywnym, podejmowałbym jakieś działania (pewnie ustawiałbym flage błedu czujnika).
  • #35
    oloam
    Level 22  
    es2 wrote:
    Napisałeś:

    oloam napisał:

    Nie wskoczy bo po wyjsciu z przerwania nie wlaczam znowu przerwania.



    Dalej mamy:

    oloam napisał:

    Ostatnie instrukcja w przerwaniu to ustawienie 0 w EIMSK .


    Czyli wyłączasz przerwania po wyjściu z niego, tylko przed opuszczeniem przerwania.

    Dlaczego więc sie oburzasz pisząc:

    oloam napisał:

    es2 napisał:
    W jaki sposób wyłączasz przerwanie po wyjściu z niego?


    Naprawde? Musze czytac przez ciebie datasheet od atmegi.


    ?
    Czy wykonanie czegoś w przerwaniu a po wyjściu z niego to jedno i to samo?


    Jeny ale czepiasz sie szczegolow, ktore nie maja wplywu na dzialanie programu. Dla twojej wiedzy, znim zajrzalem do datasheet atmegi opieralem sie na doswiadczeniuz innymi uc gdzie przerwanie nie wykonuje sie ponownie dopoki nie zostanie odpowiednio ustawiona flaga. Stad w pierwszym cytacie mowa o ponownym wlaczeniu przerwania. Skoro w atmedze jest to inaczej rozwiazane , dlatego w nastepnym cytacie pisze o wylaczeniu przerwania. Tylko co to zmienia?
    es2 wrote:
    Spotkałem sie z programami czekającymi w przerwaniu na zwolnienie przycisku. Różnica od twojego, to że nie skakał pomiędzy przerwaniem a pętlą główną tylko siedział w przerwaniu. Działał. Życzę powodzenia w modyfikacji takiego tworu. Gdy rozmawiałem o takim kodzie z kilkoma osobami, to pukały się w czoło jak można tak napisać obsługę klawiatury.
    Idę o zakład, że na temat twojego algorytmu zareagowali by tak samo.

    O czym ty piszesz? Przeciez to ja kontroluje kiedy maja sie wlaczyc przerwania a nie wlacze ich wczesniej niz ma sie cos wykonac wazniejszego niz przerwanie. Przyklad z czekaniem ma sie nijak do mojego algorytmu. Pewnie twoi znajomi na RTOS tez pukaja sie w glowe, przeciez tam jest ciagle przelaczanie taskow.
    es2 wrote:
    Sytuacje awaryjna mogę wykrywać w pętli głównej. W praktyce, w przerwaniach od timera, sprawdzałbym stan czujnika, jeśli za długo jest w stanie aktywnym, podejmowałbym jakieś działania (pewnie ustawiałbym flage błedu czujnika).

    I kto tu komplikuje? Jeszcze musialbys sprawdzac czy to poprostu ktos nie siadl sobie na schodach. U mnie, jak ktos siadlby na schodach - nie ma znaczenia, diody swieca. Jak czujnik ciagle wysyla stan wysoki - awarie widac golym okiem.
  • SterControl
  • #36
    es2
    Level 16  
    oloam wrote:
    U mnie, jak ktos siadlby na schodach - nie ma znaczenia, diody swieca. Jak czujnik ciagle wysyla stan wysoki - awarie widac golym okiem.

    Do ułomności swojego rozwiązania, dorobiłeś sobie teorię, że tak jest dobrze, super i w ogóle lepiej nie może być. Jeśli jednak autor zażyczy sobie, że w przypadku sytuacji awaryjnej ma być ustawiony jakiś tam pin procka a diody wyłączone, to twoje wywody wyższości kodu zajmującego przez przerwanie prawię całą mocy obliczeniowa legną w gruzach.

    Pokaż mi przykłady kodów, w których głównie wykonuje sie przerwanie a czasem program główny. Ile będzie takich przykładów w stosunku do normalnego kodu, gdzie przerwania zajmują kilka, kilkanaście czy kilkadziesiąt % czasu procesora a nie blisko 100.

    Dodano po 2 [minuty]:

    oloam wrote:
    Pewnie twoi znajomi na RTOS tez pukaja sie w glowe, przeciez tam jest ciagle przelaczanie taskow.

    Chcesz uruchomic do tak banalnego zadania RTOS, wymagający dużo ram, którego w AVR jest mało? Gratuluje pomysłu. Paręnaście postów wcześniej była taka propozycja ale w formie żartu, ty jak widze na poważanie.
  • #37
    User removed account
    User removed account  
  • #38
    Freddie Chopin
    MCUs specialist
    Piotrus_999 wrote:
    Nie lamerskich bardzo dużo.

    Procentowo ile? Bo "bardzo dużo" sugeruje, że trzeba by ze 2 cyfry do wyrażenia tych procentów...

    Piotrus_999 wrote:
    Jest mnóstwo programów gzie nawet nie ma programu głównego a jeżeli nawet jest to sprowadza się do pętli z jedną instrukcją : "idz spać".

    Jedynie w bardzo wąskim zastosowaniu - urządzenia o maksymalnie ograniczonym poborze prądu. Tak więc z tym "mnóstwo" to bym nie przesadzał.
  • #39
    User removed account
    Level 1  
  • #40
    User removed account
    User removed account  
  • #41
    User removed account
    User removed account  
  • #42
    Freddie Chopin
    MCUs specialist
    drobok wrote:
    timera powinien ustawiać flagi (np stan=port_z_czujnikami) i koniec przerwania (żadnego wyłączania przerwań i innych śmieci).
    Drugi timer odlicza sekundy (czy tam inne dt dla kolejnych diod), led_port(i)=schody(i) (środkowe 6 bitów, więc trzeba przesunąć i maskować); + flaga wejścia

    Generalnie ta idea jest bezsensowna. Zauważ że absolutnie zupełnie niczym nie różni się ona od najzwyklejszego pollingu stosownej flagi sprzętowej w main() - w końcu praktycznie zawsze sprzęt (np. timer czy piny GPIO) ustawiają jakąś flagę nawet jak przerwanie jest wyłączone. No dobra, różni się - wersja z przerwaniem jest wolniejsza i zajmuje więcej pamięci (; Coś w tym przerwaniu oczywiście należy zrobić żeby jego użycie miało jakikolwiek sens. Kluczem jest znalezienie odpowiedniego kompromisu (;

    R-MIK wrote:
    Osobiście, to pewnie napisałbym obsługę na przerwaniach od timera, np 10ms. W nich stwierdzałbym zmianę stanu czujnika (zbocze opadające) i sterowałbym ledami. Nie musze przekazywac flag pomiędzy przerwaniami, wszystko w jednej funkcji.

    No - wreszcie to ktoś napisał. Jedyne sensowne rozwiązanie w przypadku urządzenia zasilanego z sieci. Wszystko inne to niepotrzebne komplikowanie sobie życia.
  • #43
    User removed account
    User removed account  
  • #44
    User removed account
    User removed account  
  • #45
    User removed account
    User removed account  
  • #46
    oloam
    Level 22  
    es2 wrote:
    Pokaż mi przykłady kodów, w których głównie wykonuje sie przerwanie a czasem program główny. Ile będzie takich przykładów w stosunku do normalnego kodu, gdzie przerwania zajmują kilka, kilkanaście czy kilkadziesiąt % czasu procesora a nie blisko 100.

    Jest mnostwo - wiekszosc prostych przykladow (niekoniecznie prostych pod wzgledem skomplikowania kodu) dla lpc i bibliotek lpcopen. Chociazby przyklad usb msc device:
    Code: c
    Log in, to see the code


    Wiekszosc z was traktuje przerwania jako intrukcje , ktore sa krytyczne czasowo, ale w tym wypadku nie mozna tak tego traktowac. To tak jakby majac do dyspozycji windows pisac aplikacje pod dos z pseudografika bo zajmie mniej miejsca na dyku jako plik i mniej pamieci - zamiast 100kb zajmie 1mb. I co z tego? Po to sa dostepne zasoby, zeby z nich korzystac. Czasy kiedy to trzeba bylo optamalizowac program pod wzgledem zasobow bezpowrotnie minely. Przyklad: tworcy gier maja to gdzies - nie wystarcza ci obecna karta graficzna to kup nowa. To samo przenosi sie uc. Sa coraz bardziej wyposozone, w wiekszosci nowych uc programowanie sprowadza sie do wlaczania peryferiow i jakiej banalnym kodzie obslugujacym owe peryferia. Argument z oszczedzaniem energii w tym projekcie wogole nietrafiony - w trakcie wykonywania przerwan zuzycie wzrosnie o 10ma? Co z tego? Nie tworzycie projektu do oprogramowania tylko oprogramowanie do projektu. Do tego projektu i algorytmu atmega sie nada a i tak w wiekszosci programu bedzie sie nudzic. Ze wiecej popracuje w trakcie zalaczenia czujnika lub specyficznej awarii? Zarty. Pytam ile takich sytuacji bedzie ze trzeba martwic sie wydajnosc uc (chociaz w tym przypadku nawet przerwanie nie maj prawa 'zawiesic' uc) i o zuzycie pradu(?). Przeciez nie dla kazdego projektu trzeba pisac program jakby chodzilo o zycie ludzkie czy globalna katastrofe a niektorzy tak patrza na ten projekt.
    es2 wrote:
    Chcesz uruchomic do tak banalnego zadania RTOS, wymagający dużo ram, którego w AVR jest mało? Gratuluje pomysłu. Paręnaście postów wcześniej była taka propozycja ale w formie żartu, ty jak widze na poważanie.

    Gdzie napisalem, ze chce uruchomic RTOS? Napisalem, ze moj algorytm ma podobne machanizmy jak w RTOS i ze twoi znajomi sa przeciwni uzywania OS.
  • #47
    User removed account
    User removed account  
  • #48
    oloam
    Level 22  
    R-MIK wrote:
    Osobiście, to pewnie napisałbym obsługę na przerwaniach od timera, np 10ms.

    Suma sumarum wciagu dnia procek zuzyje wiecej energi bo jednak co 10ms wykonuje przerwanie i obliczenia (sprawdzanie stanow czujnika)
    W moim przykladzie procek wybudza sie tylko na czas przerwania i niech bedzie ich 1k w ciagu dnia , to i tak mniej operacji na dzien niz przy ustawionym timerze.
  • #49
    User removed account
    User removed account  
  • #50
    JacekCz
    Level 39  
    w języku łacińskim dwa przeczenia dają mocne twierdzenie (jak w logice). Tu trudno powiedzieć
    Koledzy już dawno stracili kontrolę, kto komu zaprzecza.

    Wśród przeczeń jest przywoływane wiele BŁĘDNEGO kodu (w dobrej intencji), ale że przeczenia są niezrozumiałe, ktoś-kiedyś uzna go za prawidłowy i wklei w jakiś ekspres do kawy albo Airbusa A330

    A Pierwotny Pytający śpi ....
  • #51
    oloam
    Level 22  
    R-MIK wrote:
    Już to czytałem, wiele razy, to się nazywa "profesjonalne" podejście.

    Mam co prawda wyksztalcenie tylko technika informatyka, ale w szkole maglowalismy nie raz to 'profesjonalne' podejscie, chociazby ze wzgledu na to ze pisalismy pod dos.
    I mam wrazenie,ze nie do konca zrozumiales o czym pisze. Zapewne majac pc pod windows i napisac chocby prosta gre w trybie geaficznym, to raczej nie bedziesz programowal karty graficznej,bo wiesz dokladnie co bedzie robila i bedziesz mial zoptymalizowany kod po swojemu, tylko uzyjesz bibliotek dx gdzie nie bedziesz mial pojecia jakie tam cuda beda sie wyrabialy i ile to wiecej zajmnie pamieci i zasobow.

    Dodano po 5 [minuty]:

    R-MIK wrote:
    Przy uszkodzonym czujniki/lini też zużyje mniej energii?

    A przy twoim rozwiazaniu? Nie ma opadajacego zbocza, petla dziala... Poza tym zapytam jeszcze raz : ile takich awarii na dzien masz? Myslisz ze od czasu zauwazenia awarii do czasu jej usuniecia ile MWh wiecej zuzyje procek?
  • #52
    User removed account
    User removed account  
  • #53
    oloam
    Level 22  
    R-MIK wrote:
    W jaki sposób? Wystąpi przerwanie, wykona się, timery wysteruja ledy. Po zakończeniu cyklu z led procek zaśnie na dobre, niby jak ma działać pętla? Linia czujnika jest w stanie niskim, a przerwanie od zbocza.

    Odpowiedz tyczyla awarii czujnika, kiedy to nie bedzie zbocza opadajacego.
    R-MIK wrote:
    W twoim rozwiązaniu jest inaczej, warunek przerwania cały czas występuje (poziom niski) i program ciągle wchodzi w przerwanie. Pytanie po co skoro nic się nie zmienia?

    Wlasnie ze nie ciagle, bo jak pisalem wyzej, wylaczam przerwanie w obsludze przerwania a zalaczam w petli glownej w miejscu w ktorym potrzebuje. Ale ok - robie przerwanie od timera w ktorym jest tylko jedna instrukcja wlaczania przerwania zewnetrznego. Czym sie rozni od twojego rozwiazania? Ano tym, ze w przerwaniu timera wykonuje sie tylko jedna instrukcja, kod mniej skomplikowany, mimowolne wykrycie awarii.
    R-MIK wrote:
    Gdy mierzysz czas impulsu na wejściu w jaki sposób to robisz?

    Nie mierze czasu impulsu, bo do tej pory nie mialem potrzeby. Jezli zajdzie taka potrzeba to wertuje dokumentacje oraz zasoby internetowe i wybiram najlepsze rozwiazanie.
    R-MIK wrote:
    W profesjonalnym podejściu, program reaguje na zmiany. O to opierają się prawdziwe 9czyli nie Win) systemy wielozadaniowe (czyli Unix).

    Naprawde? Chyba powinienem zostawic to bez komentarza. Nie wiem czy zauwazyles ale rozmawiamy o uc z programem do oswietlenia schodow a nie z programem na OS uc.
    Przyklad programu pod win mial za zadanie poruszyc twoja wyobraznie i pokazac, ze nie zawsze cel (mniejszy kod , mniejsze zuzycie zasobow) uswieca srodki.
  • #54
    User removed account
    User removed account  
  • #55
    oloam
    Level 22  
    R-MIK wrote:
    Napisz mi proszę jak pętla dział, skoro była mowa o usypianiu procka. Nie ma zmian stanu czujników procek śpi.

    Sorry moj blad. Masz racje. Tworzy to jednak , co prawda malo istotny, aczkolwiek problem. Sam pisales, ze program powinien reagowac na wszystkie sygnaly. Kiedy nastapi awaria czujnika. Nie masz zadnej reakcji programu. U mnie jest to polowicznie (jezeli czujnik bedzie stale w czasie wysokim) wykrywalne i beda caly czas swiecic diody led. No i druga sytuacja (bardziej prawdopodobna) , jak siada sobie dwie (lub wiecej) panienki przy czujniku na pogaduszki to nie bedzie reakcji (zapalenia swiatla) - beda musialy machac nogami zeby je sobie zapalic.
    R-MIK wrote:
    W którym miejscu pętli głównej to robisz? Gdzie byś nie zrobił to spowoduje to natychmiastowe wybudzenie procka.

    Na poczatku (jeszcze zanim dolaczyles sie do rozmowy) nie bylo mowy o usypianiu procka, dlatego pozniej zaproponowalem rowniez przerwanie od timera a procek do snu.
    R-MIK wrote:
    Pokaż swoja implementację z przerwaniem od poziomu niskiego (doczytałem, ze nawet nie widziałeś, że nie ma przerwań od poziomu wysokiego), gdzie usypiasz procka a ja pokażę gdzie po uśpienie zaraz zostanie wybudzony albo wybudzenie nigdy nie wystąpi.

    Dlaczego nie doczytales ze wogole nie znam atmegi i ze na potrzeby postow otworzylem datasheet?
    R-MIK wrote:
    Podkreślę, jeszcze raz, że nie twierdze, ze twój program nie zadzaiała. Zadziała, ale sposób jego napisania to czysta amatorszczyzna.

    Ja mowie o algorytmie - ty o kodzie. Jak napiszesz kod wg mojego algorytmu bedzie bardziej funkcjonalny i oszczedny niz twoj.
    Dla niemogacych sobie tego wyobrazic wygladaloby to mniej wiecej tak:
    Quote:

    funkcja przerwaniestanem{
    wykrycie czujnika/wo
    reakcja
    wylaczenie przerwanie zewnetrznego
    }

    funkcja przerwanie od timera{
    wlaczenie przerwania zewnetrznego
    }

    //setup
    konfiguracja przerwan
    wlaczenie przerwania timera

    Loop spij
  • #56
    Slawek K.
    Level 35  
    R-MIK wrote:
    Już to czytałem, wiele razy, to się nazywa "profesjonalne" podejście. A efekty tego profesjonalizmu widać, zamiganie dioda pod Arduino 12kB.

    Uwielbiam "profesjonalizm" kolegi @R-MIK, zwłaszcza w matematyce ;)
    Specjalnie wrzuciłem "przykład" z Arduino IDE żeby nie było niedomówień ;)

    Wiele wątków a jedno Arduino

    Jak dla mnie to 1kB, ale być może ja się nie znam bo jestem arduinowcem :D

    Pozdr
  • #57
    User removed account
    User removed account  
  • #58
    User removed account
    User removed account  
  • #59
    User removed account
    User removed account  
  • #60
    oloam
    Level 22  
    R-MIK wrote:
    Gdzie dałeś taka propozycję? Przejrzałem wszystkie posty i znalazłem tylko swój na temat przerwań od timera.

    Naprawde? Nie wierze, ze nie jestes na tyle inteligentny, zeby nie domyslic sie ze chodzi o procek do snu. Po co wtedy mialbym dodawac przerwanie od timera? Nie zgrywaj sie , chyba rozmawiamy na powaznie...
    R-MIK wrote:
    Jeśli mam reagować na awarie, a oszczędność energii jest istotna, uruchomię asynchroniczny timer 32kHz z preskaleram 1024 i będę liczył przepełnienia. Da to przerwania co ok 8 sekund. Co 8 sekund bede sprawdzał czy czujnik nie ma awarii. Przyznasz, że zużycie prądu będzie tysiące razy mniejsze, niż w twoim przypadku, gdzie program praktycznie cały czas pracuje, do usypiany jest na jeden rozkaz.


    R-MIK wrote:
    Ulepszenie polega na tym, ze procek śpi (pomijając przerwania od timera) do chwili gdy timer nie zrobi swoich zadań. Później znowu zostanie wybudzony poziomem i tak w kółko dopóki awaria czujnika nie zostanie usuniętea. Naturalnie mozna kod dalej komplikowac, jesli cykle świecenia sa za często czy zbyt długo, ustawić flagę i nie reagować na poziom aktywny tego czujnika.


    Ja komplikuje to ty wprowdzasz dodatkowe timery i kod zeby wykryc awarie.Eeee tam nie patrzysz tworczo, trzeba ci kazdy pomysl napisac (?):
    Quote:


    funkcja przerwaniestanem{
    wykrycie czujnika/wo
    reakcja
    wylaczenie przerwanie zewnetrznego
    wlaczenie przerwania od timera
    }

    funkcja przerwanie od timera{
    wlaczenie przerwania zewnetrznego
    wylaczenie przerwania od timera
    }

    //setup
    konfiguracja przerwan
    wlaczenie przerwania timera

    Loop spij


    teraz procek caly czas spi, budzi sie tylko podczas przerwania zewnetrznego, jezeli jest awaria lub kolezanki sobie gadaja siedzac na schodach , ustawienia przerwania od timera decyduja o tym jak czesto ma sie wykonywac funkcja przerwania zewnetrznego. Proste ? Proste Latwiejsze w implementacji? Latwiejsze . Spelnia zalozenia? Spelnia.
    R-MIK wrote:
    estem więc skłonny się założyć o to czyj kod bedzie lepszy pod wzgledem zajęcia zasobów, czasu procesora, poboru pradu.

    Napisz wiec oba programy i sprawdz...