Arduino: Obsługa wielu czujników i diod bez użycia delay i z przerwaniami

Witam
Jednowątkowy procesor i 16000 sprawdzań na sekundę...
za mało
Nie chcę udawać się do rozwiązań z malinką.
Czujnik na schodach.
włażę poziom "high"... i zapala po kolei 6 diod (diody zapalają się po kolei od czujnika w który wlazłem)
czas ustawiony i ok.
Ale czujniki są 2 i jednocześnie ktoś zaczyna schodzić...
przy "loop" łapie tylko jednego.
"delay" odpada...
Nie daj Boże jak ktoś zostanie na schodach..
Mamy 3 piętra i jednego atmela
Ja dopiero zaczynam i proszę o wyrozumiałość.

Jeszcze jedno - jak czasu przerwań nie liczyć do "akcji" ?

Factisek napisał:

Witam
Jednowątkowy procesor i 16000 sprawdzań na sekundę...
za mało
...
Czujnik na schodach.
...

Przepraszam, ty po tych (westernowych) schodach to strzelasz kulę rewolwerową?

Tego, co piszesz nie da się potraktować merytorycznie.

Po tych westernowych schodach to będę chodził.
Potrafisz pomóc czy tylko mącisz?

Factisek napisał:

Po tych westernowych schodach to będę chodził.
Potrafisz pomóc czy tylko mącisz?

Potrafisz sobie dać pomóc?
koncepcja, wstępny kod, dlaczego akurat te 16tys ci wychodzi i w ogóle ...

chcę pomocy
Jak wyjść poza "loop" żeby dziadu nie czekał?

Dodano po 7 [minuty]:

chcę wyjść poza jedną pętlę

Kazdy czujnik niech generuje przerwanie, w przerwaniu badasz ktory czujnik sie odezwal i wlaczasz diody dla tego czujnika.

W tym projekcie mikrokontroler bedzie obrabial na tyle wolne akcje, ze w zupelnosci wystarczy dac wszystko w petli glownej. Trzeba aby autor przedstawil dobry algorytm, bo tu pulapek logicznych bedzie kilka.
I tu bedzie lezal caly problem aby program byl dobrze pozniej napisany.
Takze ja nie wiem skad ta potrzeba wielowatkowosci w tym przypadku...

Podobnie jak @JacekCz dopytam - czlowiek chodzac po schodach jaka moze miec predkosc?
Skad te 16000 / sekunde? Autorze, chyba cos za bardzo fantazjujesz.

Dwa czujniki razy 3 piętra to jest tak jakby 6. Przypuśćmy, że będą biegać po schodach to sprzawdzamy kazdy 10 razy na sekundę, 6 * 10 daje 60. Pozostaje 15940. Pewnie przewidział rozbudowę domu do 797 (15940 / 2czujniki / 10razy na sek) pięter

Na razie wystarczą przerwania 60 razy na sekundę, albo, jak było napisane wcześniej, każdy czujnik osobna linia przerwań.

Dodano po 3 [minuty]:

Factisek napisał:

Jak wyjść poza "loop" żeby dziadu nie czekał?

maszynę stanów zrób.

es2 napisał:

...jak było napisane wcześniej, każdy czujnik osobna linia przerwań

Ale po co osobne linie przerwan? Wystarczy jedno przerwanie od wszystkich czujnikow plus sygnal z czujnika na wejscie (jezeli duzo czujnikow to uzyc 74hc165). Algorytm prosty. Przerwanie, sprawdzenie wejsc czujnikow (wykrycie czujnika) i zapalenie diod dla danego czujnika. Proste jak ...

oloam napisał:

es2 napisał:

...jak było napisane wcześniej, każdy czujnik osobna linia przerwań

Ale po co osobne linie przerwan? Wystarczy jedno przerwanie od wszystkich czujnikow plus sygnal z czujnika na wejscie (jezeli duzo czujnikow to uzyc 74hc165). Algorytm prosty. Przerwanie, sprawdzenie wejsc czujnikow (wykrycie czujnika) i zapalenie diod dla danego czujnika. Proste jak ...

Przerwanie od zbocza czy poziomu niskiego? W obu przypadkach widzę "komplikatory".
Jakie by nie było rozwiązanie z jedną linia przerwania, to trzeba dać dodatkową bramke np AND dla przerwania i osobne linie z czujników, wiec w sumie 7 linii na 6 czujników.

Jak pisalem wyzej mozna zastosowac 74hc165 i wtedy zawsze dla uc beda 'zajete' 4 linie (linia przerwania, 3 linie obslugi 74hc165). 32 czujniki - bez problemu 4x74hc165 i wciaz zajete 4 linie uc.

oloam napisał:

