PIC12F629 Timer issue

[Hans Wedemeyer]

Using 10MHz osc. I'm trying to run both timer0 and timer1 to generate
two frequencies 1100Hz and 1500Hz

To toggle the pin each half cycle in the ISR:
Timer0Value = 256 - (0.00033333/(8/(10000000/4)))
Timer1Value = 65536 - (0.000454545/(1/(10000000/4)))

The output is not what I expected, allowing for the timer resolution these values are too far off.
Measured output 1063Hz not 1100Hz
Measured output 1430Hz not 1500Hz

The resonator is running a little high, the measured frequency 10,050,250 Hz. Yet the outputs are far too low !

Did I do something wrong or is there something strange with the 12F629 ?

Thanks.
Hans W

#FUSES HS, NOMCLR, NOPROTECT, NOWDT, NOBROWNOUT, PUT
#use delay(clock=10000000)

#use fast_io(a)

int Timer0Value;
long Timer1Value;

#int_TIMER0
TIMER0_isr()
{
output_toggle(PIN_A1);
set_Timer0 ( Timer0Value );
}

#int_TIMER1
TIMER1_isr()
{
output_toggle(PIN_A2);
set_Timer1 ( Timer1Value );
}

void main()
{
Timer0Value = 152;
Timer1Value = 64400L;

set_tris_A(0b00101000);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_8);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);

enable_interrupts(INT_TIMER0);
enable_interrupts(INT_TIMER1);
enable_interrupts(GLOBAL);

set_Timer0 ( Timer0Value );
set_Timer1 ( Timer1Value );

while(1){;} // do nothing

}

[epideath]

Looks like you got some numbers crossed

Timer0Value = 256 - (0.00033333/(8/(10000000/4)))
Timer1Value = 65536 - (0.000454545/(1/(10000000/4)))

should be

Timer0Value = 256 - (0.000454545/(8/(10000000/4)))
Timer1Value = 65536 - (0.00033333/(1/(10000000/4)))

Note the .0004545454 and the .000333333333

If you take the half scycle speed for 1100 hz so 2200. 1/2200 = .000454545

If you take the half scycle speed for 1500 hz so 3000. 1/3000 = .0003333333


So the numbers should be
Timer0Value = 141
Timer1Value = 64703L

Hope this helps

[Hans Wedemeyer]

[Mark]

The problem is the interrupt latency. In your interrupt, you are setting timer1 to a value. When the interrupt occurs, timer1's value is 0. By the time the interrupt is processed, many instructions (and time) has gone by. By setting the timer with your "roll over value" you lose this time in your calculations and thus the difference in what you see. From the numbers, it appears to be off by about 35 instructions which is about how many instructions it takes to process the interrupts. A better approach would be to add the "roll over value" to the current timer1 value so that you don't lose its count.

[Hans Wedemeyer]

[Guest]

[quote="Hans Wedemeyer"]

[Mark]

By the time the interrupt is processed, timer1 already has a count. Run the code in the simulator and put a break point just before the set timer function. Take a look at the value of timer1. I think it will become clear then. It is not that the isr code is fat, it is the saving of all the registers that happens behind the scene. Since timer1 is not 0, when you set timer1 to a value, you lose the time hince the adjusted value. If you want to avoid this, you cannot lose this time so if you add the timer1 value to the computed value this will correct it. Actually, adding the value will produce a slightly larger isr routine but will keep in time better.

[Hans Wedemeyer]

[quote="Anonymous"]

[Hans Wedemeyer]

[Mark]

If you do it like

[Guest]

[Mark]

Use the #priority to have the Timer1 int go first. This will take care of some of the cases. There will be other cases where you will be in the timer0 interrupt when the timer1 int fires. This will cause a slight error in the signal. In the way I suggested, the frequency will remain the same but the duty cycle will change slightly when the timer0 int fires just before the timer1 int does. To improve upon this even further, you can embed a goto at the end of the timer0 routine to jump back to the beginning of the interrupt flag test in the CCS interrupt handler. If timer1 int has occurred, then it will get executed. Note that the registers have already been saved so you save this amount of time. You could also write your own int handler or use the global handler and do your own bit testing.

[Hans Wedemeyer]

[PCM programmer]

[Mark]