[NXP][LPCXpresso] - [1114/301] - niejednoznacznośc w interpretacji przerwania

Problemik z którym nie moge sobie poradzić
fioletowy to przebieg z detektora fazy
detektor fazy podpięty jest i skonfigurowany jako przerwanie do portu 3.1
żółty to zmiana stanu w przerwaniu (p3.1) wystawiona na P3.4

w programie mam uruchomiony RS232, ADC, Timer32, timer16, sisttick,


i priorytety przerwań:

zdjęcia obrazujące nie deterministyczny w wywołaniu przerwania









jeżeli ktoś potrafi tak skonfigurować procesor co by była w tym jakaś regularność byłbym szczęśliwy

dzięki za pomoc.

Spróbuj zamiast

ustawić zwykłą flagę informującą jaki był ostatni stan portu P3.4.

istotą przerwania jest

zliczanie
a to że wystawiłem sobie funkcje do zmiany stanu innego portu jest mam nadzieję jest pomijalne.

Jeśli dobrze zrozumiałem (a może źle zrozumiałem), to chodzi ci o tzw. jitter. Jeśli tak, to nowsze modele NXP, prawdopodobnie LPC12xx (o ile mnie pamięć nie myli) mają mechanizm sprzętowy umożliwiający eliminację drżenia dla przerwania o najwyższym priorytecie. Na zwykłym procesorze bez tego mechanizmu nic nie poradzisz, chyba, że pętla główna będzie pusta (procesor śpi i czeka na przerwanie) i nie będzie żadnych innych przerwań, również tych o niższych priorytetach.

jakieś inne pomysły gdyż nie chciałbym od razu skreślać procka

Pomysł już był - procesor idzie spać i nie ma żadnych innych przerwań oprócz tego najistotniejszego. Być może da się to zrobić tak, że wszystkie inne czynności uda się przenieść do obsługi tego przerwania, np. jeśli wiesz, że pomiędzy przerwaniami nie przepełnisz FIFO UARTa (bo np. ten, kto współpracuje z Tobą nie będzie nadawał danych bez opamiętania), to możesz obsługę UART przenieść do twojego jedynego przerwania. Podobnie inne rzeczy, byle byś tylko miał gwarancję, że zakończysz to w porę i zdążysz uśpić procesor przed następnym zdarzeniem.

Wiesz na czym polega problem? Na tym, że oprócz tego wszystkiego, co mamy w innych architekturach, a co w Cortex ogólnie wygląda lepiej (czyli opóźnienie odpowiedzi na przerwanie zależne od tego, co robi procesor w chwili nadejścia przerwania) w Cortex zgłoszenie przerwania o niższym priorytecie może czasem przyspieszyć obsługę przerwania o wyższym priorytecie.

A, i drobna prośba - zmień tytuł wątku na "niedeterministyczny czas odpowiedzi na przerwanie" - wtedy będzie wiadomo, o co chodzi.

Poprawka:
To, co widzę na zrzutach z oscyloskopu - to nie wygląda na jitter. Albo przebieg wejściowy jest za szybki dla mikrokontrolera, albo coś szwankuje z filtracją wejścia przy zgłoszeniu przerwania. Daj więcej kodu projektu, to może coś się znajdzie. Jaka jest częstotliwość procesora, a jaka przebiegu wejściowego? Jak zaprogramowałeś zgłaszanie przerwania od portu?

Jak są ustawione przerwania ? na zbocze? Jeśli na konkretne zbocze to po co sprawdzać fizyczny stan pinu. Jeśli sądzicie że te przesunięcie jest spowodowane czasem wykonywania przerwań to program jest źle napisany. Sądzę że problem leży po stronie błędnie napisanej aplikacji i założeń.

nic nie zmieniałem tak jak było w samplach do NXP LPC EXPRESSO tak zostało
jeżeli ma ktoś inną implementację przerwania to chętnie skorzystam z kodu.

tomasz1987 napisał:

istotą przerwania jest

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

AC_OK_Tick++;
    p3_1_counter++;
    GPIOIntClear( PORT3, 1 );  

zliczanie
a to że wystawiłem sobie funkcje do zmiany stanu innego portu jest mam nadzieję jest pomijalne.

Pomijalne, ale na podstawie tego "zółtego" przebiegu stwierdziłeś że jest problem.
Jeżeli przebieg ma 50Hz (detektor fazowy) to dla uC to "wieczność".
Nie wiem jak jest W Cortex M0 ale w M3 da się ustawić oprócz priorytetów tzw. grupy które pozwalają na wywłaszczenie innych przerwań.