Jak pisalem wyzej mozna zastosowac 74hc165 i wtedy zawsze dla uc beda 'zajete' 4 linie (linia przerwania, 3 linie obslugi 74hc165). 24 czujniki - bez problemu 4x74hc165 i wciaz zajete 4 linie uc.

Zapomniałeś o bramce AND/NAND, która sumuje logicznie wszystkie sygnału z czujników i daje na linie przerwania uC. Jakiego przerwania użyjesz? Poziom czy zbocze?

Diody nie wystarcza? Sygnal do przerwania za dioda do 'wykrywania' przed dioda(?)

O ile dobrze zrozumialem autora to przecież to mozna zrobić bez przerwan na trzech "switchach". Bez użycia funkcji delay i musi dzialac. Wielowatkowasc do sterowania światłem? Bez przesady

oloam napisał:

Diody nie wystarcza? Sygnal do przerwania za dioda do 'wykrywania' przed dioda(?)

Może byc partyzanckie rozwiązanie na diodach pełniących funkcje AND. Przerwanie od zbocza czy poziomu?

Dodano po 3 [minuty]:

japycz321 napisał:

O ile dobrze zrozumialem autora to przecież to mozna zrobić bez przerwan na trzech "switchach". Bez użycia funkcji delay i musi dzialac. Wielowatkowasc do sterowania światłem? Bez przesady

Rozwiązań jest wiele. Może być w pętli głównej, może na przerwaniach od timera, na przerwaniach od czujników. Każdy wybiera to co jest dla niego najwygodniejsze. Może jeszcze będzie chciał dodać obsługę Wi-Fi albo BT. Od tego jak obsłuży dodatkowe interfejsy (całkowicie na przerwaniach czy nie) będzie zależał wybór obsługi czujników.

es2 napisał:

Może byc partyzanckie rozwiązanie na diodach pełniących funkcje AND.

Nie jestem dobry w elektronice, wiec zapytam - dlaczego partyzanckie?

es2 napisał:

Przerwanie od zbocza czy poziomu?

Raczej zboczem, ze wzgledu kiedy to bedada aktywne 2 lub wiecej czujnikow.

japycz321 napisał:

O ile dobrze zrozumialem autora

Ja tez odpowiedzialem w taki sposob: O ile dobrze zrozumialem autora

oloam napisał:

es2 napisał:

Może byc partyzanckie rozwiązanie na diodach pełniących funkcje AND.

Nie jestem dobry w elektronice, wiec zapytam - dlaczego partyzanckie?

oloam napisał:

Temat woda. Wszystko przez to, że dioda ma jakiś spadek napięcia. Szkoda tu się nad tym rozwodzić. W każdym razie bramka jest lepsza i zajmuje mniej miejsca na PCB.

es2 napisał:

Przerwanie od zbocza czy poziomu?

Raczej zboczem, ze wzgledu kiedy to bedada aktywne 2 lub wiecej czujnikow.

I wpadłeś w pułapkę. Masz sumę logina AND. Jeden czujnik jest aktywowany, masz IRQ od zbocza opadającego, sprawdzasz który czujnik itd, wychodzisz z przerwania. Sygnał z tego czujnika cały czas jest aktywny bo trwa np 100ms. W tym czasie inny czujnik jest aktywowany. Dostajesz kolejne przerwanie? Suma AND, jakikolwiek czujnik aktywny, linia INT ma poziom niski.

es2 napisał:

es2 napisał:
Może byc partyzanckie rozwiązanie na diodach pełniących funkcje AND.

Nie jestem dobry w elektronice, wiec zapytam - dlaczego partyzanckie?

Jak zbuduje na diodach to nie mam AND tylko OR. Zamieniam zbocze na poziom i problem rozwiazany...

oloam napisał:

es2 napisał:

es2 napisał:
Może byc partyzanckie rozwiązanie na diodach pełniących funkcje AND.

Nie jestem dobry w elektronice, wiec zapytam - dlaczego partyzanckie?

Jak zbuduje na diodach to nie mam AND tylko OR. Zamieniam zbocze na poziom i problem rozwiazany...

Poziom, czyli niski bo innego AVR nie obsłuży, więc bramka AND, ok.
Aktywny czujnik 1, wchodzimy w przerwanie, obsługujemy je i co dalej? Wychodzisz z przerwania?

es2 napisał:

Aktywny czujnik 1, wchodzimy w przerwanie, obsługujemy je i co dalej? Wychodzisz z przerwania?

Tak, jezeli czujnik nadal bedzie utrzymywal stan przerwania , to wykona sie najwyzej jeszcze raz i raz i raz... wciaz mniej razy niz w loop

es2 napisał:

Poziom, czyli niski bo innego AVR nie obsłuży, więc bramka AND, ok.

Tego o AVR nie wiem ale jak napisales bramka i po sprawie.

oloam napisał:

