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

Meaning of #device HIGH_INTS=TRUE

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



Joined: 23 Jan 2018
Posts: 44

View user's profile Send private message

Meaning of #device HIGH_INTS=TRUE
PostPosted: Mon Feb 05, 2018 2:06 am     Reply with quote

I am using PIC18F452 in CCS C compiler.
In the system configuration the line have to compile, #device HIGH_INTS=TRUE.
I want to know the meaning of this and why this line is being used?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Feb 05, 2018 2:55 am     Reply with quote

On the PIC18 chips, there are two hardware interrupt priorities.

HIGH_INTS=TRUE adds the code to allow these to be used.

It is in the manual, but is under the #INT_XXXX entry, for how to organise an interrupt handler:
Quote:

The keywords HIGH and FAST may be used with the PCH compiler to mark an interrupt as high priority. A high-priority interrupt can interrupt another interrupt handler. An interrupt marked FAST is performed without saving or restoring any registers. You should do as little as possible and save any registers that need to be saved on your own. Interrupts marked HIGH can be used normally. See #DEVICE for information on building with high-priority interrupts.



A summary of the different kinds of PIC18 interrupts:

#INT_xxxx

Normal (low priority) interrupt. Compiler saves/restores key registers.

This interrupt will not interrupt any interrupt in progress.

#INT_xxxx FAST

High priority interrupt. Compiler DOES NOT save/restore key registers.

This interrupt will interrupt any normal interrupt in progress.

Only one is allowed in a program.

#INT_xxxx HIGH

High priority interrupt. Compiler saves/restores key registers.

This interrupt will interrupt any normal interrupt in progress.



You need to read the two manual sections, the chip data sheet, and the example, to get the whole picture. (ex_hpint.c). The example here shows a deliberately badly written interrupt handler 'blocking' another, and then using the hardware priority to avoid this.

There are some significant 'hardware caveats'. So (for instance) on most (all?) chips if high priority interrupts are enabled, INT_EXT is always high priority. Then having these will slightly slow the interrupt response time on the other interrupts (the hardware register save/restore is used for the high priority interrupts), and (of course) extra RAM used to save a second set of registers.

You can't use the HIGH or FAST settings, unless you have specified HIGH_INTS=TRUE.
Torello



Joined: 29 Sep 2006
Posts: 111

View user's profile Send private message

PostPosted: Wed Jul 11, 2018 1:31 am     Reply with quote

Hi Ttelmah,
Creating one fast interrupt routine (just incrmenting int8) the CCS way will generate ~500 bytes of extra code on a 18LFxxx pic.
Wow, 500 bytes..??! It is pretty fast however. Running @4Mhz going in/out the running code takes ~12us for just incrementing an int8 in the handler.
But I want to create more of those fast handlers. Adding one extra can't be fast anymore according to CCS, and, indeed, then in/out jumps to 105us. For the same action. Ouch!

I'm looking for a DIY way to CCS code more fast i'rupt routines with no priority and also no interrupting any on-going interrupt. Fast and more then one. Did you go into that corner by any chance?

Best regards,
Edwin
_________________
Regards, Edwin. PCWHD v5.097
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jul 11, 2018 2:31 am     Reply with quote

You are misunderstanding slightly.

There are high priority interrupts, 'HIGH' and 'FAST'. Two separate but interconnected things.

HIGH_INTS=TRUE, allows both to be enabled.

FAST, is the high priority equivalent of the #INT_GLOBAL for the low priority interrupts. With this, _your code_ must save any registers that need to be saved. Very fast response, but if you don't save a register, disaster. Also the handler does no testing for which interrupt has triggered. Hence only one such interrupt. However if you have enabled one 'FAST' handler, there is nothing to stop you enabling the high priority bit for another interrupt, and having this too arrive at the same handler. Then you have to check what interrupt has actually triggered. Just like the #INT_GLOBAL handler. There is only one physical vector for the high priority interrupts and one for the low.

HIGH gives you high priority interrupts. Remember 'high priority' does not make the interrupt any faster. It still has to save the registers, and test what interrupt has happened. Exactly the same time as for the low priority interrupts (actually the low priority interrupts will then become very slightly slower since these will now use RETFIE, and the high interrupt will now use RETFIE 1 which saves a couple of instructions). The point about high priority interrupts is they can interrupt the low priority interrupt handlers.

FAST or #INT_GLOBAL are much faster (just direct calls to the routines), but require your code to then handle everything (just like assembler interrupt handlers). If you are using 'FAST' and not saving registers in your code, then you have a 'disaster waiting to happen'....

FAST will only add a handful of bytes to code size.
HIGH will add many dozens of bytes as a complete second set of code to save the registers and test the interrupt source has to be added.
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