Hi Alex,
One other way to approach this without having to deal with
the fixed latency of the Tx ISR and any other interfering
ISRs is to use the Compare Match Output bit on the timer as
the Tx bit. It's close to what you're doing, but using the
output bit allows the counter hardware to
On Wed, Jan 02, 2008 at 10:59:05AM -0500, Mark Litwack wrote:
One other way to approach this without having to deal with
the fixed latency of the Tx ISR and any other interfering
ISRs is to use the Compare Match Output bit on the timer as
the Tx bit. It's close to what you're doing, but
On Wed, 2 Jan 2008 10:10:28 -0600
David Kelly [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 10:59:05AM -0500, Mark Litwack
wrote:
One other way to approach this without having to deal
with the fixed latency of the Tx ISR and any other
interfering ISRs is to use the Compare Match
On Dec 28, 2007, at 11:00 AM, Jan Menzel wrote:
Hi Alex!
I'd suggest to take larrys approach and generate the start bit from
within the ISR. For precise timings you might add the bit time to
the current OCR value (insight the ISR). Using this schema you can
have an arbitrary (but
Hi Alex!
I'd suggest to take larrys approach and generate the start bit from
within the ISR. For precise timings you might add the bit time to the
current OCR value (insight the ISR). Using this schema you can have an
arbitrary (but constant) phase difference between the interrupt and the
Hi Alex,
I am not sure why you are capturing the timer1 value, unless you are using the
timer for other purposes as well. If not then the easiest method is to:
1. Enable time over flow interrupt.
2. Load the timer withe the required delay for the chosen baud rate. The port
pin can be made low
OC3X interrupt would sample at the right time.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alex
Shepherd
Sent: Saturday, December 22, 2007 11:17 PM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Fine Tuning code timings
Hi Guys,
I'm trying to fine