es2 napisał:

Aktywny czujnik 1, wchodzimy w przerwanie, obsługujemy je i co dalej? Wychodzisz z przerwania?

Tak, jezeli czujnik nadal bedzie utrzymywal stan przerwania , to wykona sie najwyzej jeszcze raz i raz i raz... wciaz mniej razy nie w loop

Czyli gdy czujnik jest aktywny program praktycznie stoi, bo wchodzi w przerwanie, wykonuje je, wychodzi, wykonuje jeden rozkaz, wchodzi w przerwanie, idt.
Teraz aktywowany jest kolejny czujnik, w sumie nic się nie zmienia, w kółko kręcimy sie w przerwaniu. Napiszesz algorytm rozpoznania kierunku itp w takim przerwaniu?
Jeśli w pętli głównej będzie obsługa WDG, to takie przerwania, mogą doprowadzić do tego, że na czas nie obsłużysz WDG i program sie zresetuje.
Przyznajesz, że nie tędy droga, ?


Zapamiętaj, ze przerwania wyzwalane poziomem, sa używane do układów peryferyjnych, które utrzymują aktywny poziom niski do czas gdy źródło przerwania nie zniknie (np nie odczytasz danej w USART). Umożliwia to łączenie wielu źródeł przerwań w jednym układzie do jednej linii (wektora) czy wielu układów a programowo rozpoznajesz źródło przerwania i je kasujesz (lub kasuje sie automatycznie).
Do linii przerwania wyzwalanego poziomem podłączasz tylko jedno źródło.


Jaka dajesz teraz propozycję?

Dodano po 2 [minuty]:

oloam napisał:

Poziom, czyli niski bo innego AVR nie obsłuży, więc bramka AND, ok.

Tego o AVR nie wiem ale jak napisales bramka i po sprawie.[/quote]
Nie znam procesora, który akceptowałby przerwanie poziomem wysokim, bo nie znam tez układów peryferyjnych, które w ten sposób by generowały przerwanie. Zawsze jest to wyjście OC (OD). Mówimy o współczesnych układach a nie jakiś badziewiarskich, przestarzałych rozwiązaniach Intela.

es2 napisał:

Jaka dajesz teraz propozycję?

Nie wlaczac przerwania od razu tylko sprawdzic czy nie ma czegos innego do zrobienia. Okreslic priorytet co na dany moment jest wazniejsze., czy czujniki (wlaczyc przerwanie) czy np wyswietlenie czegos na lcd (najpierw lcd, pozniej wlaczam przerwanie).

oloam napisał:

Nie znam procesora, który akceptowałby przerwanie poziomem wysokim, bo nie znam tez układów peryferyjnych, które w ten sposób by generowały przerwanie.

Akurat mecze lpc4357 :

Cytat:

Up to 8 pins can be selected from all GPIO pins as edge- or level-sensitive interrupt
requests. Each request creates a separate interrupt in the NVIC.
• Edge-sensitive interrupt pins can interrupt on rising or falling edges or both.
• Level-sensitive interrupt pins can be HIGH- or LOW-active

oloam napisał:

es2 napisał:

Jaka dajesz teraz propozycję?

Nie wlaczac przerwania od razu tylko sprawdzic czy nie ma czegos innego do zrobienia. Okreslic priorytet co na dany moment jest wazniejsze., czy czujniki (wlaczyc przerwanie) czy np wyswietlenie czegos na lcd (najpierw lcd, pozniej wlaczam przerwanie).

Nie widzisz, ze sie "zapętlasz"? Algorytm takiego programu będzie strasznie skomplikowany a i tak może to spowodować, ze przegapisz jakieś przerwanie. Zgadzasz sie z tym?

Czy nie prościej, każdy czujnik do osobnej linii przerwania od zbocza?
Jeśli już problemem jest ilość linii, to np PCF8574 lub podobny na IIC. Zajmujemy 3 linie i mamy reakcje na przerwania. Nic nie gubimy i nie kręcimy sie w kółko w przerwaniu zawieszając resztę programu.

es2 napisał:

Nie widzisz, ze sie "zapętlasz"? Algorytm takiego programu będzie strasznie skomplikowany a i tak może to spowodować, ze przegapisz jakieś przerwanie. Zgadzasz sie z tym?

Nie, nie zgadzam sie z tym ,uwazam ze algorytm jest prosty jak drut. W prostym programie wystarczy jedna flaga zeby zrealizowac sprawdzanie zadan do wykonania ale to chyba juz temat do dzialu programowanie.

es2 napisał:

Czy nie prościej, każdy czujnik do osobnej linii przerwania od zbocza?
Jeśli już problemem jest ilość linii, to np PCF8574 lub podobny na IIC. Zajmujemy 3 linie i mamy reakcje na przerwania. Nic nie gubimy i nie kręcimy sie w kółko w przerwaniu zawieszając resztę programu.

