Interrupt status?

[Darrel Taylor]

I've usually had very little reason to ever disable them once enabled.
Are you doing something really complex?

The Flags, enable and priority bits can be made available if needed, using the INT_INT constants.

[Charles Linquis]

In some cases, it is useful to save INTCON0 into a variable, and then clear INTCON0.

When you want to turn on the interrupts again, restore INTCON0. That way, you don't turn on interrupts that weren't on in the first place.

[circuitpro]

Oh, thanks very much for that Charles and Darrel. The board is part of a security system board, and didn't start out complex, but seems to be getting that way. I have two uart interrupts and hardware interrupts, and am having some conflicts in the sense that at the moment they are interfering with each other. I'm doing some serious debugging next week when I get back in front of the hardware, and hope to sort some of it out then.

Have I overlooked something about the INT_INT constants? Where to find out more on this?

Thanks again!

[Darrel Taylor]

Have I overlooked something about the INT_INT constants? Where to find out more on this?

No, you haven't missed anything.
I was just thinking about how I could make the interrupt bits available using the INT_INT constants. They've never been needed so far since the person writing the program is turning them on and off to begin with.

What I came up with is pretty ugly and confusing, so probably won't help.

But if you only have 4 interrupt sources, and they are interferring with each other ...
You are probably trying to do too much in the handler.

Interrupt rule number one.
Get into the handler, do only what is necessary to service the interrupt and get out as fast as possible. No pauses, no serial input or output, no waiting for something else to happen.
Anything that takes time should be done in the main loop.

[ScaleRobotics]

Interrupt rule number one.
Get into the handler, do only what is necessary to service the interrupt and get out as fast as possible. No pauses, no serial input or output, no waiting for something else to happen.
Anything that takes time should be done in the main loop.

Hey Darrel, I have a question about the rules. Would it break the rules if inside the interrupt handler you sent one or two bytes out at a time using the uart, as it would fit in the buffer?

[Darrel Taylor]

Hey Darrel, I have a question about the rules. Would it break the rules if inside the interrupt handler you sent one or two bytes out at a time using the uart, as it would fit in the buffer?

Sure, interfacing with the hardware is fine, then the hardware goes off and does the time consumming tasks.

USART, MSSP, Timers, CCP modules, A/D converter etc. ... YES.

SERIN/OUT(2), DEBUGIN/OUT, PULSIN/OUT, RCTIME, PAUSE, FREQOUT etc ... NO

[circuitpro]

Very good reminder in #7.

I think I'll just need to go through the (INT0) handler and just pare the heck out of it.