Electronic – Generating 1 second with avr and timer 0 for Atmega32A

avrtimer

dears:
we have to Generate 1 second with atmega32A and mikrobasic software.
so I have configured timer 0 and avr with this way:

const _THRESHOLD = 250 
TCCR0=0x04
TCNT0=0x06
OCR0=0x00
' // Timer(s)/Counter(s) Interrupt(s) initialization
TIMSK=0x01

and overflow function:

sub procedure Timer0Overflow_ISR iv IVT_ADDR_TIMER0_OVF
' // Reinitialize Timer 0 value
TCNT0=0x06
if (counter1 >= _THRESHOLD) then
counter1 = 0

so with TCCR0=0x04 WE USE 256 presqale with external clock 16MHz wich :

16MHz/256=62500

which means timer 0 clock is 1/62500=0.000016 Second
which TCNT0=0x06 timer 0 over flow clock is 256-6=250
which take 0.000016*250=0.004 Second for one overflow of timer 0 with TCNT0=0x06 .

so for creating 1 second, it needed to count timer0 overflow for 1/0.004=250 turn of timer0 overflow. the above codes are written based of this calcuation.
SO when we program this codes into atmega32A, for 5 minutes the clock is Lag for 5 seconds.

Changes based of new comment.

I have changed TCNT0=0x07 for 249 clock of timer0 and 1 clock for
overloading ti,er values. but still counter lag for 5 second at 5
minutes .

please help me to correct my codes.

Thanks a lot.

Best Answer

Is "mikrobasic" compiled or interpreted? The website calls it a "compiler", but I have found that vendors play fast-and-loose with the distinction these days. Sometimes source code is compiled to an intermediate "bytecode" representation, which is then interpreted.

You have timer0 counting every 16 µs, which means that the ISR must update the TCNT0 register within that amount of time in order for your calculations to be correct.

I find myself wondering whether the ISR actually does the write to TCNT0 before it has already incremented several times, which would explain the roughly 1-part-in-60 error that you're seeing.

One experiment would be to see whether you get the correct timing by increasing the TCNT0 value even more. Try setting TCNT0 = 0x0B in your ISR. If this gives you something closer to the correct timing, that means that there's a lag on the order of 64 µs between when the overflow interrupt occurs and when the write to TCNT0 occurs. This would not be unheard of in interpreted code.

Related Topic