[elektro] PIC 16 bit megszakítás

[elight at gmail.hu]

Szia,


egy szabad ,  (vagy ideiglenesen szabaddá tett)
portláb és egy oszcilloszkóp , vagy még jobb ,
egy analizátor   lehet a barátod a kinyomozásban.
Legalább is igy szoktuk..
A debugok az INT nyomozásnál kevésbé hatékonyak..
A gyanus ágak elején , végén beteszel egy - két , három .. etc ..
egymásutáni gyors pulzust..  azután lehet tudi, melyikben
hol mennyit tartózodik és kiszáll vagy nem ..
Ha esetleg több szabad bited van , az meg már egyenesen dölux..

A másik a chip doksijának olvasgatása az érintett
( vagy nem érintett : ) részeken.
Mer a PIC nél már volt olyanom  is hogy
a 178 oldalon volt még egy bit aminek egyébként
látszólag  semmi köze   de mégis bejátszik..

Üdv István


2014-10-31 11:19 keltezéssel, Zoltán Balla írta:
> 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]
>