• Witaj na Forum Arduino Polska! Zapraszamy do rejestracji!
  • Znajdziesz tutaj wiele informacji na temat hardware / software.
Witaj! Logowanie Rejestracja


Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
kod wykonywany w przerwaniu
#1
Czy kod umieszczony w przerwaniu powinien byc wykonany tylko raz w czasie wywołania przerwania , czy cały czas w przypadku gdy stan wywołujący trwa nadal?

różne warianty. LOW,High, rising falling

Ewentualnie czy prawidłowym jest umieszczenie prostego kodu typu if w procedurze wywołanej przerwaniem?

Pytam gdyż coś mi nie działa i może zle to interpretuje.
 
Odpowiedź
#2
Tylko raz się wykonuje... Prosty "if" dopuszczalny... Najważniejsze to zmienne volatile i by był jak najkrótszy by jak najmniej czasu zajmowało przerwanie...
Arduino zostało wymyślone po to, by robić dobrze jedną prostą rzecz – migać diodą. 
 
Odpowiedź
#3
(27-02-2020, 10:48)worker13 napisał(a): Czy kod umieszczony w przerwaniu powinien byc wykonany tylko raz w czasie wywołania przerwania , czy cały czas w przypadku gdy stan wywołujący trwa nadal?
Jeśli ustawisz przerwanie w opcji LOW, to dopóki na wejściu przerwania będzie LOW CPU będzie powyjściu z przerwania wykonywał jeden rozkaz po czym zpowrotem wchodził w przerwanie, dlatego w przerwaniu należy skasować źródło przerwania.
Kod z delay to nie kod, to DEMO!
Możliwości sprzętowe uC trzeba wykorzystywać a nie /machać/. GPIO!
Jestem a usilnie chcę być amatorem to dwie różne rzeczy.

http://er-mik.prv.pl/projekty edw.php 
http://er-mik.prv.pl/projekty_avt.php
 
Odpowiedź
#4
Co do tego czasu obsługi przerwania to jak zwykle są różne szkoły i opinie. Ja też uważam, że przerwanie powinno wykonywać się jak najszybciej, ale co ciekawe można spotkać kody i biblioteki gdzie w przerwaniu jest niejeden while - więc to trochę kwestia podejścia.
 
Odpowiedź
#5
Skopiowane z :https://plociennik.info/index.php/obsluga-przerwan
Nazwa Opis
LOW przerwanie wywołane zostanie, gdy pin będzie miał stan niski
HIGH przerwanie wywołane zostanie, gdy pin będzie miał stan wysoki
CHANGE przerwanie wywołane zostanie, gdy stan pinu zmieni się
FALLING przerwanie wywołane zostanie, gdy stan pinu zmieni się z wysokiego na niski
RISING przerwanie wywołane zostanie, gdy stan pinu zmieni się z niskiego na wysoki
-----------------------------------------------------------------------------------------------
Według mnie, aby funkcja w przerwaniu wykonywała się raz, najlepiej używać CHANGE, FALLING lub RISING
Jak bredzę, to mnie poprawcie.
 
Odpowiedź
#6
ISCx1 ISCx0 DESCRIPTION
0 0 Low level of INTx generates an interrupt request
0 1 Any logic change on INTx generates an interrupt request
1 0 The falling edge of INTx generates an interrupt request
1 1 The rising edge of INTx generates an interrupt request
Arduino zostało wymyślone po to, by robić dobrze jedną prostą rzecz – migać diodą. 
 
