 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| disable interrupt during table look-up in program memory |
 Posted: Wed Mar 07, 2007 1:04 am |
 |
|
defined a table into flash program memory;
byte const = table[20] = {'A','B'....};
later my program will call up, the table from program memory and assign to a variable
xbyte = table [0];
i find that this code will disable GIEH & GIEL before look-up the table.
the problem is that my TIMER1 is running, and if that timer times up during table look-up, it would not be able to service TIMER1 immediately.
It will only service tmr1 interrupt routine after table look-up is complete, thus this effects the accuracy of tmr1.
Please help me to understand this and a solution to solve it |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Mar 07, 2007 4:06 am |
|
|
Your problem is not only the table lookup as there are more potential sources of delays, for example an other interrupt being served, etc.
Change your timer1 interrupt so it is not affected by these relative small time delays. What does your timer1 interrupt routine look like? Most likely it contains some code like:
To accommodate for the variable delays you can improve this to | Code: | | set_timer1( get_timer(1) + 123); |
|
|
|
Guest
|
|
| Posted: Wed Mar 07, 2007 4:57 am |
|
|
| Code: |
#INT_TIMER1 FAST
void ISR_TMR1 (void)
{
bit_timeout_1ms = 1; //Execute process list
reg_cnt_1ms++;
if (reg_cnt_1ms == 10)
{
reg_cnt_1ms = 0;
bit_timeout_10ms = 1; //set 10ms task
}
TMR1 = 0xFC27;
}
|
My timer routine, it should time out every 1ms and set a flag.
I'm using PIC18F452. What boggles me is why did the compiler add GIEH & GIEL = 0 instructions when look-up table on flash program memory routine executes. |
|
|
Guest
|
|
| Posted: Wed Mar 07, 2007 5:20 am |
|
|
a simple c instruction like:
| Code: | | xbyte = ROM_const[counter]; |
generates a assembly listing of
| Code: |
CLRF 0x3, ACCESS
MOVF counter, W, ACCESS
MOVFF 0xff2, 0x37
BCF INTCON, 0x6, ACCESS ; clears interrupt
BCF INTCON, 0x7, ACCESS ;
RCALL 0xa2 ; jumps to address 0xa2
BTFSC 0x37, 0x6, ACCESS
BSF INTCON, 0x6, ACCESS
BTFSC 0x37, 0x7, ACCESS
BSF INTCON, 0x7, ACCESS
MOVWF xbyte, ACCESS
0xa2:
MOVFF INTCON, 0xe
BCF INTCON, 0x6, ACCESS ;clears interrupt again
BCF INTCON, 0x7, ACCESS
CLRF TBLPTRH, ACCESS
ADDLW 0xc2
MOVWF TBLPTR, ACCESS
MOVLW 0
ADDWFC TBLPTRH, F, ACCESS
TBLRD*+
MOVF TABLAT, W, ACCESS
BTFSC 0xe, 0x6, ACCESS
BSF INTCON, GIEL, ACCESS
BTFSC 0xe, 0x7, ACCESS
BSF INTCON, GIEH, ACCESS
RETURN 0
|
|
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Mar 07, 2007 6:12 am |
|
|
For higher accuracy and to cancel the effects from unexpected delays changeto
| Quote: | | What boggles me is why did the compiler add GIEH & GIEL = 0 instructions when look-up table on flash program memory routine executes |
Some annoying default compiler behavior as quick and dirty fix for another problem.
http://www.ccsinfo.com/forum/viewtopic.php?t=25535 |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Mar 07, 2007 8:57 am |
|
|
An ROM array access, in terms of the processor work involved, is not 'simple'. There is a problem with the self incrementing/decrementing fetches on the PIC, where if an interrupt occurs during the fetch, even if the registers a then saved/restored in the interrupt, one increment/decrement, can be skipped. Hence the interrupt disable.
Seriously, you should radically re-think your actual way of operation in the interrupt handler. Incrementing the timer register itself, will never be safe. Handled properly, there will be no problems from the interrupts being disabled in the code at places (there will be others).
If you need a 1mSec interrupt, look at using timer2, and having it automatically reset for you. jitter in terms of interrupt timing, will still be present, but the total times will then be reliable.
Best Wishes |
|
|
Guest
|
|
| Posted: Wed Mar 07, 2007 10:18 pm |
|
|
| Ttelmah wrote: | | There is a problem with the self incrementing/decrementing fetches on the PIC, where if an interrupt occurs during the fetch, even if the registers a then saved/restored in the interrupt, one increment/decrement, can be skipped. Hence the interrupt disable. |
What do you mean by the above statement?
How do disabling interrupt helps when accessing ROM data using TBLRD* instruction? As i see it, there shouldn't be a problem without disabling interrupt, right?
| Ttelmah wrote: | | Incrementing the timer register itself, will never be safe. Handled properly, thre will be no problems from the interrupts being disabled in the code at places (there will be others). |
Ttelmah, please show how. I'm relatively new to all this.
Thank you
P.S. i posted all of the above posts under the moniker guest |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Mar 08, 2007 4:13 am |
|
|
Question. What is your clock speed? This is needed to work out the 'best' interrupt combination to use.
The problem with TBLRD, is discussed in a Microchip application note. They propose a number of solutions, disabling the interrupt, is the simplest.
Best Wishes |
|
|
Guest
|
|
| Posted: Thu Mar 08, 2007 7:16 pm |
|
|
| i using a 4MHz crystal |
|
|
Guest
|
|
| Posted: Thu Mar 08, 2007 8:10 pm |
|
|
Ttelmah, can you name the app. note mentioned earlier?
I've done a thorough search on Microchip website but couldn't find the the app. note you were talking about.
Thank you. |
|
|
|
|
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
