HELLO;
COULD YOU PLEASE SUGGEST ME A SOLUTION FOR A PROBLEM ON TIMER B, TIMER MODE INTRRUPT.
ACTUALLY I AM USING THIS IS FOR A SITUATION .ie WHERE SENSOR2 HAS TO BE SENSED SOON AFTER , SENSOR 1 GETS SENSED. SUPPOSE IF SENSOR2 HAS NOT SENSED , AFTER SENSOR1 GOT SENSED ,THE OPERATION HAS TO BE STOPPED.MEANWHILE CONTROLLER IS DOING SOME OTHER JOB
PARALLELLY.
TIMER B SET AT TIMER MODE , AND TRBIC IS SET TO 0X02 , (INTRRUPT CONTROL REGISTER)
THE TIMER INTRRUPT GETS RAISED FOR EVERY 25MSEC , AND INCREMENTS THE VARIABLE. THIS IS WORKING FINE.INTRUUPTS GETS RAISED FOR EVERY 25MSEC.
TIMERB_ISR( ) // INTRRUPT SERVICE ROUTINE
{
IR_TRBIC = 0;
VARIABLE ++;
IF (VARIABLE == 100)
{
FUNCTION1( );
}
}
MAIN( )
{
-----
----
----
FUNCTION( );
WHILE(1);
}
VOID FUNCTION(VOID)
{
TIMER START FLAG = 0;
WHIE( SENSOR1 == 0) ;
IR_TRBIC = 0; TRBPR = 200 ; // THE TIMER B IS STARTED TRBP = 200; TRBIC = 0X02; TIMER START FLAG = 1;
OTHER_OPERTION( );
}
ATER VARIABLE GETS EQUAL TO 100 , THE FUNCTION( ) IS CALLED AND AGAIN ITS CHECKS FOR SENSOR1, IF IT IS ONE , THEN AGAIN TIMER IS SWITCHED ON,
PROBLEM: AT THIS POINT THE INTRRUPT IS NOT RAISED FOR EVERY 25MSEC AND THE ,INTRRUPT SERVICE ROUTINE IS NOT SERVICED. THIS IS THE PROBLEM.
could you please help me out,
thanking you
naveen
First, you don't need to reset any interrupt request flag in the interrupt routine (IR_TRBIC=0). The interrupt request flag is reset automatically when an interrupt is accepted and the software jumps to the interrupt routine.
Is only the timer interrupt not executed any more, or does the software stop?
Are FUNCTION and FUNCTION1 the same?
If not, the function at the end should be FUNCTION1 I believe?
If so, you should try to reduce the code executed in the interrupt routine. I think best would be if you only increment VARIABLE in Timer RB interrupt, and do the test "if (VARIABLE==100)" in main(). Otherwise, you have to be careful which functions are called in the interrupt routine and make sure all of them are re-entrant.
What means "// calling ISR FROM HERE"? timer_rb IS the ISR, isn't it?
//TIMER B INTRRUPT IN INTRT.C
VOID TIMER_RB(VOID) //VECTOR = 24
{
TIMERB_ISR( )
}
VOID TIMERB_ISR(VOID) AT MAIN.C , WHICH CONTAINS INCREMENT OF "VARIABLE " ,
WHEN COUNT REACHES 100 IN VARIABLE, THE FUNCTION( ) IS CALLED . THIS WORKS FINE , FOR FIRST TIME AFTER RESET .
iF NOW THE SENSOR1 ==1 , TIMERB AGAIN STARTS COUNTING FOR 25MSEC , UNTILL VARIABLE = 100 ; THIS IS NOT HAPPENING FOR SECOND TIME .CONTROL IS NOT GOING TO VOID TIMER_RB(VOID). //VECTOR = 24 // WHICH IS AT INTRT.C .
Could it simply be that there is no
VARIABLE=0;
in FUNCTION? In this case you only have to wait a little longer until VARIABLE overflows and reaches again 100.
INTIALLY AFTER RESET THINGS ARE WORKING FINE,
AFTER 25MILLI SEC
THE SOFTWARE SWITCHES TO TIMER B ISR ,
INCREMENTS THE VARIABLE FROM ZERO TO 100,
AFTER COMPARING , SOFTWARE BRANCHES TO MAIN FUNCTION TO RESTART ALL OPERATION.
I CANT COMPARE VARIABLE = 100 AT MAIN FUNCTION ,BECAUSE CONTROLLER IS PARALLELY EXECUTING CODES FOR OTHER OPERATIONS.
NOW, IF AGAIN THE TIMER B IS STARTED , THE SOFTWARE WILL NOT BRANCHES TO ISR .,
WHY THIS IS HAPPENING. IS THERE ANY SETTINGS OR MEMORY OVERLAP OR SP ADDRESS IS INVALID.
the software is not going to intrrupt service routine for second time , after i compare the variable ==100 and get back to main function .
Don't branch to FUNCTION1 from inside the ISR. This means you never return from the ISR after you get to 100.
Set a flag in a global variable to signal the ISR has happened. Then branch to FUNCTION1 inside of the "interrupted program". This is the way a forwground/background application is written - ISRs mainly change variables or flags, and the main functions do all the work.
If you want to look a way to do this with "threads" or tasks, then an RTOS or simple threading might be in order.
http://en.wikipedia.org/wiki/Protothreads
There's an R8C example here:
©2003–2009 Renesas Technology Corp. All rights reserved. Using Our Website | Privacy
Contact us