ja chyba czegoś nie rozumiem
po to stosuje przerwanie co by nie było problemu z czasami

leci przebieg fazowy transformator mi to obniża transoptor z rezystorem wycina mi części przebiegów transooptor podciągnięty do zasilania uC żeby poziomy były takie same.

co tu jest problematyczne jak bym to przepisał na atmege to działało by bez ... mrygnięcia

a tu ni cholery nie działa sistick odbija mi między 40 a 60 impulsów w czasie w czasie 200ms(chyba już nie pamiętam) na oscyloskopie wszystko wygląda ok. Jednak nie zawsze przerwanie się wywołuje

tomasz1987 napisał:

ja chyba czegoś nie rozumiem
po to stosuje przerwanie co by nie było problemu z czasami

Tylko jak "siedzisz" za długo w jednym przerwaniu to nie obsłużysz innych.
Problematyczne jest Twoje podejście, myślisz jak inni że jak wezmą ARM'a to będzie taaaki szybki że ... i tak się "wyrobi".

ale te przerwanie nic nie robi już nawet za komentowałem zmiany stanu portu
tak więc porównuje tylko stany na rejestrach i ewentualnie je zmienia

to dużo??

Przyjrzyj się lepiej, które przerwania masz, ich obsługa zajmuje dużo czasu, a nie obniżyłeś im priorytetów. Priorytet 0 - domyślny - jest najwyższy. Na tym priorytecie powinno pozostać przerwanie portu, wszystkie inne powinny mieć niższe priorytety. Priorytetów masz do dyspozycji tylko 4 - od 0 do 3, ale oczywiście kilka przerwań może mieć ten sam priorytet.
A, i to chyba wyjaśnia sprawę, bo właśnie zobaczyłem, że masz w kodzie priorytet 4 i 5, czyli to samo co 0 i 1. No to mamy chyba winowajcę.
Proponuję zacząć od prostego testu - wyłącz wszystkie inne przerwania i sprawdź, jak chodzi to jedno, potem włączaj po jednym i zobaczysz, kto opóźnia.

Zresztą to jest pewien feler w CMSIS - argument funkcji ustawienia priorytetu jest modyfikowany w funkcji, nie wiem po co. Byłoby łatwiej uniknąć błędów, gdyby wartość napisana przez programistę była po prostu wpisywana do rejestru priorytetu. Ja nie używam SetPriority, tylko piszę wprost do rejestrów priorytetów.

markosik20 napisał:

tomasz1987 napisał:

istotą przerwania jest

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

AC_OK_Tick++;
    p3_1_counter++;
    GPIOIntClear( PORT3, 1 );  

zliczanie
a to że wystawiłem sobie funkcje do zmiany stanu innego portu jest mam nadzieję jest pomijalne.

Pomijalne, ale na podstawie tego "zółtego" przebiegu stwierdziłeś że jest problem.
Jeżeli przebieg ma 50Hz (detektor fazowy) to dla uC to "wieczność".
Nie wiem jak jest W Cortex M0 ale w M3 da się ustawić oprócz priorytetów tzw. grupy które pozwalają na wywłaszczenie innych przerwań.

Wieczność. Dokładnie, procesor poprawnie skonfigurowany (przypuśćmy PLL 20MHz) wykona w tym czasie (20ms) ~400k instrukcji. Nawet jeśli przerwanie z detektora nie jest obsłużone natychmiast to powinno być wykonane w czasie mikro sekund po rzeczywistym ustawieniu flagi przerwania (np: gdy wykona się inne przerwanie).


EDIT:

Umieszczanie np:
UARTSend((uint8_t *)"dn", 2 );//debug
w przerwaniu to podstawowy błąd. Być może masz w którymś z pozostałych taki "debug". W tych funkcjach często jest nieskończona pętla czekająca na flagi wysłania.

pragnę zauważyć że te debug'i są za komentowane mało tego mimo wszystko działa nawet z ta funkcją
na razie skorzystam z podpowiedzi BlueDraco
dzięki

Bawiąc się ustawianiem priorytetów zauważ że jeżeli są one w jednej grupie to poziom priorytetu decyduje o kolejności wywołania przerwania jeżeli przyjdzie ich kilka naraz w jednym, czasie. Nawet jak wykonuje się przerwanie o niższym priorytecie to i tak przerwanie o wyższym priorytecie musi poczekać aż obsługa tego niższego się skończy.

Problem nie leżał w programie tylko w nieukształtowanym sygnale wejściowym
bramka shmita załatwiła sprawę