Interrupt status?

[circuitpro]

I have a program using 4 different DT_INTs, and to be honest, it's getting a little hairy.

I've sort of lost track if an interrupt is enabled or disabled. Is there a quick (lazy) way for me to tell if an interrupt is enabled or disabled?

[circuitpro]

Bulldoze the code, and rewrite it.

[Charles Linquis]

Read the INTCONx registers.

[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.

[circuitpro]

I know about not using serial port/s during an interrupt, but how time consuming is something like this?

ARRAYWRITE TEMP,[DEC2 HOST,".",DEC2 ADDRESS,".","125",".",DEC2 V,".","*",13,10]

(I guess this would be considered 'hardware' and therefore probably permissible, right?)

[mackrackit]

You might want to try this.
http://www.picbasic.co.uk/forum/showthread.php?t=9350