Searching \ for '[PIC] Transients when setting an output porttoits ' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=output
Search entire site for: 'Transients when setting an output porttoits '.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Transients when setting an output porttoits '
2008\11\03@135011 by olin piclist

face picon face
Wouter van Ooijen wrote:
>> Another part of this low end with which I'm not familiar..
>> If interrupts are disabled when one *would have* been delivered,
>> is it lost?
>
>> (to some stack-limited number, no doubt)?
>
> no

I think this needs some clarification.  Interrupt conditions are not stacked
anywhere in a PIC as Wouter says.  For each interrupt condition, the PIC has
a flag that indicates whether that condition is asserted or not.  These are
called the xxxIF bits.  The hardware sets these, and software action resets
them.  If another event occurs for a interrupt condition that is already
set, nothing more happens.

For example if a INT0 edge occurs but this interrupt is disabled for
whatever reason, then the INT0 interrupt flag bit gets set and no interrupt
occurs.  If the INT0 interrupt flag bit remains untouched and the INT0
interrupt is enabled, a interrupt will occur immediately.  If in the mean
time another INT0 event comes along, no state will be changed.  The number
of multiple INT0 events is not remembered, only that at least one has
occurred.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\04@070619 by Alan B. Pearce

face picon face
>If in the mean time another INT0 event comes along, no state
>will be changed.  The number of multiple INT0 events is not
>remembered, only that at least one has occurred.

The other bit that seems to confuse new comers, is that only one interrupt
can be serviced at a time, on the smaller PICs. But if another peripheral
has set its interrupt flag, and the interrupt enable for that flag is set,
then when the currently executing interrupt is finished, a new interrupt
will occur to service the other peripheral.

Where more than one peripheral can cause an interrupt, the order in which
the get serviced is set by the code in the interrupt routine that checks the
interrupt flags, looking for the flag that invoked the interrupt.

2008\11\04@072831 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote:
>> If in the mean time another INT0 event comes along, no state
>> will be changed.  The number of multiple INT0 events is not
>> remembered, only that at least one has occurred.
>
> The other bit that seems to confuse new comers, is that only one interrupt
> can be serviced at a time, on the smaller PICs. But if another peripheral
> has set its interrupt flag, and the interrupt enable for that flag is set,
> then when the currently executing interrupt is finished, a new interrupt
> will occur to service the other peripheral.
>
> Where more than one peripheral can cause an interrupt, the order in which
> the get serviced is set by the code in the interrupt routine that checks the
> interrupt flags, looking for the flag that invoked the interrupt.
>

And yet another thing that confuses new-commers, is that if you
do not check *both* xxIF and xxIE in your ISR in the case that you
uses multiple interrupt sources, then it's not enough to just clear
the IE bit for a particular interrupt to prevent that ISR part to
be run. The other interrupt (with xxIE set) will call the ISR.

So it's a good idea to check both xxIF and xxIE in the ISR.
So that later, when you re-set xxIE (and if you have left
the xxIF set of course), your ISR will be called...

Jan-Erik.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...