View previous topic :: View next topic |
Author |
Message |
Ramey
Joined: 11 Sep 2007 Posts: 18
|
interrupt priority changed by compiler? |
Posted: Tue Apr 01, 2008 3:39 pm |
|
|
In my program I have used
#int_timer0 high
When I do this - I get another warning. This suggests that now I have 2 high priority interrupts - timer0 + USB which I don't want as it is critical to me that the timer0 be invoked "on time".
What can/should I do to fix this.
Robert Ramey
Code: |
>>> Warning 225 "C:\PROGRA~1\PICC18\drivers\pic18_usb.h" Line 994(1,1): Interrupt level changed USB: NORMAL=>HIGH
>>> Warning 216 "LEM.c" Line 186(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_token_reset)
>>> Warning 216 "LEM.c" Line 186(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_flush_out)
>>> Warning 216 "LEM.c" Line 186(0,1): Interrupts disabled during call to prevent re-entrancy: (@MUL3232)
>>> Warning 216 "LEM.c" Line 186(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_cdc_flush_out_buffer)
|
|
|
|
Guest_7068 Guest
|
|
Posted: Tue Apr 01, 2008 9:35 pm |
|
|
There is a compiler directive which you can use to set the priority in which the compiler checks the interrupt flags:
Code: |
#priority Timer0, USB
|
|
|
|
Ttelmah Guest
|
|
Posted: Wed Apr 02, 2008 2:37 am |
|
|
No.
#priority, only changes the order the flags are scanned in the individual global handler (a sort of psuedo priority, that 'pre-dates' the hardware priority on latter chips). What is happening, is that the compiler insists on the USB interrupts, being raised to the 'high' hardware priority, if the hardware priority ability is used. It is really a fault, and should be reported to CCS. Ideally, while this is probably a 'safer' default behaviour, if people write slow 'high priority' handlers, there should be an option to disable this.
There are some behaviours of this sort, that are in the hardware (for instance, on most chips, if the hardware high priority interrupts are enabled, INT_RTCC, will automatically be promoted to become a high priority interrupt, but there is no such hardware limitation on the USB interrupt.
It appears that CCS are just being a little 'too smart' here...
Best Wishes |
|
|
OzanGazi
Joined: 03 Mar 2008 Posts: 6
|
|
Posted: Tue Mar 23, 2010 3:57 am |
|
|
Yes I have the same problem..
device 18f8722.in my program i am using
#int_timer1
#int_timer3
#int_rda high
#int_rda2 high
#int_adc
#int_ext
There is no problem except #int_ext
Warning 225 : Interrupt level changed EXT : NORMAL => HIGH |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Tue Mar 23, 2010 4:40 am |
|
|
It is not the compiler doing the change.
It is just warning you that this is happening.
Read the data sheet.
Study the interrupt tree.
Look at the INT0 interrupt. Do you see a INT0IP bit?.
This is common for all the PC18 chips. INT_EXT, has no priority flag in the hardware, and is _always_ a high priority interrupt, if hardware priority is enabled.
Paragraph 10.6 in the data sheet. Last line:
"There is no priority bit associated with INT0.
It is always a high priority interrupt source."
If you want a low priority external interrupt, you have to use INT1,2 or 3.
Best Wishes |
|
|
OzanGazi
Joined: 03 Mar 2008 Posts: 6
|
|
Posted: Tue Mar 23, 2010 8:52 am |
|
|
Thank you Ttelmah everything is clear...Now i am using INT1 and no problem.. |
|
|
|