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 CCS Technical Support
Edge of interruption IV (delay in ext2 & rda int)

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



Joined: 19 Nov 2003
Posts: 22

View user's profile Send private message

Edge of interruption IV (delay in ext2 & rda int)
PostPosted: Sun Apr 25, 2004 2:40 pm     Reply with quote
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
Ttelmah
Guest
Re: Edge of interruption IV (delay in ext2 & rda int)
PostPosted: Mon Apr 26, 2004 4:11 am     Reply with quote
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
ibg



Joined: 19 Nov 2003
Posts: 22

View user's profile Send private message

Delay removed
PostPosted: Mon Apr 26, 2004 3:25 pm     Reply with quote
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
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