Mike Warren wrote:
> I need to blank out a VGA monitor during startup but want to show the
> user that something is happening.

I don't remember what the ATmega8's capabilities are (yes, I'm lazy) -
but the "best" way to solve this sort of problem is to use a
programmable capture/compare output that toggles the I/O line at the
exact clock edge you selected, _then_ calls the interrupt, wherein you
reprogram the CCR for the next desired edge. It's basically a
(complicated) PWM application, after all.

Fred Bartoli wrote:

> Why?
> Since the main loop is there to just loose time simply make the uC sleep
> at the end of the IT routine.
> No instruction executed = no jitter.

Exactly. If you want to solve this in a general case where you can't
control what you're doing in the main  loop, you could define an
additional compare match interrupt. For instance, if you're using match
A to update the VGA output at a certain time, you can define a match B
timer interrupt that goes off a few cycles before A. In the match B
ISR, you reenable the interrupts, and do a sleep instruction (you'll
have to save state to allow reentrant interrupts).

This can even be modified to allow for other interrupts, as long as
they are short, and can be stalled for a while. To do this, make the
gap between match A and match B bigger than the worst case timing for
other interrupts. In match B, disable all interrupts except match A,
and sleep. After handling the match A interrupt, reenable the other(s).

"Ian Bell" <ruffrecords@yahoo.co.uk> wrote in message 
news:453b1611.0@entanet...
> Mike Warren wrote:
>> My problem is that there is more jitter (about 2 to 3 cycles) than I
>> would like. My timer interrupt is this:
>>
> When an interrupt occurs, the current instruction is completed. Depending
> on the instruction this will cause a couple of cycles or so of jitter.
> Unavoidable I am afraid.
>
> Ian


Hmmm, I've never used the ATmega8, but the PIC MCUs don't suffer from this. 
They have zero jitter (for internally-generated interrupts). It doesn't 
mater what instruction is being executed at the time of the interrupt 
(either 1-cycle or 2-cycle instructions will generate the same latency as 
the PIC automatically compensates for the difference). For external 
(unsynchronized) interrupts the jitter is exactly 1 cycle (the minimum 
possible - can't be avoided).

-- 
Regards,
Costas
_________________________________________________
Costas Vlachos  Email: c-X-vlachos@hot-X-mail.com
SPAM-TRAPPED: Please remove "-X-" before replying

On Sun, 22 Oct 2006 07:37:47 +0100, Ian Bell <ruffrecords@yahoo.co.uk>
wrote:

>When an interrupt occurs, the current instruction is completed. Depending on
>the instruction this will cause a couple of cycles or so of jitter.
>Unavoidable I am afraid.

It might be possible to set the output compare register, and let the
timer hardware set a pin by itself at the right time. This will be
jitter free.

Mikael
-- 
Mikael Ejberg Pedersen
http://www.ejberg.dk

Ian Bell a �crit :
> Mike Warren wrote:
>> My problem is that there is more jitter (about 2 to 3 cycles) than I
>> would like. My timer interrupt is this:
>>
> 
> When an interrupt occurs, the current instruction is completed. Depending on
> the instruction this will cause a couple of cycles or so of jitter.
> Unavoidable I am afraid.
> 

Why?
Since the main loop is there to just loose time simply make the uC sleep 
at the end of the IT routine.
No instruction executed = no jitter.


-- 
Thanks,
Fred.

Ian Bell wrote:

> When an interrupt occurs, the current instruction is completed.
> Depending on the instruction this will cause a couple of cycles or so
> of jitter.  Unavoidable I am afraid.

Yes, I have it working acceptably now by not making any rcalls in my
main loop when the timer is running.

-- 
Mike

Mike Warren wrote:
> My problem is that there is more jitter (about 2 to 3 cycles) than I
> would like. My timer interrupt is this:
> 

When an interrupt occurs, the current instruction is completed. Depending on
the instruction this will cause a couple of cycles or so of jitter.
Unavoidable I am afraid.

Ian

Rich Webb wrote:
> AFAIK, the irreducible minimum jitter is the 2-3 clock cycles that
> you're seeing, based on the need to complete the current instruction
> before the interrupt is recognized.

Ahhh. For some reason I thought rcall and ret used 2 cycles each. I
looked them up and discovered that rcall uses 3 and ret used 4 cycles.

That plus the fact that the correction I'm doing will not help for the
current interrupt will cause what I'm seeing.

I'll have to rewrite so there are no rcalls in the main loop while the
timer is running.

Thanks Rich.

-- 
Mike

Mike Warren wrote:

> That's why I read the timer again and do the add.
> 
> 	in	A,TCNT1L
> 	ldi	B,2	; Timer1(L)
> 	add	A,B	; Allow for any delay getting here
> 	ldi	B,254	; Timer1(H)
> 	out	TCNT1H,B
> 	out	TCNT1L,A
> 
> I see no visible difference between the above code and this:
> 
> 	ldi	B,2	; Timer1(L)
> 	ldi	B,254	; Timer1(H)
> 	out	TCNT1H,B
> 	out	TCNT1L,A

Oops. The second one should be:

 	ldi	A,2	; Timer1(L)
 	ldi	B,254	; Timer1(H)
 	out	TCNT1H,B
 	out	TCNT1L,A

-- 
Mike

Rich Webb wrote:

> AFAIK, the irreducible minimum jitter is the 2-3 clock cycles that
> you're seeing, based on the need to complete the current instruction
> before the interrupt is recognized.


That's why I read the timer again and do the add.

	in	A,TCNT1L
	ldi	B,2	; Timer1(L)
	add	A,B	; Allow for any delay getting here
	ldi	B,254	; Timer1(H)
	out	TCNT1H,B
	out	TCNT1L,A

I see no visible difference between the above code and this:

	ldi	B,2	; Timer1(L)
	ldi	B,254	; Timer1(H)
	out	TCNT1H,B
	out	TCNT1L,A

-- 
Mike