[elektro] PIC 16 bit megszakítás

[potyo]

Nem volt dolgom 16 bitessel, de logikus lenne, hogy ugyanolyan prioritású
megszakításba mégegyszer nem futhat bele, amíg ki nem ért az előzőből. De a
TXIF bitet szerintem nem kell kézzel törölni, hanem amikor írsz valamit a
TXREG regiszterbe, akkor sajátmagától törlődik a TXIF bit. Sőt, lehet, hogy
azzal, hogy kézzel törlőd a bitet, ha kétbájtos a hardveres puffer, akkor
épp elrontod a működést.

C-ben van a program? Esetleg volatile-nak deklarálni az index változót?
Mindenesetre ne mi találgassunk már, hogy mit csináltál rosszul, mutasd meg
a kódrészletet, aztán abból tudunk valamit mondani.

2014. október 31. 11:19 Zoltán Balla írta, <sdrlab at yandex.ru>:

> Sziasztok!
>
> Adott egy 16 bites DsPIC környezet. Van egy megszakítás, a soros port
> adására, mely szerint ha kiürült a FIFO, megszakítást generál. Ekkor a
> kiszolgáló rutin inkrementál egy tömböt cimző index változót, ha az
> kisebb, mint a max érték, és újabb byte-ot helyez a FIFO-ba. A flag
> törlése a megszakításkezelő elején történik.
> A tünet a következő: minden tömb(adat) küldése inicializálásakor az
> index nem incrementálódik, az az ugyanazt az indexű byte-ot küldi el
> mindig konzekvensen.
> Elemezve az egyetlen értelmes feltételezés az volt, hogy mivel a rutin
> elején van törölve a flag, így a megszakítási feltétel újra fennáll, és
> azonnal belép újból a kiszolgáló rutinba. Így még az index
> inkrementálása előtt mégegyszer bekerül a FIFO-ba ugyanaz a címzett
> byte. Az utána következő adatok már jól mennek, végig.
> A kérdésem az, létezik az, hogy beléphet ugyanabba a megszakításkezelőbe
> úgy, hogy még az előző nem lett kiszolgálva ? Emlékeim szerint, mintha
> hardveres tiltás kéne, hogy legyen addig, amíg ki nem lép a megszakítási
> rutinból... Vagy ez csak a 8 biteseknél volt így ?
>
> Zoli
>
> -----------------------------------------
>           elektro[-flame|-etc]
>