... have your PIE1 and eat it! - Page 1
Forum section: electronics / general

author: PerranOak
author_rank: Frequent Contributor
timestamp: May 14, 2020, 12:03:35 pm
content: I am running Timer 2 on a PIC16F1827.I looked in the datasheet and it said:22.2 Timer2/4/6 InterruptTimer2/4/6 can also generate an optional device interrupt. The Timer2/4/6 output signal (TMRx-to-PRx match) provides the input for the 4-bit counter/postscaler. This counter generates the TMRx match interrupt flag which is latched in TMRxIF of the PIRx register. The interrupt is enabled by setting the TMRx Match Interrupt Enable bit, TMRxIE of the PIEx register.However, the first time I ran it I forgot to set TMR2IE on PIE1(it's on PIE1 not PIE2 as implied above)but it still worked! I checked with the simulator on MPLAB X IDE and the whole of PIE1 was zero.Now I'm really confused. Do I need to set TMR2IE like it says in the datasheet or not? Experience tells me not but I wonder if this is automatically set somewhere else … or something(!) Also, GIE and PIEI of INTCON were all zero too - what I have learned is no longer true.Cheers.

author: JTR
author_rank: Regular Contributor
timestamp: May 14, 2020, 02:03:56 pm
content: If you want aninterruptto be generated then you need to set the corresponding TMRxIE bit. However, the TMRxIF bit is set on timer overflow regardless of whether an interrupt is generated or not. The TMRxIE does not need to be set for the TMRxIF to be set. This is to allow software polling methods to know when a timeout condition has been met.

author: PerranOak
author_rank: Frequent Contributor
timestamp: May 15, 2020, 10:19:14 am
content: Ah, right. I was thinking that an actual interrupt was needed but the programme just waits while TMR2IF is low then, on going high, it acts - a very simple prog.Thank you very much for pointing that out. I knew I was thinking wrongly!

author: itdontgo
author_rank: Regular Contributor
timestamp: May 16, 2020, 03:43:27 pm
content: Also a little trap is putting the test for TMR2IF before another interrupt in the ISR. So if an interrupt was generated by the other thing it goes off and does the TMR2IF before the true interrupt cause... even when the TMR2IE is not set.org 0x04btfsc PIEx,TMRxIFgoto TMRx thingbtfsc PIEy,TMRyIFgoto TMRy thing...it will always do TMRx thing first if the flag is set even if not enabled. I've often had to test the TMRxIE and skip over the TMRxIF test to avoid this.

author: mikerj
author_rank: Super Contributor
timestamp: May 16, 2020, 07:58:45 pm
content: Quote from: itdontgo on May 16, 2020, 03:43:27 pmThis is standard practice for the PICs that have only one or two interrupt vectors, you must always test the interrupt enable bit for each source if you are handling multiple interrupts.

author: ajb
author_rank: Super Contributor
timestamp: May 17, 2020, 12:26:07 am
content: Quote from: mikerj on May 16, 2020, 07:58:45 pmThis is how basically how every ARM MCU works too. If you had a separate ISR for every single interrupt the vector table alone would wind up being like 2kB. So there's only one vector per peripheral, and it's up to you to make sure the ISR handles the correct condition at the correct time.

author: PerranOak
author_rank: Frequent Contributor
timestamp: May 17, 2020, 10:15:27 am
content: Cheers all.

author: itdontgo
author_rank: Regular Contributor
timestamp: May 17, 2020, 12:11:00 pm
content: I don't do that on every interrupt I just put them in the order where it doesn't matter. It wastes page 0 memory and makes the ISR slower if you do it for everything.The only important ones in our comms firmware is the UART TXIF/E which I put last as it's least timing critical.

author: mikerj
author_rank: Super Contributor
timestamp: May 25, 2020, 11:40:25 am
content: Quote from: itdontgo on May 17, 2020, 12:11:00 pmHow can this prevent an interrupt getting serviced if e.g. you have temporarily cleared the IE bit in the main loop?