Interrupt On Change  - Page 1
Forum section: electronics / general

author: singlarrysong
author_rank: Contributor
timestamp: May 05, 2015, 06:47:03 pm
content: Anyone have IOC program sample for PIC16 that work perfectly well?I got some cool project for customizing home lightning on going.Because using I/O reading technique not as good as reading edge, so I wish to use it in my program.Its better have multiple IOC configured, I tried on config it for one I/O, it work, but unstable. When I increase the number of I/O that using IOC, it not working anymore.TQ very much!!!

author: SL4P
author_rank: Super Contributor
timestamp: May 05, 2015, 10:35:53 pm
content: It's not all that hard.Strip out all other code, and work on a basic test... (blinking LED!)Instability may be due to switch bounce or too much happening within the ISR.ISR code should be as short and sweet as possible.Test your state flags and do further (time consuming) work in your main()...(CPU cycles spent in main() are 'free' - you will just get interrupted again if something else changes )// ================================void main() {Make sure the idle state of your inputs are pulled as expectedSet up your IO pins.Clear any stray interrupt source flags (in case!)Enable interrupt modes-- things can start happening now...// ----------------while(1) {-- main stuff-- test your private flags and call your action functions-- reset your private flags or whatever is needed to maintain your operating state}// ----------------}// ================================void interrupt isr {Test which interrupt source fired the ISR...if (RBIF) {-- test those specific I/O bits that are your sensor-input pins(minimise the code executed within the ISR - e.g. only set some flags etc)}Clear the ISR source flag & return to caller.RBIF = 0;}

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2015, 10:40:37 pm
content: Rule number one: never use interrupts on GPIO pins for events which cannot be predicted. You won't be the first to find out the CPU gets stalled because it can't cope with the amount of interrupts. It is far better to poll the GPIO pins. That way you can also detect whether the condition stays valid for a certain time (and it wasn't a glitch due to static discharge).

author: SL4P
author_rank: Super Contributor
timestamp: May 05, 2015, 10:47:03 pm
content: Quote from: nctnico on May 05, 2015, 10:40:37 pmI won't say you're wrong, but where did you pick that up? I'd like to learn.How doyouread high-speed rotary encoders etc.....

author: mazurov
author_rank: Frequent Contributor
timestamp: May 05, 2015, 10:54:12 pm
content: This is the encoder code (and interrupt-on-change routine, for AVR) ->https://www.circuitsathome.com/mcu/rotary-encoder-interrupt-service-routine-for-avr-micros. Works very well for reading hand-operated encoders and slow motors.

author: mikerj
author_rank: Super Contributor
timestamp: May 06, 2015, 11:33:23 am
content: Quote from: SL4P on May 05, 2015, 10:35:53 pmNote that within the 'if (RBIF)' block the IOC port (PortB)mustbe either read or written to in order to remove the mismatch condition. If you don't do this, the PIC will jump straight back into the interrupt.Also, beware ofthis bugin the IOC.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2015, 07:09:15 pm
content: Quote from: SL4P on May 05, 2015, 10:47:03 pmFrom a high speed timer interrupt.I've seen it go wrong too many times combined with insufficient input debouncing/filtering. Using a GPIO interrupt for buttons, encoders, etc looks very nice but it is cumbersome to filter such inputs properly in hardware. And what when (not if) an input gets stuck between logic levels and starts to generate a continouos stream of interrupts? And then there is also the matter of signalling the interrupt to the user application (synchronisation between asynchronous threads). Polling allows to do simple filtering in software for low frequency events like buttons and other inputs.

author: Howardlong
author_rank: Super Contributor
timestamp: May 07, 2015, 07:20:59 am
content: You can use the IOC to do the initial wakeup, but in general I agree, using IOC for quadrature encoders isn't the way forward for the reasons mentioned. Regretfully the IOC pins on most, if not all PIC16 devices don't have Schmitt trigger inputs, so even an external cap in compination with the weak pull up won't work.In a power constrained system, you could do IOC in combination with a timer interrupt to resample regularly until a steady state is reached. IOC should be disabled immediately on wakeup, and the timer reset. The IOC can be re-enabled just before sleeping again, but the device needs to be awake during the de-glitching period however long that is.

author: singlarrysong
author_rank: Contributor
timestamp: May 09, 2015, 07:51:55 am
content: Hi everyone, sorry for the late reply.I rework my initial program that fail and now it success.I avoid setting GIE so no interrupt function require. I read the interrupt flag to identify the interrupt.On the circuit part, there is a pF cap across each switch button to filter out the noise and further more Schmitt trigger is configure for the triggering method.and yea it work. PIC16F1825 with Hi-Tech C at MPLAB v8.9

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2015, 11:19:43 am
content: Now count the number of interrupts versus the button pushes...