Instant Interrupts - Revisited

[circuitpro]

DT,

I have only used interrupts once, (using Instant Interrupts) based on your clock routine. I am starting a design in which I want to again use your interrupt routines, (and I admit I haven't read all your examples and documentation yet). I'm at the point where I'm making a first guess at pin assignments on a PIC18F67J60. I know I'm going to have to use the clock output of a rotary encoder as one interrupt source, and a generic 'some button has been pushed' kind of interrupt from a bunch of PCF8574's as another. Being really new at interrupts, which would more straightforward to implement... the PortB 'onchange interrupts', or individual B0 (Int0), and B1 (Int1) dedicated interrupts?

Thanks much,
Len G.

[Darrel Taylor]

It really depends on what you need to catch.

If you only need to catch either the Rising or Falling edge of a signal, then it's much easier to use INT1, INT2 and INT3.

But it you need to catch both edges, then the best route is RBC_INT (PORTB Change) on PORTB.4-7.

So I'd guess buttons on INT?, and encoders on RBC.
<br>

[circuitpro]

Thank you.

[ralfmayr]

Hi Darrel,
i use your instant interrupts on a 18F6722.
A question to the interrupts:
I want to use a timer which shall make 1sec ticks and i have both uarts receving commands from other devices. I also have two subs writing and reading via I2C-Bus to some internal devices. Problem: If having more and more activity on the i2c bus and also interrups are coming via the uarts, the timer is getting slower (2 - 3 sec) depending on the activity.
All interrups are defined as high priority interrups.
Any idea?

Regards,
Ralf

[Darrel Taylor]

I want to use a timer which shall make 1sec ticks and i have both uarts receving commands from other devices. I also have two subs writing and reading via I2C-Bus to some internal devices. Problem: If having more and more activity on the i2c bus and also interrups are coming via the uarts, the timer is getting slower (2 - 3 sec) depending on the activity.
All interrups are defined as high priority interrupts.
Any idea?

Hi Ralf,

Do you have PAUSEs in your handlers?
Interrupt handlers should be as fast as possible, get in - do only what needs to be done - and get out.

If for instance it were writing to I2C EEPROM then sitting around waiting 10mS for each write to complete, then no other interrupts can occur during that time that it's doing nothing.

If you have pauses, or long strings of data being sent or received, then those handlers should be LOW PRIORITY. Then with the Timer still in High Priority, it won't miss a beat.

hth,

[ralfmayr]

Hi Darrel,
thanks for the answer.
I don't have any pauses, the i2c bus writes and reads ad-converters and io-expanders, no eeproms.

I think the main problem is the handler for the uarts. The interrups for the uarts are handled as fast as possible, i read back the RCSTA registers and then i put the data in an array, by triggering on "{" and "}" for start of text and end of text. When "}" was received the serial command is valid and then i parse the string.
After that i handle my i2c bus and so on....
Maybe it is more effective to make a ring buffer, and when ever there is time then i check this buffer and parse the data in it. But i never made such a ring buffer.....

Regards,
Ralf

[Darrel Taylor]

Receiving data 1-byte at a time is always the best way to do it with USARTs and interrupts.

No Timeouts, no WAIT(), and no long strings.

For a simple Ring buffer, check out Joe S.'s Serial Backpack program, modified for DT_INTS.

http://www.picbasic.co.uk/forum/show...8336#post28336
<br>