Page 1 of 1

Interrupt priorities on an ECIO40

Posted: Fri Jun 24, 2011 2:12 pm
by Electron
What are the default interrupt priorities on an ECIO40? Can I change their priorities? I'm using Flowcode 4.

TMR0
RB0/INT0
PORT
TMR1
RB1/INT1
RB2/INT2
USBINT
RXINT
TMR2

When I select the PORT interrupt, it indicates that this is PORT B. What are the conditions on PORT B that will cause an interrupt? Any bit? Low to high? High to low?

Re: Interrupt priorities on an ECIO40

Posted: Fri Jun 24, 2011 2:26 pm
by Benj
Hello,

The default priorities are that the interrupts are all the same priority so incoming interrupts will override existing interrupts.

The PORT interrupt will fire when any of the portb pins change state. i.e. going high and going low.

If you do not want all of the portb pins to trigger the interrupt then you can check at the start of the interrupt which pins have changed and therefore see if you are interested in processing the rest of the interrupt code or not.

Re: Interrupt priorities on an ECIO40

Posted: Fri Jun 24, 2011 2:46 pm
by Electron
Thanks Benj,

How do I change the priorities of the interrupts? Do I need to use a C routine? (I'm not familiar with C).

Re: Interrupt priorities on an ECIO40

Posted: Fri Jun 24, 2011 3:27 pm
by Benj
Hello,

With PIC18 devices you have two priorities,

1) Normal priority
2) Low priority

All Flowcode interrupts are normal priority.

At the moment I can't really think of a way of managing the low priority interrupts via Flowcode even using custom C code.

Can I ask if you actually need interrupt priority in your application as I have been able to do large programs with complex interrupt structures without any issues. The best way is to keep the interrupt macro itself as simple as possible and then do the complex tasks in your main program by setting flags. This way you can prioritize the interrupt processes any way you like.

Further to this I will see if I can find a way of getting a priority interrupt structure into v5 of Flowcode.

Re: Interrupt priorities on an ECIO40

Posted: Mon Jun 27, 2011 9:17 am
by Electron
Hi,

The project is a pulse generator with the following layout:

TMR2 is configured to provide a regular timing interrupt, which sets a pulse flag when the next pulse should occur.

The main routine contains switch checking (to set the pulse rate and width) and writing to an LCD.

A pulse routine is actioned when the pulse flag is set in TMR2.

The problem is that the program might be half way through the switch/LCD routine when the pulse flag is set, but the pulse routine is not actioned until the flag is checked at the start of the switch/LCD routine loop (which can take ~5mSec for LCD writes).

What I would like is to action the pulse routine regardless of where the program is in the switch/LCD routine, and then to return back to where it left. And still maintain the TMR2 interrupts so the overall timing is accurate.

So I was thinking to make TMR2 a high priority interrupt, and instead of a pulse flag, generate a low priority interrupt which calls the pulse routine.

I would like the pulse train to occur continuously, that is not to stop/restart when an update to the rate/width is requested via the switches.

Any suggestions welcome.

Re: Interrupt priorities on an ECIO40

Posted: Wed Jun 29, 2011 10:22 am
by Electron
Is this not possible?

Re: Interrupt priorities on an ECIO40

Posted: Wed Jun 29, 2011 10:44 am
by Benj
Hello Electron,

Yes this should be possible. Have you had a go using hardware? Hopefully you can process the high importance bits in the interrupt routines and then leave any low priority code in the main and use flags to call it.

Another option is to have a second slave PIC and get that to generate the uninterruptable pulse chain and then send it commands from your main controller.

My suggestion would be to give option 1 a go and then post again with your program attached if you are having specific problems. We may then be able to find workarounds for you to get a better result.

Re: Interrupt priorities on an ECIO40

Posted: Wed Jun 29, 2011 1:00 pm
by Electron
What additional code do I need to make TMR2 a high priority interrupt and INT2 a low or lower priority. I assume this code would be put somewhere at the very beginning of the overall program - is that right?

Re: Interrupt priorities on an ECIO40

Posted: Thu Jun 30, 2011 4:32 pm
by Benj
Hello Electron,

Sorry I do not currently know how to achieve this using Flowcode at the moment as all of the interrupt handlers are automatically loaded into a standard priority function. You could maybe get away with it by using C code via the supplementary code window but it is not as simple as simply passing a value to a register and that's it. We have a bit of a plan in place for v5 but it is a low priority as we currently have lots of new features to cram in.

Re: Interrupt priorities on an ECIO40

Posted: Fri Jul 01, 2011 1:16 pm
by Electron
I see that JACQOUT had a similar interrupt priority question http://www.matrixmultimedia.com/mmforum ... ies#p25093 and there was talk of using intcon3 to control the priority of INT2. I don't know if JACQOUT resolved this, but would that technique be applicable to mine?

I need to know if this can be resolved or not, otherwise I will start looking at other methods, which I don't think will be very effective or efficient as prioritising the interrupts.

Thanks

Re: Interrupt priorities on an ECIO40

Posted: Fri Jul 01, 2011 2:54 pm
by Benj
Hello,

I can provide details but as I say I cannot think of a clean way to do this without doing it all using C code.

At the moment when interrupts are enabled they all jump to the default interrupt vector which is controlled by this function.

void interrupt ()
{
}

Interrupts can be made low priority on PIC18 devices using the control bits in the interrupt registers. eg intcon3.

These will then refer to this function.

void interrupt_low ()
{
}

Therefore you could add the code from the standard interrupt function into the interrupt_low function using the supplementary code window.

As I said before though I have written complex programs with multiple interrupt sources and have never needed to resort to using this technique.