Re: [avr-gcc-list] Fine Tuning code timings

[Mark Litwack]

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 autonomously land
the Tx bit in exactly the right position.

The code is a little tricky, but the basic strategy is to
repeatedly set up the OCR and COM registers so that the
output pin gets set to 0 or 1 at the *next* bit time.

In addition to setting the Tx pin, at each next bit time a
Tx ISR is called to set up the OCR and COM registers again
for the next bit.  The OCR is loaded with OCR + BIT_TIME,
and the COM is set up to clear or set the output bit (Tx)
depending on the next Tx bit value.  This is done 10 times
until all bits (8+start/stop) have been sent.  The only
timing constraint is that the Tx ISR needs to be called and
complete its pre-loading work before the the next bit time
passes.

The timer in this case is free running at a rate that is
unrelated to the baud rate (within some contraints) which
allows the timer to be used for other functions as well.  By
using the other output compare unit an Rx input pin can also
be implemented.

I have written double-buffered Tx and Rx routines (in C) for
an ATmega168 because I needed a second full-duplex UART.  I
won't clog the group by posting the code, but if you want it
drop me a note.

Hope this helps,

-mark


On Sun, 23 Dec 2007 20:16:45 +1300
"Alex Shepherd" <address@hidden> wrote:
> Hi Guys,
> 
> I'm trying to fine tune some C code timing issues for a
> software UART written in AVRGCC.
> 
> Essentially when I go to transmit a byte, I capture the
> value of Timer1, set the output compare value to the
> current timer value + the bit period, activate the Tx pin
> and then wait for the interrupt handler to output the
> rest of the bits in the byte.
> 
> The problem I'm having is that the latency between the
> timer interrupt firing and the code in the interrupt
> handler that drives the pin state is causing some error.
> I need some way to calculate the amount of time to reduce
> the initial timer period by so that the pin state driving
> logic in the interrupt handler executes at the right
> time. 
> 
> What I would like to try and find out (and why I'm asking
> on this list):
> 
> Is there any way to figure out using compiler
> tricks/magic how far into a function or interrupt handler
> a line of code is so that I can use this offset value to
> tune the initial start-bit timer value. The subsequent
> bit timings are ok as they are generated using the same
> code path?
> 
> I have experimented using LABELS in the code and trying
> to do pointer arithmetic but they don't seem to be
> accessible outside the function or I was just doing it
> wrong. 
> 
> Merry Christmas
> 
> Alex Shepherd
> 
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list