| View previous topic :: View next topic |
| Author |
Message |
Andrew83
Joined: 16 Sep 2008
Posts: 51
|
| Timing discrepancy problem |
 Posted: Mon Oct 20, 2008 10:02 am |
 |
|
Hello 2 all !
I'm trying to flash a LED to test timing issues.
First of all, my setup is this :
- compiler version CCS C ver. 4.057
- microcontroller: PIC18F452
- clock frequency : 4.4 MHZ
-example code : http://www.ccsinfo.com/forum/viewtopic.php?p=58272
- my test code for timer0:
| Code: |
#include <18F452.H>
#fuses HS,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay (clock=4.4 MHZ)
//#byte TMR0L = 0xfd6
//#INT_TIMER1
//void timer1_isr( )
#INT_TIMER0
void timer0_isr( )
{
// TMR0L = TMR0L + 6;
output_toggle(PIN_B1);
}
//==================================
void main()
{
setup_timer_0(RTCC_INTERNAL |RTCC_8_BIT|RTCC_DIV_4);
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);
for(;;);
{
output_low(PIN_B1);
}
}
|
I've been playing a little bit with timer0, trying to achieve a 1mS delay, and come across the following discrepancy:
- from my calculation :
Overflow value = 0,9(uS) * 256(timer overflow value) * 4(prescale value) ~~ 930(uS)
-from mplab stopwatch and another pic18 simulator : ~~970(uS)
So the obvious question would be: why the calculated value differs from the simulated result?
How can i achieve the much desired 1ms delay ?
THANK YOU VERY MUCH !  |
|
 |
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: Timing discrepancy problem |
| Posted: Mon Oct 20, 2008 10:52 am |
|
|
For clock frequency = 4.4 MHz, the internal clock rate would be 1.1 MHz. Using the /4 prescaler puts it at 275 kHz. And since it takes 256 Timer 0 clocks to overflow, the overflow rate would be 1074.21875 Hz, giving a period of 930.909 uSec. So I agree with your calculation. Could you describe how you used the MPLAB stopwatch to get 970 uSec? Try simulating a series of NOPs just to see if the 4.4 MHz clock rate is properly being taken into account. Then describe which instruction you used to start the stopwatch and which instruction you used to stop it.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Andrew83
Joined: 16 Sep 2008
Posts: 51
|
|
| Posted: Mon Oct 20, 2008 11:16 am |
|
|
Thank you for the quick response !
In MpLAb i've set a break point on the output_toggle(PIN_B1) and i've used the stopwatch to time the program execution till the breakpoint.
I''ve used the same procedure on the oshon pic18 simulator. |
|
|
Andrew83
Joined: 16 Sep 2008
Posts: 51
|
|
| Posted: Mon Oct 20, 2008 11:17 am |
|
|
| ok ! I will try the NOP aproach and see vhat results i get. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Oct 20, 2008 11:20 am |
|
|
| Andrew83 wrote: | Thank you for the quick response !
In MpLAb i've set a break point on the output_toggle(PIN_B1) and i've used the stopwatch to time the program execution till the breakpoint.
I''ve used the same procedure on the oshon pic18 simulator. |
Does that mean you zeroed the stopwatch on one breakpoint and then ran until that breakpoint was reached a second time?
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Andrew83
Joined: 16 Sep 2008
Posts: 51
|
|
| Posted: Mon Oct 20, 2008 11:27 am |
|
|
| No. I've run the program only once to the breakpoint. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Oct 20, 2008 11:32 am |
|
|
| Andrew83 wrote: | | No. I've run the program only once to the breakpoint. |
Well, that accounts for the extra time. You are including the setup time before Timer 0 even starts timing. Your calculation of 930 uSec. only applies to the time from one overflow to the next- not to the time for the first overflow starting from when the program executed its first instruction.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Guest
|
|
| Posted: Mon Oct 20, 2008 11:41 pm |
|
|
Hmmm ...yes...you are right ... it was obvious ... thank you !  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
