|
|
View previous topic :: View next topic |
Author |
Message |
Mrinmoy Dey
Joined: 23 Jan 2018 Posts: 44
|
Meaning of #device HIGH_INTS=TRUE |
Posted: Mon Feb 05, 2018 2:06 am |
|
|
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: 19516
|
|
Posted: Mon Feb 05, 2018 2:55 am |
|
|
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: 120
|
|
Posted: Wed Jul 11, 2018 1:31 am |
|
|
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.114 |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19516
|
|
Posted: Wed Jul 11, 2018 2:31 am |
|
|
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. |
|
|
|
|
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
|