nse Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 Jądra zaawansowanych systemów, dopuszczają zagnieżdżanie się przerwań w sobie, AVR'y nie maja takich zasobów. Gdy wystąpi przerwanie w przerwaniu, to procesor odkłada sprzętowo adres, ustawia wskaźnik stosu i ustawia flagę zgłoszenia przerwania, wtedy AVR po skończeniu obsługi i wykonaniu jednego rozkazu ASM w pętli głównej zaczyna realizacje zgłoszonego przerwania. A w tym przykładzie czas reakcji na zgłoszenie przerwania jest losowy. Oczywiście ten problem można rozwiązać w prosty sposób, ale nie mam obowiązku poprawiania baboli w cudzych programach. Przedstawiłem swoje sugestie i to wystarczy. Programowanie to nie ctrl+C i ctrl+V 🙂 Przykro mi że w czyjejś ocenie okazały się bezwartościowe. Po prostu widzę że nie ma sensu by się tu pocić, nikt mi za to nie płaci. Cytuj Link do komentarza Share on other sites More sharing options...
Elvis Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 nse, masz jak najbardziej rację. Tak wygląda standardowa procedura obsługi przerwania. Jednak to co zrobił Sabre właśnie przypomina obsługę przerwań z większych procesorów. Zamiast tradycyjnie wracać z przerwania, on po prostu ręcznie uruchamia przerwania ponownie i kontynuuje działanie. Wtedy kolejne przerwania mogą być ponownie zgłaszane, nawet jeśli kod rozpoczyna się od kontekstu przerwania. Właśnie to jest fajne - mamy zupełnie inne niż typowe użycie przerwań. Nawet jeśli to skomplikowane, to daje okazję do poznania zaawansowanych technik obsługi przerwań. Cytuj Link do komentarza Share on other sites More sharing options...
Sabre Czerwiec 16, 2016 Autor tematu Udostępnij Czerwiec 16, 2016 jnk0le, napisałem, że teraz z włączoną opcją "nosave" (niezależnie od słuszności jej użycia) mikrokontroler przestaje reagować na przerwania po wejściu do 11 efektu i gdy zdefiniuję na początku programu, że diod jest 15. Gdy zdefiniuję 100 diod to zawiesza się dopiero po kilku tysiącach przerwań. EDIT: Oczywiście ten problem można rozwiązać w prosty sposób, ale nie mam obowiązku poprawiania baboli w cudzych programach.Przedstawiłem swoje sugestie i to wystarczy. Programowanie to nie ctrl+C i ctrl+V 🙂 Przykro mi że w czyjejś ocenie okazały się bezwartościowe. Po prostu widzę że nie ma sensu by się tu pocić, nikt mi za to nie płaci. Jak masz takie podejście to naprawdę nie powinieneś udzielać się na żadnych forach. Bądź mężczyzną i przestań żegnać się 10 razy tylko odejdź bo Twoja obecność tutaj niczego nie wnosi do meritum sprawy a wprowadzasz tylko niepotrzebne zamieszanie. Cytuj Link do komentarza Share on other sites More sharing options...
Chumanista Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 Sabre, masz 2 chińskie płytki, nie? Może wylutuj procesor z jednej i wlutuj ten z TME a następnie wgraj na obydwie identyczny kod. To pozwoli wyizolować wszelkie różnice poza procesorem. Cytuj Link do komentarza Share on other sites More sharing options...
Polecacz 101 Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Produkcja i montaż PCB - wybierz sprawdzone PCBWay! • Darmowe płytki dla studentów i projektów non-profit • Tylko 5$ za 10 prototypów PCB w 24 godziny • Usługa projektowania PCB na zlecenie • Montaż PCB od 30$ + bezpłatna dostawa i szablony • Darmowe narzędzie do podglądu plików Gerber Zobacz również » Film z fabryki PCBWay
nse Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 nse, masz jak najbardziej rację. Tak wygląda standardowa procedura obsługi przerwania. Jednak to co zrobił Sabre właśnie przypomina obsługę przerwań z większych procesorów. Zamiast tradycyjnie wracać z przerwania, on po prostu ręcznie uruchamia przerwania ponownie i kontynuuje działanie. Wtedy kolejne przerwania mogą być ponownie zgłaszane, nawet jeśli kod rozpoczyna się od kontekstu przerwania. Właśnie to jest fajne - mamy zupełnie inne niż typowe użycie przerwań.Nawet jeśli to skomplikowane, to daje okazję do poznania zaawansowanych technik obsługi przerwań. Przerwania w procesorach są po to by reakcja programu na nie odbywała się w możliwie jak najkrótszym czasie i ten czas reakcji mieścił się w jakiś ustalonych normach. Inaczej działają procesory których rdzenie są taktowane GHz, a inaczej jak są taktowane MHz. Zaawansowane systemy obsługiwane są przez procesory wielordzeniowe i nie można "ideologi chmury" przenosić do małych 8 bitowych procesorów. Tak na marginesie: Hehe, kiedyś kolega jak został w ręku z kilkoma drutami i nie miał pojęcia jak je podłączyć, to sobie wymyślił taką filozofie ( połączę je wszystkie razem, a inteligentne elektrony same będą wiedziały dokąd płynąć ) 😃 Cytuj Link do komentarza Share on other sites More sharing options...
Elvis Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 nse, koniec procedury obsługi przerwania nie musi kończyć się powrotem do przerwanego kodu. Może nastąpić przełączenie do innego zadania, albo obsługa np. błędu, czy wręcz restart urządzenia. W przypadku AVR nie jestem w 100% pewny, ale o ile rozumiem wystarczy wyzerować flagi przerwania i można odbierać kolejne. W przypadku kodu Sabre oznacza to że wejście do funkcji realizującej efekty jest końcem pracy w przerwaniu. W przypadku "większych" procesorów, np. ARM sytuacja jest podobna chociaż nieco bardziej skomplikowana. Program musi odblokować kontroler przerwań, zanim następne będą mogły być obsługiwane. Często robi się ciekawą sztuczkę - program zapisuje stan obsługiwanego przerwania, a następnie przełącza się w normalny tryb pracy i wywołuje program obsługi przerwania w zwykłym kontekście. W takiej sytuacji przerwanie o wyższym priorytecie może być zgłoszone zanim aktualne się zakończy. Nic nie stoi na przeszkodzie, żeby podobmy mechanizm działał na AVR. W tym jednak przypadku mamy dużo łatwiejszą opcję - każde przerwanie jest niema restartem procesora, tylko globalne zmienne są zachowywane. 1 Cytuj Link do komentarza Share on other sites More sharing options...
Sabre Czerwiec 16, 2016 Autor tematu Udostępnij Czerwiec 16, 2016 Sabre, masz 2 chińskie płytki, nie? Może wylutuj procesor z jednej i wlutuj ten z TME a następnie wgraj na obydwie identyczny kod. To pozwoli wyizolować wszelkie różnice poza procesorem. Na szczęście nie muszę wylutowywać, w lampkach mam megę w DIPie, przełożę ją do płytki propoxa i podłączę tą płytkę z 15 diodami. To wykluczy mam nadzieję już wszystkie wątpliwości. Zgram tylko z niej bina gdyby miało się okazać, że to coś nie tak z kompilatorem jest. Wgram do niej dokładnie ten sam program, który aktualnie jest na medze z Chin. Cytuj Link do komentarza Share on other sites More sharing options...
nse Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 nse, koniec procedury obsługi przerwania nie musi kończyć się powrotem do przerwanego kodu. Może nastąpić przełączenie do innego zadania, albo obsługa np. błędu, czy wręcz restart urządzenia.W przypadku AVR nie jestem w 100% pewny, ale o ile rozumiem wystarczy wyzerować flagi przerwania i można odbierać kolejne. W przypadku kodu Sabre oznacza to że wejście do funkcji realizującej efekty jest końcem pracy w przerwaniu. W przypadku "większych" procesorów, np. ARM sytuacja jest podobna chociaż nieco bardziej skomplikowana. Program musi odblokować kontroler przerwań, zanim następne będą mogły być obsługiwane. Często robi się ciekawą sztuczkę - program zapisuje stan obsługiwanego przerwania, a następnie przełącza się w normalny tryb pracy i wywołuje program obsługi przerwania w zwykłym kontekście. W takiej sytuacji przerwanie o wyższym priorytecie może być zgłoszone zanim aktualne się zakończy. Nic nie stoi na przeszkodzie, żeby podobmy mechanizm działał na AVR. W tym jednak przypadku mamy dużo łatwiejszą opcję - każde przerwanie jest niema restartem procesora, tylko globalne zmienne są zachowywane. Właściwie można tak zrobić, wykasować wewnątrz flagę zgłoszenia i tak też robiłem w niektórych przypadkach, można zmniejszyć wskaźnik stosu. Tylko po co na siłę trzymać się wnętrza procedury przerwania któremu jest przypisany konkretny podprogram ? Ok robimy jak proponujesz, ta jak wewnątrz przerwania odróżnić że przerwanie wystąpiło z innego powodu niż to pierwsze by zastosować inną procedurę jego obsługi ? Właściwie z takim podejściem kolejne przerwanie wywoła inny podprogram, miało by to sens gdyby zastosować licznik występowania przerwań i każde kolejne wymagałoby innej procedury. Ale w tym konkretnym przypadku takiego wymogu nie ma 🙂 Co można udowodnić, jeśli się uparcie wali głową w mur ? Cytuj Link do komentarza Share on other sites More sharing options...
Chumanista Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 Sabre, chodzi mi o to że w ten sposób (o ile dobrze zrozumiałem) wciąż będziesz miał inne zasilanie i inną płytkę. Czy chodzi ci o to że masz jedną w DIP z TME i jedną w DIP z Chin i odpalisz obydwie w tej samej płytce (Propoxa)? Cytuj Link do komentarza Share on other sites More sharing options...
nse Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 @Elvis: W ten sposób można kolejno multipleksować różne wątki programu, i jeśli będzie to robione wystarczająco szybko to będzie taki efekt jakby one działały równolegle 🙂 Cytuj Link do komentarza Share on other sites More sharing options...
Sabre Czerwiec 16, 2016 Autor tematu Udostępnij Czerwiec 16, 2016 Trochę się wyjaśniło. Wyciągnąłem mikrokontroler z lampek choinkowych i zaprogramowałem tym nieszczęsnym kodem. Jest to samo, tzn. wszystko działa prawidłowo niezależnie od tego czy jest dodane "nosave" czy nie. Jedyna różnica polega na definicji ilości diod. Program działa prawidłowo gdy zdefiniuję 100 diod w programie a przestaje reagować na przerwania na 11 podprogramie, gdy zdefiniuję na początku tych diod 15. Tak więc pies jest pogrzebany prawdopodobnie w kodzie i nie zależy od użytego mikrokontrolera. Musi być jakaś różnica w tym jednym miejscu czy definiuję 100 diod czy tylko 15, bo tylko to w tym momencie powoduje brak reakcji na przerwania, które żeby nie było szły co 5 sekund z innej płytki. EDIT: Zmodyfikuję za chwilę kod o to co pisał Elvis i dam znać. EDIT2: Nie mogę dodać tego kawałka od Elvisa, dostaję komunikat: Label not found (RAMEND) Cytuj Link do komentarza Share on other sites More sharing options...
Elvis Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 RAMEND było z jakiegoś przykładu w necie 🙁 Ale może w helpie albo pod debuggerem Bascom-a możesz zobaczyć gdzie domyślnie tworzony jest stos? To sprawdzenia wystarczy po prostu wpisać wartość zamiast RAMEND. Trochę o stosie w Bascomie znalazłem tutaj: http://www.mcselec.com/index.php?option=com_content&task=view&id=286 Cytuj Link do komentarza Share on other sites More sharing options...
jnk0le Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 mikrokontroler przestaje reagować na przerwania po wejściu do 11 efektu i gdy zdefiniuję na początku programu, że diod jest 15. Gdy zdefiniuję 100 diod to zawiesza się dopiero po kilku tysiącach przerwań. Jak na razie to widziałem tylko kod do efektu 6. Ale, po głębszej analizie tego co już wrzuciłeś wynika że: 1. Bit_send nie powinien być wywoływany z włączonymi przerwaniami szczególnie że pakuje 3 adresy powrotu na stos (+własny oczywiście). 2. Przed włączeniem przerwań należy zdjąć ze stosu adres powrotu przerwania jak i wywołanej funkcji, chyba że funkcje umieścisz bezpośrednio w przerwaniu. pop r0 pop r0 4. To że z NoSave nie wiesza się to tak łatwo, to raczej kwestia tego że kod już nie zrzuca 32 rejestrów na stos przy każdym wejściu w przerwanie. 5. Różnice w działaniu atmegi z ali i tme wynikają z tego że przepełnienie stosu jest najprawdopodobniej sytuacją niezdefiniowaną, a żółtki mają ogromny problem z kopiowaniem, takowych. Możliwości w tej sytuacji jest kilka: - powrót wskaźnika stosu na swój początek - zatrzymanie się wskaźnika stosu (Bit_send przestaje działać) - pisanie po przestrzeniu IO (Bit_send przestaje działać) - całkowita zwiecha 6. Jakiś babol w 11 efekcie. Bez .lss ciężko mi wywróżyć coś więcęj. Cytuj Link do komentarza Share on other sites More sharing options...
Elvis Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 O ile widzę stos jest na końcu pamięci RAM, więc możesz spróbować tak: ldi r16,0xff out Spl,r16 ldi r16,0x7f out sph,r16 Cytuj Link do komentarza Share on other sites More sharing options...
deshipu Czerwiec 16, 2016 Udostępnij Czerwiec 16, 2016 5. Różnice w działaniu atmegi z ali i tme wynikają z tego że przepełnienie stosu jest najprawdopodobniejsytuacją niezdefiniowaną a żółtki mają ogromny problem z kopiowaniem, takowych. Chinczycy nic nie skopiowali, to jest dokładnie taki sam mikrokontroler, jak w nie-chińskich (a raczej Chińskich, ale kupionych przez pośredników) wersjach. Jak się już wyjaśniło, dokładnie ten sam problem występuje z mikrokontrolerem zakupionym w TME, tylko nie było tego widać, bo miał 100 diod. Cytuj Link do komentarza Share on other sites More sharing options...
Pomocna odpowiedź
Dołącz do dyskusji, napisz odpowiedź!
Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!