interrupt assistant

[jpc]

as such the interrupt assistant seems a nice tool to create a ISR that at least is correctly setup but after struggling for several hours with a simple Uart-ISR that refused to trigger i have some questions here.
What is exactly are the ilevel and ics settings doing? I thought that giving the ilevel would set the priority of this ISR but that seems to be wrong. Only after configuring expolicitly in my code the IPC the interrupt started triggering

[mileta.miletic]

as such the interrupt assistant seems a nice tool to create a ISR that at least is correctly setup but after struggling for several hours with a simple Uart-ISR that refused to trigger i have some questions here.
What is exactly are the ilevel and ics settings doing? I thought that giving the ilevel would set the priority of this ISR but that seems to be wrong. Only after configuring expolicitly in my code the IPC the interrupt started triggering

Hi,

Ilevel sets the priority of ISR, but also you need to set up manually the correct priority for the used module. The priority of the module should be the same as the ISR priority.
ics is interrupt context saving, which determines the way of how the context is saved.

[jpc]

with all respect,maybe i miss something essential but i still do not understand how this ilevel works, if i put it to zero my ISR seems to work equally well, i have the impression the priority-level is only set by the IP-bits. Maybe the interrupt-assistant could do this in the future ( not highest priority right now)

[mileta.miletic]

with all respect,maybe i miss something essential but i still do not understand how this ilevel works, if i put it to zero my ISR seems to work equally well, i have the impression the priority-level is only set by the IP-bits. Maybe the interrupt-assistant could do this in the future ( not highest priority right now)

Compiler uses ilevel value for context saving. It tells compiler priority levels of interrupt routines defined in the program, in order to do adequate context saving. Hardware priority levels are set by IP bits, like you said.

[jpc]

ok, i understand better now but in fact this is not a very safe situation, we might have differences between ilevel and IP-settings resulting in probably impossible to debug problems. What is the safest Ilevel ? I suppose the lower the priority-level of any ISR, the more the context is at risk. In my current test ( only 3 ISR's of which 2 at the same IP-level i see no difference in the generated code if i change the ilevels. Maybe a solution is to make the ilevel available as buildin function to allow verification. Alternatively the interrupt assistant would set the IP-level based upon the ilevel parameter as passed to the assistant.

[rajkovic]

ok, i understand better now but in fact this is not a very safe situation, we might have differences between ilevel and IP-settings resulting in probably impossible to debug problems. What is the safest Ilevel ? I suppose the lower the priority-level of any ISR, the more the context is at risk. In my current test ( only 3 ISR's of which 2 at the same IP-level i see no difference in the generated code if i change the ilevels. Maybe a solution is to make the ilevel available as buildin function to allow verification. Alternatively the interrupt assistant would set the IP-level based upon the ilevel parameter as passed to the assistant.

If IP-level and ilevel are not the same context saving may not work,
I agree that best situation would be that ilevel is assigned by compiler to IP-bits
we will probably implement this. But until this time comes user as is stated in help
must be carfull and ensure that ilevel and IP-bits are the same.
I will remind you that there is some vectors that has multiple sources so one ilevel determinate multiple
IP-levels. Interrupts in PIC32 are quite complex and we are working as much as we can to make them usable
by simplifying and reducing number of steps that user should be aware of.

[jpc]

yes i am very aware this interrupt controller is complex, introducing the interrupt assistant tool on this family is the most difficult, on P16,P18 it is very simple, the 16 bit family's already have more complex interrupt controllers, the tool mostly makes sense if it protects us from making mistakes.
I have developped library's containing ISR's for several peripherals and i have init-functions like Init_Irq_Uart1(baudrate,Interrupt-priority), it is obvious that the Ilevel should be adapted at compile-time. Currently i cannot make this happen automatically, probably the safest is to set the Ilevel in that library to zero which i presume will do most complete context saving, however it is possibly wasting precious cpu-cycles.

[jpc]

talking about the complexity of this interrupt-controller, in how far is this Ilevel-context saving issue related to the interrupt subpriority levels ? I realize now that probably that should be taken i account by the tool as well and here the same situation pop's up, how to know the Iplevel and sublevel at compile-time?

[rajkovic]

talking about the complexity of this interrupt-controller, in how far is this Ilevel-context saving issue related to the interrupt subpriority levels ? I realize now that probably that should be taken i account by the tool as well and here the same situation pop's up, how to know the Iplevel and sublevel at compile-time?

subpriority is of no meaning for context saving, just priority is important. subpriority is used only in case when there are more than one interrupt pending with same priority to resolve which will
be executed first.