![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
ibg
Joined: 19 Nov 2003 Posts: 22
|
Edge of interruption IV (delay in ext2 & rda int) |
Posted: Sun Apr 25, 2004 2:40 pm |
|
|
Hi all,
Thanks for keeping helping me with this.
As I mentioned before, I NEED to add the delay(30) inside the ext2 handler to avoid the glitches from the signal coming from the telemetry system. The thing is, that I need to add this interruption handler (int_ext2) to a program where I'm getting GPS data coming through the serial cable. These data are read using the rda interruption handler. The GPS data are coming continously.
When I add the ext2 interruption handler to the GPS program, this program doesn't work. It gets stuck but if I delete such delay(30) from the ext handler, the GPS program works well again.
Ttelmath said: Quote: | The interrupt handler, as coded by CCS, allready clears the interrupt on exit, so if you delay in the handler, any interrupts that have occured before the routine exit, will be cleared. This behaviour can be disadvantageous if you want to handle high speed interrupts |
So, is that the reason why my program gets stuck? Any suggestions?
Thanks for all,
Imanol |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
Re: Edge of interruption IV (delay in ext2 & rda int) |
Posted: Mon Apr 26, 2004 4:11 am |
|
|
ibg wrote: | Hi all,
Thanks for keeping helping me with this.
As I mentioned before, I NEED to add the delay(30) inside the ext2 handler to avoid the glitches from the signal coming from the telemetry system. The thing is, that I need to add this interruption handler (int_ext2) to a program where I'm getting GPS data coming through the serial cable. These data are read using the rda interruption handler. The GPS data are coming continously.
When I add the ext2 interruption handler to the GPS program, this program doesn't work. It gets stuck but if I delete such delay(30) from the ext handler, the GPS program works well again.
Ttelmath said: Quote: | The interrupt handler, as coded by CCS, allready clears the interrupt on exit, so if you delay in the handler, any interrupts that have occured before the routine exit, will be cleared. This behaviour can be disadvantageous if you want to handle high speed interrupts |
So, is that the reason why my program gets stuck? Any suggestions?
Thanks for all,
Imanol |
Question.
Do you use 'delay_ms' anywhere in the external code?. If so, you are running into the 're-entrancy protection'. Basically, if a routine is used in both the internal, and the external code, interrupts will be disabled in this routine, in the external code.
You really _must_ re-think the need to use the delay inside the subroutine. Any serial data received in this time will also be lost (you can't interrupt from an interrupt handler - except on the PIC18 family, and even here the chips are faulty if the interrupt source is an 'asynchronous event'). At the normal GPS data rate, a delay of 30mSec, corresponds to 15 characters. I suspect you are triggering a comm overflow, and the UART is therefore hung.
Think instead of using the external interrupt, to trigger a timer. Program this to give a delay of 30mSec, and enable it's enterrupt, disable the exernal' interrupt at the same time. Then when the time times out, read the input, and if it is still in the active state, you have a 'legitimate' trigger. At this point re-enable the external interrupt, and disable the timer interrupt.
An alternative, if the 'input', is allways guaranteed to be active for 30mSec+, is to stop using the interrupt at all. Instead have a 'timer' interrupt at perhaps 10mSec intervals. Have this 'poll' the input. It the input is active, increment a counter. If it is inactive, clear the counter. If the counter reaches 3, then a 'good' input has been detected. Though it is possible to use delays in an interrupt handler, doing so, really removes the advantage of using interrupts in the first place (you are killing the ability of the processor to do other tasks while waiting for an event to occur).
You do _not_ 'NEED' the delay in the interrupt. You _need_ to rethink ghow your code works.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
ibg
Joined: 19 Nov 2003 Posts: 22
|
Delay removed |
Posted: Mon Apr 26, 2004 3:25 pm |
|
|
Well, I have removed the delay from the ext2 handler (using a timer instead) and it seems everything works well. I avoid the glitches coming from the signal that generates the interruption and the GPS data coming through the serial cable are read too :-)
I attach the code I've used for it:
Code: |
// PIC18F452
// Interruption Control Register
#byte INTCON3 = 0xFF0
// Peripheral Interrupt Request (for TIMER1)
#byte PIR1 = 0xF9E
.
.
.
//----------------------------------------------------------------------------------
// This interruption service routine is executed when TD edge goes from H to L
#int_ext2
void ext_isr(void)
{
set_timer1(timer1_offset);
bit_clear(PIR1, 0);
enable_interrupts(int_timer1);
disable_interrupts(int_ext2);
int_flag= 1;
signal_strength= read_adc();
pulses++;
}
//----------------------------------------------------------------------------------
#int_timer1 //We will have this interruption 30 miliseconds (aprox) after an external interruption occurs
time_out_routine()
{
bit_clear(INTCON3, 1);
enable_interrupts(int_ext2);
disable_interrupts(int_timer1);
}
.
.
.
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8);
// Computation -> 65536 - (0.03 / (32/19660800))= 47105;
timer1_offset= 47105;
// Activate interruptions
ext_int_edge(2, H_TO_L);
input_b(); // read portB -> the latch is reset
bit_clear(INTCON3, 1); // ext2 interruption flag is cleared
enable_interrupts(GLOBAL); // It allows interruptions to become active
enable_interrupts(int_ext2); // Enable ext2 interruption
|
Thanks a million to the power of a million for all your help ;-)
Cheers,
ibg |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|