Chyba nie prosciej ( jezeli pytasz o prostote). Dobry algorytm to podstawa. A w tym przypadku nie mam nic skomplikowanego...

Twierdzisz, że twoje rozwiązanie jest proste. Wcześniej twierdziłeś, ze zrobisz na przerwaniach od zbocza. Zrobił bys i co? Program czasami by działa źle. Ile czasu bys dochodził, ze trzeba zrobić IRQ od poziomu? Teraz zaczynasz kombinować z zawieszaniem przerwań. Ok, sprawdźmy, który algorytm będzie prostszy i mniej będzie obciążał uC. Mój wyglądał by np tak:
- inicjalizacja przerwań od 6 linii zbocze narastające

przerwanie:
- określ źródło przerwania
- ustaw flagę/flagi

pętla główna:
- sprawdź flagi, wykonaj działania związane z flagami, skasuj flagę/flagi
- sprawdź czy jest choć jeden znak w USART, podejmij działanie jak jest znak/znaki w Usart
- czy trzeba zmienić treść LCD? jak tan zmień zawartość LCD
- tu czasochłonne działania trwające 100ms

Praktycznie 100% mocy uC idzie w pętle główną. Zakładając, że czujnik może przesłać 10 danych na sekundę, pętla główna może wykonywać sie 100ms. Przypuśćmy jednak, że wykonuje sie dłużej, albo czujniki przesyłają dane częściej, zrobię wtedy tak:
- inicjalizacja przerwań od 6 linii zbocze narastające

przerwanie:
- określ źródło przerwania
- ustaw flagę/flagi
- wykonaj działania związane z flagami, skasuj flagę/flagi

pętla główna:
- sprawdź czy jest choć jeden znak w USART, podejmij działanie jak jest znak/znaki w Usart
- czy trzeba zmienić treść LCD? jak tan zmień zawartość LCD
- tu czasochłonne działania trwające 500ms

Nadal praktycznie 100% mocy idzie w petle główną, która może wykonywać się dowolnie długo, byle obsłużyła na czas usart.


Widzisz jakieś błedy w moim algorytmie? Czy twój algorytm będzie prostszy?

es2 napisał:

Twierdzisz, że twoje rozwiązanie jest proste. Wcześniej twierdziłeś, ze zrobisz na przerwaniach od zbocza. Zrobił bys i co? Program czasami by działa źle. Ile czasu bys dochodził, ze trzeba zrobić IRQ od poziomu?

Do pierwszego debugu...

przerwanie:
-wykonaj funkcje zwiazane z przerwaniem (zapal diody)

petla głowna:
-sprawdz czy jest cokolwiek w kolejce do wykonania
-jezeli nie wlacz przerwanie w przeciwnym wypadku wykonaj jedna funkcje z kolejki i wlacz przerwanie

W najgorszym przypadku gdy czujnik bedzie caly czas generowal przerwanie na calosci programu trace czas tyle co wykonanie przerwania...

U ciebie jak ktos stanie na czujniku to jak diody zgasna , to spadnie ze schodow i sie polamie...

oloam napisał:

przerwanie:
-wykonaj funkcje zwiazane z przerwaniem (zapal diody)

Po wyjściu z przerwania wykona się jeden rozkaz i program znów wskoczy w przerwanie, dopóki na wszystkie czujniki nie znajda sie w stanie nieaktywnym. Taka jest specyfika przerwania od poziomu niskiego. Co z tym zrobisz?

oloam napisał:

U ciebie jak ktos stanie na dluzej czujniku to jak diody zgasna , to spadnie ze schodow i sie polamie...

es2 napisał:

Po wyjściu z przerwania wykona się jeden rozkaz i program znów wskoczy w przerwanie, dopóki na wszystkie czujniki nie znajda sie w stanie nieaktywnym. Taka jest specyfika przerwania od poziomu niskiego. Co z tym zrobisz?

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

oloam napisał:

oloam napisał:

U ciebie jak ktos stanie na dluzej czujniku to jak diody zgasna , to spadnie ze schodow i sie polamie...

es2 napisał:

Po wyjściu z przerwania wykona się jeden rozkaz i program znów wskoczy w przerwanie, dopóki na wszystkie czujniki nie znajda sie w stanie nieaktywnym. Taka jest specyfika przerwania od poziomu niskiego. Co z tym zrobisz?

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

W jaki sposób wyłączasz przerwanie po wyjściu z niego? W przypadkowym miesjscu pętli głównej następuje przerwanie, wchodzisz w nie, wykonujesz, wychodzisz, wykonuje sie jeden rozkaz petli głównej i znów skaczesz w przerwanie. Gdzie i jak je wyłaczasz?

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