[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Newbie question

From: Vincent Trouilliez
Subject: Re: [avr-gcc-list] Newbie question
Date: Wed, 25 Feb 2009 17:36:08 +0100

On Wed, 25 Feb 2009 11:05:02 -0500
David VanHorn <address@hidden> wrote:

I am kinda a newbee too, but I will throw my comments. The experts will
come to the rescue soon I am sure ;-)

> I have an app on a Mega32L, running at 4 MHz.
> in ITEMP,TCNT1H   ;Once I've captured the timer value,
> in ITEMP2,TCNT1L  ; I don't care how long the ISR takes to run.

I am using a mega32 and last weeks I used Timer1 for the first time.
I learned the hard way that one should BELIEVE what the datasheet says.
In this case it says that 16bit timers, like timer one, when you READ
them, you must read the LOW byte first. Here you do the opposite.
Read the datasheet closely for details.

> I'm trying to measure the widths of pulses that could be as short as 5uS.
> The theory was to detect the first rising edge, and zero T1.
> Then on the second rising edge, grab the count from T1, which is running at
> CK/1

If you measure the time between two riseing edges, this will give you
the period of the signal, not the width of the pulse ! the period may
be fixed, so you will always obtain the same value, will never
change ! ;-)
What you could do is trigger the timer on the rising edge, then modify
the configuration of the interrupt, to generate an interrupt on the
FALLING edge. Then you clear the timer and re-configure the interrupt
to trigger on the rising edge again, etc, etc..

> I understand what the compiler is doing, but the ISR it generates is way too
> slow. > (see below)

See the avr-libc manual. I have never the opportunity to use that, but
I am sure there is a "naked" attribute you can use, to keep the
compiler from generating any prologue/epilogue whatsover, leaving you in
full control (for the best and the worst ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]