On Wed, 13 Aug 2003, Jan-Erik Soderholm XA (TN/PAC) wrote:

> Jan-Erik.
>
>
> Vasile Surducan wrote:
> > With the remark I'm reseting the gpif after
> > a quite long delay ( a few instructions ), and never
> > saw a re-setting state for gpif.
>
> So you are reseting GPIF without reading GPIO at all ?
> Not even using btfsc or btfss to check witch pin changed ?


  I don't need to check which pin is because in my application I'm using
just one pin for irq on change.


>
> Interesting...
>
> >
> >> Also note that there is a race condition
> >> (as noted in the grey box on side 20
> >> of the data sheet) thay says that, if you
> >> are unlucky, you can miss a port change
> >> if it occures in the "start of th 2 cycle"
> >> when reading the GPIO port. The GPIF flag
> >> might not be set.
> >
> >
> >  Yes, but this is extremely rare situation.
> >  Interrupt on change can't usualy be used for
> >  detecting events having the pulse width
> >  comparable with machine cycle. So I wouldn't try that...
>
> It's not about short pulse widths, it's about if the next
> level change happens at the same time as the GPIO is read
> (Q2 cycle), *whenever* that is.
>
> Let's say you are monitoring 2 or 3 lines witch can change
> asyncronysly from each other. If they change fully at random,
> this race condition would happen *sometime*.
> And I don't see any workaround. In the solution I described
> earlier (double read of the GPIO), this condition can also
> happen in the second read, of course. Well, maybe one, using
> external curcuits to syncronize the edges so they do not
> happens at the Q2 cycle...


  This situation is difficult even to be catched on the scope,
so how are you able to verify the whole Microchip story ?

>
> Jan-Erik.
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body