Odpowiedź
#7
(27-02-2020, 11:22)elvis napisał(a): co ciekawe można spotkać kody i biblioteki gdzie w przerwaniu jest niejeden while - więc to trochę kwestia podejścia.
Jak system przerwań jest wielopoziomowy to while w przerwaniu (te o niskim poziomie) może ułatwić pisanie programu. Niestety, Arduino jest postrzegane jako UNO czyli mega328 gdzie z wieloma poziomami przerwań jest problem.
W przypadku powolnych AVR program z while w przerwaniu może działać szybciej niż w przypadku ciągłego wchodzenia i wychodzenia w przerwanie. Dobrym przykładem jest(wysyłanie danych przez SPI z max prędkością, podobnie jak i UART. wejście i wyjście z przerwania zajmuje więcej czasu niz sama obsługa przerwania, dlatego wysyłając kilka bajtów korzystniej czasowo jest zrobić to czekając w przerwaniu na zakończenie poprzedniej transmisji.


(27-02-2020, 11:49)Agregacik napisał(a): Według mnie, aby funkcja w przerwaniu wykonywała się raz, najlepiej używać CHANGE, FALLING lub RISING
Jak bredzę, to mnie poprawcie.
Przy wyzwalaniu poziomem, najczęściej właśnie chodzi o to aby wykonywało się aż wszystkie źródła przerwań nie będą ich zgłaszać.
Kod z delay to nie kod, to DEMO!
Możliwości sprzętowe uC trzeba wykorzystywać a nie /machać/. GPIO!
Jestem a usilnie chcę być amatorem to dwie różne rzeczy.

http://er-mik.prv.pl/projekty edw.php 
http://er-mik.prv.pl/projekty_avt.php
 
Odpowiedź
#8
Czyli w takim przypadku w funkcji obsługi przerwania trzeba "gasić" poszczególne wywołania po obsłużeniu.
 
Odpowiedź
#9
(27-02-2020, 17:36)Agregacik napisał(a): Czyli w takim przypadku w funkcji obsługi przerwania trzeba "gasić" poszczególne wywołania po obsłużeniu.
Temat raczej na książkę niż forum i raczej duże systemy niż mikrokontrolery. Zapoznaj się z przerwaniami maskowalnymi np Z80 w trybie IM1, czy 6502, 68k tryb autowektor. Do tego peryferiami do w/w CPU.

W skrócie, gdy do jednej linii przerwania masz podłączone kilka układów zgłaszających je (suma logiczna na drucie) to przerwanie może zgłosić kilka układów na raz lub w jednym układzie wystąpić kilka zgłoszeń albo w czasie obsługi przerwania pojawić się kolejne. Przypuśćmy, dostajesz przerwanie z UART, odbierasz znak, to najczęściej automatycznie kasuje przerwanie ale w czasie wyjścia z przerwania przychodzi kolejny znak. UART znów ustawia L żądając obsługi. CPU wychodzi z przerwania po oczy ponownie w nie wchodzi. 
Inna sytuacja, kilka układów na jednej linii przerwania. Obsługujesz jedno przerwanie a w tym czasie inny układ żąda obsługi.

Jak sobie to dobrze przeanalizujesz, wszystkie możliwe przypadki, to stwierdzisz, że obsługa zboczem może doprowadzić do tego, że linia przerwania jest aktywna a CPU "hula" w programie głównym i już nigdy nie obsłuży przerwania chyba, że w programie głównym tez będzie kasował zgłoszone przerwania ale jak program napisany jest po arduinowemu, to w ten sposób przerwania mogą być odblokowane po kilku czy kilkudziesięciu sekundach i miliony zdarzeń (np znaków z UART) przepadnie.

Jak wgryziesz się w temat, to zrozumiesz jak spie... konstrukcja PC AT/XT i podobnych z ISA i problemy z przerwaniami, zworkologia itp. Co dziwne, kontroler przerwań, mógł pracować w "normalnym" trybie, reagując na poziom niski, niestety, w przypływie nie wiem czego, wybrano bezsensowny w tym przypadku tryb reakcji na zbocze narastające przez co w praktyce do jednej linii przerwania można było przyłączyć jedno źródło (co w sytuacji gdy układ miał wewnętrznie kilka źródeł przerwania?). Jak pamiętam z 7 przerwań w PC AT jedno czy dwa były już zajęte. Zostawało 5. Więcej źródeł miał chociażby C-64! Ale tam mądrze wybrano zgłaszanie poziomem! XT miał "aż" 15 linii ale nadal były problemy. Dopiera PC z PCI miało zrobione przerwania w "normalny" sposób.
Jak przyjżysz się konstrukcji PC, jaka była beznadziejna, to zdziwisz się jakim cudem zdobył taką popularność?
Co był źle w PC? Wszystko:
- CPU: 8086, chyba gorszego na tamte czasy nie było CPU 16-bit.
- Przerwania juz wiesz.
- DOS: najgorszy istniejący.
- Cena: pierwsze PC 16kB RAM, "aż" 3 kolory: świeci, nie świeci, średnio świeci - słynny HERKULES, późniejsza CGA i podobne z "aż" 16 barwami w sytuacji gdy konkurencja miał od 32 do 256.
Później nie lepiej:
- "System" Windows 3.x: tak naprawdę nakładka na DOS, praktycznie bez multitaskingu, w tym czasie konkurencja oferuje prawdziwą wielozadaniowość.
- Win95/98: Ukrycie faktu, że to nakładka na DOS. Reklamowany jako pierwszy prawdziwy multitaskimg. Dwa kłamstwa, nie pierwszy (mac OS, Unix już dawno istniał jakieś 20 lat no chyba, że sensie pierwszy firmy Micro$oft) no i nie prawdziwy bo jeśli tak, to czemu system "zamiera" na nawet 30 sekund lub dłużej (nawet na 10 takie rzeczy się dzieją).
PC to po prostu szmelc! Produkty u$oft też.
Kod z delay to nie kod, to DEMO!
Możliwości sprzętowe uC trzeba wykorzystywać a nie /machać/. GPIO!
Jestem a usilnie chcę być amatorem to dwie różne rzeczy.

http://er-mik.prv.pl/projekty edw.php 
http://er-mik.prv.pl/projekty_avt.php
 
Odpowiedź
#10
Tak dla przypomnienia - mamy 2020 rok, fajnie powspominać, ale może lepiej trzymać się tematu?
 
Odpowiedź
  


Skocz do:


Przeglądający: 1 gości