priorytety przerwań w 51, nie działają jak powinny.

dziś troche zgłupiałem, W urządzeniu które robie zauważyłem subtelny błędzik
Przerwania nie śmigaja wg swojej kolejności. Załadowałem program do symulatora i faktycznie, przerwanie o najniższym priorytecie jest nie przerywalne- nie zależnie czy dziubne mu T0 lub INT0.

Ogólnie to chciałem uzyskac taki efekt: (od najniższego priorytetu) T1, INT0, T0. W programie wstawiłem "SETB IT0". Wg symulatora bit ten faktycznie zostaje ustawiony, lecz przerwania dalej swoje.

Czary?

Nie czary tylko jakiś błąd. Nic nie piszesz o rejestrze IP. Myśle, że ustawienie bitu PT0 załatwi sprawe. Bez kodu programu jest to wróżenie z fusów.

Na początku tak konfiguruje rejestry


Przerwania od T0 i INT0 zajmują kilka cykli. Krytyczne jest natomiast przerwanie od T1 gdzie multipleksuje wyświetlacz, sprawdzam klawiature i co jakiś czas odczytuje DS18b20. Timer ładowany jest wartoscią D8EFh.
Z najnowszych rzeczy jakie wyczaiłem to to ze T1 w momencie odczytu dallasa depcze sobie po ogonie (licznik sie przepełnia w trakcie obsługi przerwania) i na 100% ma to związek z moim problemem.
INT0 odpowiedzialne jest za wykrywanie zera sieci. T0 odlicza czas (kąt) załaczenia triaka. Efekt jest taki że gdy odczytywany jest dallas to bardzo często sie zdaża że wypadnie mi kilka impulsów synchronizacji z siecią, lub odliczeń kąta zapłony triaka. Na razie prubuje sprawdzic czy wypada przerwanie T0, czy INT0. Jeśli wywale obs. dallasa to wszytsko jest ok.

Nie mniej jednak, jeśli nawet najmniej ważne przerwanie na chwile się zapętli to przerwania o wyższym priorytecie powinne powinne sie wtrącic do pracy, chyba dobrze myślę?

Wyprostuje także sprawe, o której pisałem w pierwszym poście. Prace przerwań symulowałem na PCcie. Jeden symulator nie wchodził do żadnego przerwania (bez względu na priorytet) do puki nie zakończył aktualnie wykonywanego. Dziś załadowałem soft do innego symulatora. Ten z kolei robi wręcz przecinwie. Skacze do każdego przerwania bez względu na to które teraz wykonuje...

Cytat:

Jeśli wywale obs. dallasa to wszytsko jest ok

Ale nie czekasz bezczynnie ~750ms na dane z dallasa?? .

Co do symulacji tego wszystkiego proponuję zatrudnić Keila.

Nie, nie czakam. Co odpowiednią ilosć przerwań (czyli 1s. odcinki czasu) Neguje bit w zależnosci którego albo wysyłam rozkaz pomiaru temperatury, albo jej odczytu. Potem program bierze sie za reszte czynności

A keil jest bardziej zmyślny?. Ostatnim programem w jakim to testowałem to MIDE51

bolek napisał:

A keil jest bardziej zmyślny?.

Keil to jeden z lepszych (jak nie najlepszy) pakiet do 8051 . Ma ograniczenie do 2kB ale można bardzo dobrze sobie sprawdzić działanie newralgicznych punktów programu.

Po co SETB PX0? To w końcu co ma mieć wyższy priorytet INT0 czy T0. Nawet nie potrafie przewidzieć jak zadziała taka kombinacja
SETB PX0
SETB PT0

mój błąd, W praktyce jest tylko PT0.

Jeśli chodzi o to jak działa taka kombinacja, to księgi piszą że jest kilka priorytetów jest ustawionych to będą działać wg "standardowej" kolejności. czyli np IP=FFh da to samo jak IP=0

Zrobiłem kolejny eksperyment. Wywaliłem te wszystkie priorytety. Zamiast do INT0 podczepiłem sie do INT1. Czyli mam tutaj zachowaną kolejność zdażeń (taką jak chce). Niestety, nic mi to nie pomogło. Dalej gdy odczytuje dallasa reszte przerwań jest jakby zawieszona. ;/

Brak mi pomysłów

