Interrupt-on-change handling by CCS

[RLScott]

For interrupt-on-change (IOC), the PIC datasheet for the 16F870 shows that the state of the pin for purposes of reading the port is latched during every processor state Q1. But the state of the pin for purposes of comparison to generate an IOC is latched during processor state Q3 when the port is read. If the state of the pin changes between Q1 and Q3 on the very instruction cycle when you are reading the port, then the value you read will be stale, having been latched during Q1. Yet, the new pin value will be latched into the IOC comparison latch during that port read. Then, on the very next instruction cycle, the pin value latch that gets latched on every Q1 will "catch up" to the IOC comparison latch. This allows you to clear the IOC interrupt, never having read the current port value. What is more, the IOC interrupt will stay cleared because the IOC comparison latch and the pin value latch are now in agreement. Thus if you only read the port once in your ISR, you could miss a port change indefinitely.

To avoid this problem, the programmer who writes all his own handlers (using INT_GLOBAL) will do this:

1. Read the port and discard the value read
2. Clear the IOC interrupt
3. Read the port again and use this value

This ensures that no change will ever go unhandled indefinitely.

My question is, how much of this can we expect from the CCS IOC interrupt wrapper? Does the CCS wrapper for IOC read the port and clear the IOC interrupt in its preamble? That would work (assuming the user then read the port again). Or does the CCS handler clear the IOC in its postamble, which would leave us open to the problem described above? Anyone know for sure?

Robert Scott
Real-Time Specialties

[PCM programmer]

Compile a test program and look at the .LST file.

[RLScott]

Ah, yes. I see. It does none of it. The preamble just saves a bunch of compiler temporaries, checks which interrupt flags are set, and then jumps to our ISR. I have always used INT_GLOBAL, so I didn't know what to expect. Thanks for the point in the right direction.

Robert Scott
Real-Time Specialties

[Ttelmah]

CCS, clears the interrupt flag _after_ the handler.

Normally what you describe, should not happen for a lot of chips. In general, the read latch, is not driven directly from the pin, but from the output of the Q1 latch. Hence the data itself, is latched just _once_ in the Q1 cycle, but is copied to the comparison latch, in the following Q3. If the pin has changed after Q1, the latched value, is the 'old' value, and the interrupt will retrigger.

I have seen what you describe happen on two of the very old 16chips, and it is listed as an errata for these. If you think that the 16F870, has this problem, check with MicroChip directly. In the past on two other chips, they have confirmed for me, that the error is in the diagram on the data sheet, and not present in the actual chips.

If they confirm the 870 has this fault, then declare the interrupt handler using 'noclear', and handle the clearing yourself.

Best Wishes

[RLScott]