I've got a new project on a PIC16F877 which uses several PORTB pins. 2 of these are "interrupt-on-change", one is the normal INT pin, one is a plain polled input pin, and some are output. (Basically, we want 4 interrupt-on-change pins, but RB6:7 have to be used for in-circuit programming)
Is there a safe way to read the normal input pin without messing up the interrupt-on-change pins? The code outside of the ISR already wraps all of the reads/writes to PORTB bits in macros.
-- Darin Johnson
It's not very clear from your question what you are doing, maybe you could rewrite it. reading a pin doesn't cause an interrupt on change.
No, but I believe that is how you clear the interrupt.
To the OP, unless you are turning off the interrupt when you are reading the "normal" pins I don't see how it could be a problem. The reading of the port is atomic. Maybe I am missing something here, but I don't see a problem, are you having a problem?
Jim
reading a pin doesn't cause an interrupt on change.
Not really, you need to clear the flag in the intcon register as well.
reading a pin doesn't cause an interrupt on change.
Not really, you need to clear the flag in the intcon register as well.
Well, that is even better. No amount of fiddling in the main loop (short of clearing the intcon bit) should stop the int on changed pin from occurring.
Jim
From the datasheet:
"If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the RBIF interrupt flag may not get set. Furthermore, since a read or write on a port affects all bits of that port, care must be taken when using multiple pins in Interrupt-on-change mode. Changes on one pin may not be seen while servicing changes on another pin."
-- John W. Temples, III Remove -spam to reply.
This is the part I'm concerned about. Reading from PORTB will clear any pending "interrupt-on-change" bit. I don't know what cycles the PIC uses internally (though from the diagrams it seems that there is Q1 through Q4), but it seems conceivable that there could be a race condition.
The datasheet figure that shows the interrupt-on-change pin has the the "previous" latched value overwritten during during Q3 if reading the port. So if the bit changes value before Q3, the change would seem to be lost. I notice now that the datasheet also says that any write will clear the mismatch condition...
I think I can get rid of the problem in software though.
-- Darin Johnson
Only in the sense that there might be a change in the port bit that does not cause the RBIF flag to be set in INTCON. But that should not be a problem. The purpose of the interrupt-on-change function is to make sure that an interrupt is latched whenever the port bit changes without being read by software. Whenever you read the port, you are implicitly taking responsibility for handling any changes that you read. The only interrupts you can depend on are for changes that you never read. So if the port changes during Q2 and you read it in that instruction cycle, then there may not be an RBIF, but you do have a copy of the changed port. Just don't ignore what you read and you will be OK.
Robert Scott Ypsilanti, Michigan
Technically this can be done, but the code is split into multiple tasks, with their own spheres of control. The function that is reading bit #1 may not know what to do with bit #2, etc.
I'm just going to have the tasks monitor their own bits with polling (only 2 bits are interrupt-on-change). In the normal case the interrupt wakes up the tasks right away, but in the rare case that an interrupt is missed there may be a 50ms delay in responding (which is ok for these).
-- Darin Johnson
This must be a new paragraph as it doesn't seem to be in any of my old datasheets. I've only used the portb interrupt with low frequancy signals that are related to each other so not more than 1 can change at any time. The pic interrupt structure is a pretty poor setup, the more you use the worse it gets. I would recommend a processor with a traditional prioritised vectored setup if you need to use multiple interrupt sources. I notice the OP now says 50mS latency is acceptable so polling would be a much better option anyway.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.