Many of the newer AVRs, Tiny88 for example, let you dynamically change
the CPU clock
frequency. However the AVR-LibC based delays always assume
a fixed frequency based on F_CPU.
I'll always know what frequency I'm at when I call a delay() function.
Is there a way of doing:
_delay_us( double
I'll always know what frequency I'm at when I call a delay() function.
Is there a way of doing:
_delay_us( double __us, uint32_t f_cpu )
and still have the compiler generate code that does not
invoke floating point at run time?
I could make a delay function for each clock
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of Bob Paddock
Sent: Wednesday, March 04, 2009 9:00 AM
To: AVR-GCC
Subject: [avr-gcc-list] Using delay functions
The delay functions require a constant so the delay can be calculated at
compile time. I would think that part of the problem is that you have to
introduce more code to check the value of f_cpu and to calculate the delay.
This pushes the delay calculation into run-time, plus it adds more
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of David VanHorn
Sent: Wednesday, March 04, 2009 11:46 AM
To: AVR-GCC
Subject: Re: [avr-gcc-list] Using delay
Bob Paddock graceindustr...@gmail.com wrote:
Is there a way of doing:
_delay_us( double __us, uint32_t f_cpu )
and still have the compiler generate code that does not
invoke floating point at run time?
#undef F_CPU
#define F_CPU new_value
_delay_us(us);
F_CPU is always evaluated
F_CPU is always evaluated upon each invocation, so if you ever change
it within one compilation unit, the next invocation of one of these
macros will reflect this.
That's compile-time, he's looking for execution-time changes in processor
speed.
He didn't explicitly say so, but I think he's
David VanHorn wrote:
F_CPU is always evaluated upon each invocation, so if you ever change
it within one compilation unit, the next invocation of one of these
macros will reflect this.
That's compile-time, he's looking for execution-time changes in processor
speed.
He didn't explicitly say so,
On Wed, Mar 04, 2009 at 04:37:22PM -0500, David VanHorn wrote:
F_CPU is always evaluated upon each invocation, so if you ever
change it within one compilation unit, the next invocation of one of
these macros will reflect this.
That's compile-time, he's looking for execution-time changes
] Using delay functions with
variable F_CPU clock?
On Wed, Mar 04, 2009 at 04:37:22PM -0500, David VanHorn wrote:
F_CPU is always evaluated upon each invocation, so if you ever
change it within one compilation unit, the next
invocation of one of
these macros will reflect
10 matches
Mail list logo
