INT_GLOBAL vs INT_FAST vs INT_HIGH on 18F parts

[5440]

I did some reading but have a couple of Q's regarding priority ints on 18F devices.

I am playing with a 18F2585 on CCS 4.106

I think I understand the following:

1) Using INT FAST will allow a high priority int to interrupt a low priority in progress. No context saving is performed as I seen from the listing

2)Using INT HIGH will allow a high priority int to interrupt a low priority in progress, but will generate context saving code is performed as I seen from the listing, 50 cycles or so extra over the FAST option.The compiler needs the statement #device HIGH_INTS=TRUE for priority Ints.

3) Using an interrupt that has no assigned priority (Microchip design) such an INT0 pin, will basically generate code that is the same as if HIGH was used.ex One INT_EXT and one fast int, INT_TIMER1 FAST would generate code that adds the saving overhead.

4) INT_GLOBAL, generates nothing, but the complier expects a user ISR at 0x08 which is the high vector when used (low priority vector is 0x18), else 0x08 is used for all non high priority ints

Q's:

Q1) If one wants the tightest high priority int code, is it best to use INT_Global or use FAST INTs? The user would have to add context saving and check the flags for Global Ints to determine what ints occurred? If so a low int is in progress, what happens when a high priority occurs? Would it just vector back to 0x08? How does it back to the low priority int? Any good example code for something like this?

Q2) If one needed a INT such as EXT (INT0 pin) that is no a priority int, are you stuck using a Global Int as all FAST Int would be handled as HIGH and have the overhead automatically added?

Q3) Is it a good idea to have more than one high priority (HIGH or FAST) enabled at one time? What happens if two high priority ints are pending at the same time?

Q4) If one were to use GLOBAL INTS, what registers really need to be saved if one is doing basic code in the ISR such as saving a CCP ot TMR reg, or inc a counter variable? What is the point of all the saving I seen in the listing file for HIGH INT?

Q5) If one wanted tight code for non priority Ints (compatibility mode), is it GLOBAL INT to only option?

Q6) Is it common practice to mix asm (for save/restore) and C code in the ISR?

[Ttelmah]

If you have _any_ interrupt set as high priority, and also have the standard 'INT' in use, this _always_ becomes a high priority INT. Hence an interrupt source test becomes 'forced'. This is a hardware limitation of the chips, with this interrupt having no 'priority' bit. This is why in your notes, when you used INT_TIMER1 FAST, the saving overhead was generated, since the compiler did this automatically. This is also your Q2 answer. If you want a single high priority interrupt with the minimum overhead, then it is vital to not have INT0 in use as well...
You can only ever have one interrupt flagged as 'FAST', since otherwise the code must test for the source, and the code to do this together with saving the registers, is automatically added.

The amount of saving needed, depends totally on the code _you_ use in the interrupt handler. If you perform array operations, the table pointers have to be saved. Most things will affect the W register, but the RETFIE1 instruction, restores this for you (and the BSR etc..). The only way to really optimise the interrupt handler, is to write the handler code, then go through the assembler listing generated, and note down every register that is used. Then add code to save these.
The compiler defaults to saving everything that it uses, even if the routines using the registers don't exist in the interrupt handler. I have often 'wished' for a compiler option, that checked for what registers were actually used in the interrupt routines, and only saved these. Lacking this, you have to do it yourself.

There is no inherent speed difference between using INT_GLOBAL, or fast INTs. In fact the 'FAST' directive, can be used to generate the exact equivalent to INT_GLOBAL for the high priority interrupts. If you generate a _single_ interrupt handler and flag it as 'FAST', this becomes the 'global' handler for high priority interrupts. You can add code to this to test for what interrupt occurred, and then manually set the priority flag for another interrupt source.

You need to slightly change your thinking about the interrupt vectors. 0008, is the 'high priority' vector address _when interrupt priorities are enabled_, and the 'global' vector address when priorities are disabled. Hence if you define INT_GLOBAL with no high priority vector enabled, the handler goes at address 8. If you wanted to handle both high and low priority interrupts, you would need to write the INT_GLOBAL routine to immediately vector to the high priority handler, and then have a second entry point for the low priority interrupts.
You can still use high priority interrupts with an INT_GLOBAL, but you have to set the priority bits yourself.

Have a look at ex_glint.c, which gives a basic example of handling an interrupt 'fast' using the global declaration.
The below is a small 'snippet' from a handler designed to give minimum latency for a quadrature change, with this needing less registers saved than the other routines:

[dmitrboristuk]

Hello. Is it possible to access addresses 0x08 and 0x18 to write your own interrupt handler with different priority levels for pic18 devices.
The standard handler uses a lot of things that I don't need, slowing down the work. This can be seen from the assembler listing.

[Ttelmah]

Yes, just use #INT_GLOBAL.

You just do exactly what I show, except you justify the code between
arriving at the fast handler, and it's exit, to fill 16 bytes. Then have
the low priority handler arrive at what is labelled NXT in my code.
Then don't have the low priority code use the fast return stack.

You do realise that if you use 'FAST', the register saving is removed. So
you can just do your own.

So for INT_GLOBAL:

[dmitrboristuk]

Ttelmah,
Thank you, I'll give it a try soon.

I also take this opportunity to ask you why the compiler for PIC18 does not use fast commands such as ADDWFC, COMF, DECFSZ, BC, BNC, RETURN, RCALL and others, instead they use constructions from several instructions inherent in PIC16

[temtronic]

My 'gut' feeling is that CCS programmers used what worked in the past, to get the product 'up and running', reliably. Considering the HUGE numbers of PICs today, trying to 'optimize' code for a handful of PICs would be very time consuming.

As Mr T says ,YOU can modify the code to suit EXACTLY what you want the PIC to do, you don't need to use what CCS supplies.

[Ttelmah]

Several of the instructions mentioned, they do use. Just perhaps not where
you expect. ADDWFC, DECFSZ BNC, and RETURN I have just found in the
listings from some of my code here. They avoid RCALL, because I think
it makes the calculations very difficult with the optimiser. RETURN they use
regularly. How else do you think they get back from routines?. Remember
though that they will always tend to 'inline' code if they can, and the stack
size on most PIC's is so limited that they need to avoid using it if they can,
so they will substitute a GOTO if they possibly can.
DIY'ing things has become less and less needed. Historically it was essential
for much fast code, but now the optimiser tends to get very close to as
good as you can get. Generally unless interrupt handlers are very limited in
what they do, the number of extra registers saved is very small, and
remember that the saving used is normally shared by all routines, If you
have one that needs to be really fast, then just use the FAST option.

[temtronic]

also... today's PICs have more memory and run a LOT faster than the original 4MHz ones where we had to cut in assembler and play 'tricks' to get use of every bit of memory and every microsecond of time.

[dmitrboristuk]

Ttelmah,
Your code is much faster than the standard one! I want to ask, is it necessary to set the RBIP and IPEN bits to high priority with this approach?

[Ttelmah]

Return in C, if it is in a function that has been called, is exactly the same
instruction as RETURN in the assembler. The highlighter knows it as a
C keyword, so makes it blue.
Remember though you cannot use a RETURN inside anything that is
in the global interrupt handler (or called from it). The compiler will
substitute a RETFIE if you do.
Yes, you manually have to set the priority. The enable the standard
enable_interrupts instruction will set.

Remember though to look at the assembler listing for all functions you
use inside the interrupt handlers, and you then need to add saving any
registers these use. Even quite basic things will change other registers,
and if the code is going to work correctly you have to be handling these.

[dmitrboristuk]

Ttelmah, Thank you, so far no questions