CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
2 or more high priority interrupts on PIC18Fxxx

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
nik



Joined: 23 Jan 2004
Posts: 1

View user's profile Send private message

2 or more high priority interrupts on PIC18Fxxx
PostPosted: Fri Jan 23, 2004 3:50 am     Reply with quote
hello,
i've read about the 'fast' directive to set high priority to one interrupt handler and i confirm it's ok, but is it possible to set this directive to more interrupt handlers?

thanks in advance
Nik
Ttelmah
Guest
Re: 2 or more high priority interrupts on PIC18Fxxx
PostPosted: Fri Jan 23, 2004 8:08 am     Reply with quote
nik wrote:
hello,
i've read about the 'fast' directive to set high priority to one interrupt handler and i confirm it's ok, but is it possible to set this directive to more interrupt handlers?

thanks in advance
Nik

The problem is that doing this degrades the utility of the fast handler. It immediately implies that you now have to test a status to see which routine has interrupted. Depending in the chip, you also need to be aware of the 'caveats' about the use of fast (on a 18Fxx2, there is a problem if the fast device is asynchronous). Basically, you just go 'DIY'. There is no support in the compiler for a int 'despatcher' for the fast interrupt.

Best Wishes
RKnapp



Joined: 23 Feb 2004
Posts: 51

View user's profile Send private message

PostPosted: Tue Feb 24, 2004 12:51 pm     Reply with quote
OK -- no support for the "fast" interrupt.

But what's unclear to me from the datasheet -- and from the CCS documents for v3.185 -- is if there's queuing of normal-priority interrupts.

I'm using five 18F8720s in my design, and plan to communicate between them using the two native RS232 ports. Can I stack the RS-232 interrupts into separate ISRs and not lose chars? Or must I use a single ISR and poll whenever that interrupt fires?

Thanks,

Smile Robert
Ttelmah
Guest
PostPosted: Tue Feb 24, 2004 3:40 pm     Reply with quote
RKnapp wrote:
OK -- no support for the "fast" interrupt.

But what's unclear to me from the datasheet -- and from the CCS documents for v3.185 -- is if there's queuing of normal-priority interrupts.

I'm using five 18F8720s in my design, and plan to communicate between them using the two native RS232 ports. Can I stack the RS-232 interrupts into separate ISRs and not lose chars? Or must I use a single ISR and poll whenever that interrupt fires?

Thanks,

Smile Robert

The interrupt hardware, handles this.
Basically, when an 'event' occurs, the interrupt flag is set. This happens whether or not the processor is inside a handler, or in the main code. When the processor exits an interrupt handler, restores the register, and returns to the main code, interrupts are re-enabled, and if the interrupt flag is set, there will be an immediate interrupt again.
The key question is the total 'latency'. If there are two basically identical interrupts, one will have priority over the other, simply on the basis that it's flag is tested first in the global handler (you can set this order with the #priority directive). When an interrupt occurs, there is a significant delay while the global handler saves lots of registers, then the tests are made. There is then a further delay to handle the actual interrupt routine, and then more delay while the registers are restored. If (for instance), two serial interrupts occur at once, the second handler, will only be reached, after the entire time associated with handling the first interrupt has taken place, and then the register saving, and test process, has been repeated for a second time. Typically, even at 40MHz, assuming a reasonably 'compact' interrupt routine is used, the delay, can easily be in the order of 60uSec. Provided each serial can accept this much delay, there is no problem. If one interrupt corresponds to a faster data stream, then this should be given priority.
Care also needs to be applied (allways), to the time spent in all interrupt handlers.

Best Wishes
RKnapp



Joined: 23 Feb 2004
Posts: 51

View user's profile Send private message

PostPosted: Wed Feb 25, 2004 2:31 pm     Reply with quote
Ttelmah,

Thank you for your reply. What I think you're telling me is:

- Yes, an interrupt will stay active until serviced. (Good.)

- The #priority directive can be used to set the order of low-order interrupts. This is good, but it seems that on this platform interrupts are not interruptible (unlike x86) so priority inversion is possible. (Good to be aware of this.)

- Latency can be very high. My platform is the 8720, which can only run at 20MHz and (because it requires four clock cycles per instruction) only really runs at 5MIPS. But you were saying that a 40MHz device is still taking 60 usec to service an interrupt and return. (Annoyingly long.)

My plan is to merely unload bytes in the ISRoutines, since the native UARTs apparently only have a single latch and a shift register for receive -- only one byte is buffered by the 8720.

Again, thanks,

Smile Robert
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group