Hi Vasile, I had a closer look at your program (and at the one of Rob). I saw your 20 ms delay (which Rob got rid of) before you clear the interrupt flag.
If I am right the Interrupt On Edge will no longer work if you did not process it before the next change on the pin. So your 20ms delay may be the cause of your problem. You should first clear the IOCAF0 as the first step. Stil the 20ms delay may give you problems so that may be the reason that the program of Rob does not have the problem. Kind regards, The other Rob ________________________________ Van: [email protected] <[email protected]> namens vsurducan <[email protected]> Verzonden: zondag 3 oktober 2021 10:32 Aan: [email protected] <[email protected]> Onderwerp: Re: [jallib] interrupt on change issue Hi Rob, thanks for your feedback. Your program somehow works, however in my level of understanding it is not based on pure IOC. Once the IOCAF_IOCAF0 is set ( a IOC occured) you are testing again the level of RDY_IN which should not happen... IOC is the transition of IOCAF0 or INTCON_IOCIF to high (and I'm assuming only that should be tested since the transition is defined by IOCAP/IOCAN). On the other hand, if you set only the detection of the rising edge ( IOCAP_IOCAP0 = high, IOCAN_IOCAN0 = low), RDY_OUT stayed indefinitely on high even on RDY_IN a positive edge occured, which seems wrong. According to the datasheet The "IOCIF Flag bit is read-only and cleared when all the Interrupt-On-Change flags in the IOCxF registers have been cleared by software", so that line can be commented, it will not be cleared. In fact this seems to be the real problem with the IOC module. I can send you a scope image for positive edge detection to see the lost IOCs on positive edges if that helps. best wishes, On Sat, Oct 2, 2021 at 1:02 PM Rob Hamerling <[email protected]<mailto:[email protected]>> wrote: Hi Vasili, On 01/10/2021 13.11, vsurducan wrote: Hi Rob and Rob, :) I've tried with or without ISR, with AND IOCAP reset or normal IOCAP reset. This IOC is erratic and has a lot of latency. The RDY_IN signal is 20ms square 50% duty cycle, the RDY_OUT signal has a latency most of the time...but sometimes has a 20mS pulse as it should. I'm using IOC for quadrature encoders on the wheels of an RC vehicle for navigation. With higher speeds the interrupt frequency is significantly higher then once per 20ms. Nevertheless this seems to work quite well (but latency is not a real issue). Below my test with a 12F1572 and modified version of your program on a little board with LEDs on pins A0, A1 and A2. The IOC of RDY_IN is handled by an interrupt routine. Both rising and falling edge interrupts are activated and RDY_OUT (in my setup on pin_A2) is controlled in the ISR as well. The input signal for RDY_IN is generated in the forever loop on pin_A1. When connecting pin_A0 with pin_A1 RDY_OUT is following RDY_IN neatly (visual observation shows all 3 LEDs blinking synchronously). Hopefully this is of some help to solve your issue. Regards, Rob. ================================= alias pin_RDY_IN is pin_A0 alias pin_RDY_IN_direction is pin_A0_direction pin_RDY_IN_direction = input OPTION_REG_WPUEN = 0 WPUA_WPUA0 = 0 ; pull-up disabled on RA0 alias pin_RDY_OUT is pin_A2 alias pin_RDY_OUT_direction is pin_A2_direction pin_RDY_OUT_direction = output pin_RDY_OUT = low alias pin_TRIGGER is pin_A1 pin_A1_direction = OUTPUT pin_TRIGGER = low -- main program INTCON_GIE = high INTCON_IOCIE = high -- enable IOC interrupts IOCAP_IOCAP0 = high -- enable positive edge interrupts RDY_IN -- enable negative edge interrupts RDY_IN procedure IOC() is pragma interrupt if INTCON_IOCIF then -- IOC interrupt if IOCAF_IOCAF0 then -- edge interrupt on RDY_IN if pin_RDY_IN then -- was a positive edge pin_RDY_OUT = high else -- negative edge pin_RDY_OUT = low end if IOCAF = IOCAF & 0xFE -- clear IOCAF0 end if INTCON_IOCIF = 0 -- reset IOC interrupt flag end if end procedure forever loop pin_TRIGGER = high delay_1ms(20) pin_TRIGGER = low delay_1ms(20) end loop -- Rob Hamerling, Vianen, NL -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/24f3dc21-9e72-2932-ea0b-ed3a6a0d64e2%40gmail.com<https://groups.google.com/d/msgid/jallib/24f3dc21-9e72-2932-ea0b-ed3a6a0d64e2%40gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsi2442Wx2mjk%3DcoUuf2jaa1wrLA4s9qT52APe4sfdHiA%40mail.gmail.com<https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsi2442Wx2mjk%3DcoUuf2jaa1wrLA4s9qT52APe4sfdHiA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/VI1PR07MB6256420C79A6C1BD1F58D696E6AD9%40VI1PR07MB6256.eurprd07.prod.outlook.com.
