Interrupt handling?

[Guest]

Hi

In my code I disabled ext_x interrupt but poll for it.

My Q is what way does the pic / ccs handle this ?

The pic will goto addr: 0008 and execute the ccs dispatcher code but the ccs code is real long.

[Ttelmah]

Nothing to do with the compiler...
This is down to how the _chip_ handles interrupts.
The code really doesn't 'come into it'.

There are three flag bits associated with each interrupt:

First, the 'flag'. This is set by the hardware event. The event on some interrupts may be changed (so on the level interrupts for example, you may change whether this is set by a rising or falling edge).

Then the individual 'enable'. This is controlled by the enable/disable interrupt call.

Then the 'global' enable (set by the same calls, but using #INT_GLOBAL).

The interrupt handler (at address 8), is _only_ called, when all three bits are set.

You have turned off the 'enable', so the handler will not be called.

Clearing the interrupt will become your responsibility (the compiler will automatically clear interrupts when the 'handler' routine is called).
Also remember that for some interrupts (serial data received, RB change etc.), the event causing the interrupt itself, _must_ be cleared before the interrupt can be cleared.

For the '18' chips, there is also another bit involved, the hardware 'priority' flag. This has it's own caveats.

Remember, that though testing the flag bit is a great idea to remove the latency implicit in calling the handler, if you have other interrupt sources enabled, and a chage occurs while the code is in the handler for these, you will not return to the 'main' routine, till this handler has completed, potentially 're-introducing' latency problems.

Best Wishes

[Guest]

Hi

Sorry for the late response.

In this ex will addr 0008 NOT be entered because the INT0IE=0. ?