 |
 |
| View previous topic :: View next topic |
| Author |
Message |
FJMSoft
Joined: 20 Oct 2013
Posts: 36
|
| PIC12F675 INT_EXT latency. |
 Posted: Fri Nov 01, 2013 1:30 am |
 |
|
Hello.
I was doing some experiments with INT_EXT.
I was expecting 2us up to 10us but I'm measuring about 35us.
Is this normal?
uC is PIC12F675 (using internal clock)
Compiler is 5.008
Code is:
| Code: | #include <main.h>
#USE FAST_IO(A)
#INT_EXT
void EXT_isr(void)
{
output_low(pin_a5);
delay_us(100);
output_high(pin_a5);
}
void main()
{
ext_int_edge(H_to_L);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
set_tris_a(0b00000110);
while(TRUE)
{
//TODO: User Code
}
} |
| Code: |
#include <12F675.h>
#device ADC=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES PUT //Power Up Timer
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOBROWNOUT //No brownout reset
#use delay(internal=4000000)
|
Thank you. |
|
 |
alan
Joined: 12 Nov 2012
Posts: 357
Location: South Africa
|
|
| Posted: Fri Nov 01, 2013 2:17 am |
|
|
Yes that's normal. Getting to the interrupt takes about 30 instructions. On 4MHz that's 30us.
Regards |
|
|
FJMSoft
Joined: 20 Oct 2013
Posts: 36
|
|
| Posted: Fri Nov 01, 2013 2:33 am |
|
|
I'm disappointed :/
This is uC fault or CCS fault?
Thanks for the answer. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri Nov 01, 2013 2:47 am |
|
|
| FJMSoft wrote: | I'm disappointed :/
This is uC fault or CCS fault? |
Neither, its your "fault" for having an unrealistic expectation. All interrupts involve some processor latency. There is also generally some environment specific latency, i.e. the time taken for any compiler/operating system specific interrupt code, which in CCS's case is fairly long. It does this as an interrupt is a context switch, so the current processor context has to be saved, by code, before the ISR can be run. Also the PIC hardware has a very simple non-vectored interrupt mechanism, and the compiler generated code has to emulate a vectored system by checking, in turn, each of the possible interrupt sources. All this happens behind the scenes and most users are totally unaware of it.
Much of this latency can be eliminated at the expense of the user having to implement similar functionality using either #int xxxx FAST, where the FAST attribute tells the compiler not to do any context saving and restoring, but it will still do the vectoring. Or there's also the nuclear option, #int_global which overrides all the compilers interrupt handling code and means you have to implement all vectoring and context saving/restoring yourself. Both should be regarded as advanced, and are very rarely used, even by experienced and highly skilled programmers, mainly as they know not to design systems that expect and rely on very short, well defined interrupt latency. Such users also know that any delay of more than a few cycles in an ISR is bound to cause trouble, and adds unreliably to interrupt latency is systems with more than one interrupt source. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
| Posted: Fri Nov 01, 2013 4:52 am |
|
|
Let's step in and extend this a bit.
First key thing, is to understand that the PIC does not have a register stack. Hardware limitation. This is why code cannot be re-entrant. Everything has to be stored in RAM, and just the act of saving a single register takes a couple of instructions. Many other processors have the ability to save some or all registers in a single instruction. The PIC doesn't. The PIC18, can save the three most critical registers automatically, but the smaller PIC's lack even this.
Now when an interrupt occurs, the reaction, is not till the next instruction. Then the processor executes a call to the core 'handler'. Already three instruction times have passed. Now we arrive at this handler, and everything that may be changed in the handler, has to be saved. Absolute minimum about another four instructions. Then everything else that may be changed needs to be saved, and then we have to test what interrupt has actually occurred. Total about 30+ instructions.
Now RF_Developer, has gone off on a slight tangent here. 'FAST' _only_ applies to PCH. With your chip, you have just two choices:
1) The standard handler. This saves all registers used by compiler maths etc.., then tests the interrupt flags and enables, to find 'which' interrupt has occurred, then jumps to the handler routine.
2) 'INT_GLOBAL'. This does nothing. It allows you to write your own replacement for the handler. Look at ex_glint.c.
However key point straight away, is that you must save everything that is changed in the handler. You are using a delay (hopefully just as a demo - search here for why you don't want to do this normally....). This immediately uses extra registers....
It is possible, using your own INT_GLOBAL handler, with a routine that is very careful about what registers it uses, to get the response down to under perhaps 10uSec. Not 3.5uSec though even at best. However every extra thing you do in the handler, will involve saving yet more....
It has always been a slight 'weakness', that the optimiser doesn't work out exactly what registers _are_ accessed in each interrupt routine, and save just these. However (obviously) significant work, so the compiler leaves it up to you to do this if you want the ultimate speed.
Best Wishes |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Fri Nov 01, 2013 9:34 am |
|
|
| Code: |
void EXT_isr(void)
{
output_low(pin_a5);
delay_us(100);
output_high(pin_a5);
} |
if you need really low latency toggling of a pin
you could use some 74HC123 and an HC08/HC32(for pic access to "a5"
during other than the INT condition) as glue logic and respond with external hardware- then use the #int in the pic to merely record the fact
that the specified action was taken. and trigger the HC123 with the same pin as the ISR trigger.
then you have reaction time in the sub usec range with ease
and the pic stays"informed" of what was done, could still control the "virtual pin_a5" using and AND or OR gate on the HC123 output..
the only issue is if the trigger condition happens more frequently than 100 usecs or so
etc ..... |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