j/w oczekujesz jasnowidztwa. Daj kod to się zobaczy

jest i kod, jest on nieco rozwalony (poskracane pętle główne, pułapki), bo własnie dochodze co jest nie tak

W Keilu symulator działa bez sensu INT0 ma niższy priorytet od T1 dopiero SETB PX0 przywraca właściwą kolejność?????
Upewnij się czy napewno wchodzisz w procedurze LEDY do miejsca gdzie włączasz przewania INT0 i T0 ,jest to jedyne miejsce gdzie się to wykonuje.

Dziwne to symulowanie przerwań- kazdy program robi to jak chce
Wchodzi na 100% w procedure LEDY. Przerwania sa poprawnie wyłączane jak i wlączane. Czy procek (S52 jeśli chodzi o ścisłość) nie lubiu w przerwaniu długich procedur CALL lub JMP?
Na pewno problem znika jeśli wywale z pomiar temperatury, więc coś w tym jest.
Na próbe zmieniłem też wartosc jaką ładowany jest TH1, dałem na 0 więc nie bylo mowy o tym aby przerwanie się zapętlało. Nie pomogło, któreś z wyższych przerwań dalej wypadało
---------------------

Inne programy z podobnym układem przerwań symulują sie u Ciebie prawidłowo?.

Daleki jestem od twierdzenia, że program za 8000€ działa nie tak i nie jeszcze to nie wyszło (to nie jest Windows:D). Chyba czegoś nie wiemy?
Specjalnie napisałem program testowy i objawy mam podobne. Pisałem kiedyś podobny program na regulator pogodowy CO ale używałem wtedy RTX51 gdzie każde urz. peryferyjne były obsługiwane w osobnym wątku. Zniknęły wtedy problemy z obsługą "wolnych" urządzeń i pisaniem "przeźroczystych" procedur. RTX51 tiny nie zużywa dużo zasobów a prostota programu jest ogromna.
Jak dojdziesz do jakiś odkryć podziel się nimi.

to ja już nic nie rozumiem z twojego posta.
"że program za 8000€ działa nie tak i nie jeszcze to nie wyszło (to nie jest Windows:D). Chyba czegoś nie wiemy?"

Znaczy się że ja wiem o czyms, czego tu nie napisałem?. Nie wiem, ale na pewno nie "zapomniałem" o czyms z premedytacją.

Wychodzi na to że jednak ten keil nieco kłamie przy symulacji przerwań, skoro piszesz że sprawdziłeś inny soft i efekt jest podobny...

Dziś jeszcze troszke przy tym posiedze. Przerobiłem soft tak aby nie korzystać z T0. Zrobiłem sterowanie grupowe, a nie fazowe (tak jak do tej pory). No i Pan oscyloskop pokazał ze wszystko działa ok. Muszę zawęzić poszukiwania do procedury T0 i dallasa. Stos chyba odpada, z tego co widze to najwyżej dochodzi on do 19h, bity zaczynają sie od 20h. Powalczymy, zobaczymy

Hardcore jest niezły bo 51ka ma w sumie cztery zdażenie w czasie rzeczywistym, nie mniej jednak, według mnie są one na tyle luźne że powinna sie wyrobić.
No i wielo wątkowość to dla mnie na razie czarna magia. Może by jeszcze ktoś sprubował przesymulować działanie przerwań?

starob napisał:

W Keilu symulator działa bez sensu INT0 ma niższy priorytet od T1

Bo tak jest ustawione w programie .

Cytat:

Wychodzi na to że jednak ten keil nieco kłamie przy symulacji przerwań

Nic nie kłamie, u mnie symulacja jest prawidłowa, przerwanie o wyższym priorytecie przerywa to o niższym. Co do pozostałego kodu to sie nie wypowiadam bo go nie analizowałem.

[quote="markosik20"]

starob napisał:

W Keilu symulator działa bez sensu INT0 ma niższy priorytet od T1

Bo tak jest ustawione w programie .

Cytat:

gdzie tak jest?

Przepraszam, miałem na myśli T0

Nie chce zapeszać, ale sądze że działa.

Sprawa jest conajmniej dzwina, prócz ustawienia priorytetu od T0, trzeba było także ustawić priorytet od INT0 ;/

Teraz niech to ktoś wytłumaczy