logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmega8 - kilka przerwań na INT0

Mgli 05 Sty 2011 00:24 4639 37
REKLAMA
  • #1 8959432
    Mgli
    Poziom 9  
    Witam!

    Mam drobny problem - muszę zrealizować kilka różnych przerwań na INT0. W tym celu zrobiłem układ jak na rysunku poniżej, ale powiedzieli mi, że to nie będzie działać...

    Atmega8 - kilka przerwań na INT0

    Te 5 linii pochodzi od kilku enkoderów - wykrywanie ma być przy narastającym zboczu. W obsłudze przerwania ma to sprawdzać która linia była tak naprawdę wykorzystana i w zależności od tego obsługiwać odpowiedni rejestr.

    Proszę o w miarę szybkie odpowiedzi:)
  • REKLAMA
  • Pomocny post
    #2 8959447
    mirekk36
    Poziom 42  
    Mgli napisał:
    powiedzieli mi, że to nie będzie działać...


    Ja się nie dziwię, że tak powiedzieli.

    A z ciekawości zapytam cię w oparciu o co tworzysz takie schematy? czy dobierasz elementy na nich oraz ich podłączenia tak całkiem przypadkowo? losowo? czy jak?

    Może jednak powinieneś całkowicie odwrócić problem i pytanie? czyli zapytać jak zrealizować wykrywanie czegoś tam od jednego z wielu enkoderów w oparciu o jedną linię INTx ?

    Przy czym warto opisać dokładniej ideę jaka ci przyświeca bo może się okazać, że to co tu chcesz zrealizować można np całkiem inaczej i prościej.
  • #3 8959486
    Mgli
    Poziom 9  
    Okej, co chcę osiągnąć. Te dwa enkodery + przycisk (łącznie 5 sygnałów) sterują pracą mojego modelu (samochód 4x4). Muszę wykrywać sygnał lewo/prawo na obu (wiadomo, czy najpierw zgłosi się A potem B czy B potem A) + przycisk. Chcę to zrobić na przerwaniu bo odpytywanie linii jest bez sensu, gdy może przyjść np. jeden sygnał na minutę.

    Pytam więc: Jak zrealizować wykrywanie z wielu enkoderów w oparciu o jedną linię INTx? Bardzo proszę?

    Co do ciekawości: elementy były faktycznie wybrane losowo: nie chciało mi isę w eaglu dociągać innych bibliotek, a chodziło mi jedynie o zrobienie sumy na drucie za pomocą diod. Nie mam wielkich doświadczeń z elektroniką, myślałem że zadziała.
  • #4 8959503
    mirekk36
    Poziom 42  
    Nie no jeśli chodzi o mnie to chciałem się upewnić co do założeń bo w związku z przedstawionym schematem wydawało mi się bardzo niejasne.

    Ale ok - to teraz zauważ, że zakładając iż chcesz odseparować sygnały diodami, to musisz przyjąć założenie, że wejście INT będzie w stanie wysokim poprzez np podciągnięcie programowo wewn. rezystorem do VCC. A zatem możesz wykrywać zmianę stanu z wysokiego na niski i wtedy musisz podłączyć diody odwrotnie przecież.

    A jeśli pasuje ci bardziej odwrócenie tego czyli reakcja na narastające zbocze to możesz np wstawić tu jakąś bramkę (za diodami) do wejścia INT żeby to zmienić i wtedy też możesz inaczej aktywować wejście int czyli swoim zboczem narastająycm.

    albo coś w ten deseń ..... a na końcu w procedurze obsługi przerwania sprawdzać stan tych linii od enkoderów jeśli nad nimi panujesz programowo.
  • #5 8959513
    Mgli
    Poziom 9  
    Zakładając, że płytki nie chce mi się zmieniać, i wykrywanie opadającego zbocza mi pasuje, wystarczyłoby ustawić w programie INT na stan wysoki i diody na odwrót podłączyć?

    Początkowo myślałem o bramce, ale rozmyśliłem się (diod mam pod dostatkiem).
  • #6 8959552
    mirekk36
    Poziom 42  
    Mgli napisał:
    Zakładając, że płytki nie chce mi się zmieniać, i wykrywanie opadającego zbocza mi pasuje, wystarczyłoby ustawić w programie INT na stan wysoki i diody na odwrót podłączyć?
    .


    No dokładnie, tylko przypadkiem nie zwykłych diod prostowniczych tylko jakichś shottky o małym spadku napięcia, najlepiej.

    Tyle że pin INT ustawiasz jako WEJŚCIE i wysyłasz na ten pin JEDYNKĘ co spowoduje podciągnięcie do VCC. Wtedy jeśli na którejś linii pojawi się ZERO to masz zbocze opadające i skok do przerwania.
  • #7 8959582
    asembler
    Poziom 32  
    Powiedz czy używasz usypiacza procesora? bo jezeli nie to po co sobie tak utrudniać a te kilka diodek zostawić na później
  • #8 8959955
    Mgli
    Poziom 9  
    Wiem że zwykłych nie, akurat miałem przygotowane Shottky'ego na to.

    Nie używam usypiacza procesora. Po co, jeśli będę miał około 1000 przerwań na sekundę (z impulsatora - mierzenie prędkości).
  • REKLAMA
  • #9 8960128
    sulfur
    Poziom 24  
    Proszę także zauważyć, że jeżeli impulsator w konkretnym położeniu zwiera do konkretnego potencjału, to się okaże, że na INT0 występuje długotrwale potencjał masy. Jeden impulsator tak stoi, drugi się obraca, ale jedynki nie wymusi, bo ściąganie do masy ma "pierwszeństwo". Moim zdaniem nawet schemat po poprawkach kolegi mirekk36 jest błędy i działać nie będzie.
  • #10 8960148
    dondu
    Moderator na urlopie...
    Mgli napisał:
    Nie używam usypiacza procesora. Po co, jeśli będę miał około 1000 przerwań na sekundę (z impulsatora - mierzenie prędkości).

    Dla treningu, doświadczenia, nawyku i Matki Ziemi :D
    To tak proste, że warto do co najmniej IDLE MODE.
  • #11 8960232
    mirekk36
    Poziom 42  
    sulfur napisał:
    Jeden impulsator tak stoi, drugi się obraca, ale jedynki nie wymusi, bo ściąganie do masy ma "pierwszeństwo". Moim zdaniem nawet schemat po poprawkach kolegi mirekk36 jest błędy i działać nie będzie.


    Racja w 100% ja już nawet tego nie rozpatrywałem w ogóle, zwróciłem tylko uwagę, że aby mieć przerwanie z kilku źródeł na jednym pinie to diody muszą być inaczej włączone i jak obsługiwać INT. Tak się to robi mniej więcej czasem w przypadku obsługi jakichś tam klawiaturek matrycowych. Dlatego sugerowałem aby autor zadał inaczej pytanie - to może podpowie ktoś coś konkretnego, kto bawił się różnymi enkoderami i ma jakieś sprawdzone pomysły na tego typu obsługę.

    Dodano po 4 [minuty]:

    dondu napisał:
    Dla treningu, doświadczenia, nawyku i Matki Ziemi :D
    .


    Kolega to chyba z partii zielonych hmmm ? ;)

    Ja przyznaję bez bicia, że rzadko dbam niestety o matkę ziemię ;) jak już to o matkę baterię (chociaż to też poniekąd troska w jakimś promilu o matkę ziemię)

    Ale oczywiście nie oznacza to iżbym lansował takie podejście, wręcz odwrotnie, kolega dondu ma 100% racji i popieram ;)
  • #12 8960606
    szelus
    Poziom 34  
    Zamiast tak kombinować, to może najprościej będzie zmienić procesor na Atmega88 i wykorzystać przerwanie od zmiany stanu pinu (dowolnego)?
  • #14 8960672
    SylwekK
    Poziom 32  
    Jeśli procek nie jest usypiany to myślę, że troszkę bez sensu jest korzystanie z tego przerwania. Został bym przy bezpośrednim badaniu pinów... chyba że czegoś nie zrozumiałem.
  • #15 8960686
    asembler
    Poziom 32  
    No własnie o tym myślałem. zwykłe skanowanie stanów pinów a ze 1000 na sek to nie tak dużo. Skanowanie w przerwaniu jest proste do napisania szczególnie że częstotliwośco od impulsatorów bedą malutkie.
  • REKLAMA
  • #16 8962193
    Mgli
    Poziom 9  
    Ale że jak? Bo ja chciałem skanować piny w przerwaniu :P Tylko chciałem mieć po prostu sygnał utworzony z tych pinów. Uważacie że do obsługi tego wystarczyłoby w samej pętli programu skanować, bez tych diod? Znacznie by mi to pracę ułatwiło :)
  • Pomocny post
    #17 8962324
    janbernat
    Poziom 38  
    Polling- czyli odpytywanie.
    Pojedyńczych pinów na tyle często żeby ich stan zmieniał się kilka-kilkadziesiąt razy wolniej niż to odpytywanie.
    Ponieważ procesor jest szybki a sygnały na pinach zmieniają się zwykle wolno to tak się robi.
    W głównej pętli- raczej nie w przerwaniu.
    Oczywiście to trzeba oszacować albo czasem dokładnie obliczyć- zależy od częstotliwości pracy procesora i sygnałów.
    W AVR-GCC są makra:
    if(bit_is_set(x,y))
    if(bit_is_clear(x,y))
    rejestr,bit
  • #18 8962360
    Mgli
    Poziom 9  
    Ok, dzięki wszystkim, tak zrobię. Sporo pracy mi to oszczędzi, nie mówiąc o skomplikowaniu płytki.
  • Pomocny post
    #19 8962496
    asembler
    Poziom 32  
    Raczej jednak w przerwaniu bo zabezpiecza to przed zgubieniem impulsów.

    Dodano po 1 [minuty]:

    W przerwaniu od jakiegoś licznika oczywiście
  • #20 8962690
    janbernat
    Poziom 38  
    W przerwaniu od licznika nie zabezpieczy.
    W pętli głównej też nie zabezpieczy- przed zgubieniem impulsów.
    Wystarczy dać jeszcze jedno przerwanie od czegokolwiek z ulubionym delay_ms(100) i zgubi.
    Ale przy "normalnie" napisanym programie trzeba obliczyć czasy.
    Prolog- odłożenie na stos itp.
    Obsługa przerwania.
    Epilog- powrót ze stosu itp.
    A ile czasu trwa to makro- nie wiem.
    No ale jak zawsze- trzeba obliczyć i sprawdzić.
  • #21 8962772
    asembler
    Poziom 32  
    Dlaczego nie zabezpieczy w przerwaniu od licznika?
    Przeciez z nazwy "przerwanie" musi być obsłużone.
    No chyba ze uzytkownik bedzie złośliwy i wyłączy przerwania lub napisze dlugą procedure od innego przerwania nie odblokowywując na początku jej wykonywania przerwan.
    Wystarczy dać w przerwaniu ulubiony delay(100ms) -- idąc dalej to wystarczy wyłączy napiecie od procesora i też zgubi.
  • #22 8962813
    dondu
    Moderator na urlopie...
    Pytanie podstawowe na ile istotne jest niegubienie impulsów?
    W pokrętle w radio nie ma większego znaczenia, czy się gubi jakiś impuls, więc to autor tematu musi zadecydować, czy to warunek "być albo nie być".
    Oczywiście pomijam problem wykrywania kierunku kręcenia.
  • #23 8962834
    janbernat
    Poziom 38  
    No właśnie o tym pisałem.
    Jak odblokuje przerwania w innym przerwaniu- to jest ryzykant albo dokładnie wie co robi.
    O stosie nie wspomnę.
    Użytkownicy czasem robią sobie "na złość" i w innym przerwaniu wstawiają delay() albo pętlę oczekującą na cokolwiek.
    Nic nie zabezpieczy przed samodestrukcją użytkownika.
    Ja podałem tylko dwa przykłady- dajcie więcej.
    Np. oczekiwanie na zakończenie przetwarzania przez DS temperatury- czy w przerwaniu czy też w głównej pętli.
  • REKLAMA
  • #24 8962878
    dondu
    Moderator na urlopie...
    janbernat napisał:
    Ja podałem tylko dwa przykłady- dajcie więcej.

    Ja jestem zwolennikiem wykorzystywania przerwań gdzie się da (ale z rozsądkiem) oraz usypiania procesora. Uważam, że to dobry nawyk, ale nie oznacza, że inne rozwiązania uznaję za złe. Wszystko ma wady i zalety albo raczej plusy i minusy.
  • #25 8962968
    janbernat
    Poziom 38  
    Samochód 4x4 raczej nie oszczędza zasilania.
    Tak że w tym wypadku usypianie/budzenie procesora to niewiele oszczędzi.
    A dynamika jazdy się liczy.
  • #26 8963052
    asembler
    Poziom 32  
    janbernat napisał:
    Samochód 4x4 raczej nie oszczędza zasilania.
    Tak że w tym wypadku usypianie/budzenie procesora to niewiele oszczędzi.
    A dynamika jazdy się liczy.

    A ile razy zapomni wyłączyc zasilanie wtedy usypianie procesora zabezpieczy przed całkowitym rozładowanie, baterii.
    Nie rozumiem czy funkcja delay nawet 10sek w programie głównym wyłącza przerwania?
    Jeżeli przerwania by się gubiły yo nie można by zrobic zegaraka na procesorze a takąmożliwośc daje producent.
    Ja by raczej nie gdybał jak użytkownik może spiep...ć ale raczej jak napisa powinien dobrze.
  • #27 8963175
    janbernat
    Poziom 38  
    Nie w głównym a raczej:
    w innym przerwaniu wstawiają delay() albo pętlę oczekującą na cokolwiek.
    P.S.
    Poczekajmy co Autor wymyśli.
  • #28 8963207
    asembler
    Poziom 32  
    No to trzeba powiedziec raz na jutro że czas trwania powinien wynosić uS a nie sekundy inaczej mówiąc być jak najkrótszy.
  • #29 8963415
    dondu
    Moderator na urlopie...
    janbernat napisał:
    A dynamika jazdy się liczy.

    Dynamika by była gdyby miał co robić, ale jeżeli procek się nudzi ...
    Jak pisałem wcześniej autor sam musi zdecydować.

    Dodano po 3 [minuty]:

    asembler napisał:
    Jeżeli przerwania by się gubiły yo nie można by zrobic zegaraka na procesorze a takąmożliwośc daje producent.

    Producent daje, Ty programujesz. Efekt końcowy zależy od Ciebie. A przerwania mogą się gubić z wielu powodów. Flaga przerwania od danego Timera jest jedna i jeśli kolejne przerwanie nąstapi przed rozpoczęciem obsługi poprzedniego to jedno zostanie zgubione. Innymi słowy nie ma licznika przerwań nieobsłużonych.

    Dodano po 2 [minuty]:

    asembler napisał:
    Nie rozumiem czy funkcja delay nawet 10sek w programie głównym wyłącza przerwania?

    Nie pytaj, tylko sprawdź bibliotekę delay.h. znajdziesz tam:
    _delay_ms(double __ms)
    {
    	uint16_t __ticks;
    	double __tmp = ((F_CPU) / 4e3) * __ms;
    	if (__tmp < 1.0)
    		__ticks = 1;
    	else if (__tmp > 65535)
    	{
    		//	__ticks = requested delay in 1/10 ms
    		__ticks = (uint16_t) (__ms * 10.0);
    		while(__ticks)
    		{
    			// wait 1/10 ms
    			_delay_loop_2(((F_CPU) / 4e3) / 10);
    			__ticks --;
    		}
    		return;
    	}
    	else
    		__ticks = (uint16_t)__tmp;
    	_delay_loop_2(__ticks);
    }
    

    Po analizie zauważysz, że nie ma blokady przerwań. Ale jeżeli użyjesz delay w przerwaniu to musisz pamiętać, że wywołanie przerwania automatycznie blokuje przerwania do momentu zakończenia aktualnego przerwania, chyba ze w tym przerwaniu włączysz przerwania :)
  • #30 8963669
    Fredy
    Poziom 27  
    Ten układ będzie jakoś tam działać - Tylko daj rezystory do masy na wszystkie wejścia włącznie z INtem.
    Potem w przerwaniu tylko robić skan portu i widać co zostało naciśnięte. Można użyć najzwyklejszych diód. Ma tylko jedną wadę, jeśli któraś z lini wymusi stan 1 na dłużej to wtedy zablokuje odczyt z innych lini.
    Można spróbować te stany zróżniczkować tak aby zlikwidować to ww. niedogodność.
    Lepiej i łatwiej byłoby gdybyś próbował wyłapać opadające zbocze.
REKLAMA