Re: [Patch,avr] Implement PR56254

[Georg-Johann Lay <avr at gjlay dot de>]

Weddington, Eric wrote:

> From: Georg-Johann Lay
>> This adds variable delays to __builtin_avr_delay_cycles.
>> 
>> Is this okay?
> 
> What does this do? How does it work?
> 
> Could you explain the statement in the documentation "if ticks is not a
> compile-time constant, the delay might be overestimated by up to 15 cycles".
> Why would we want to do that? I thought the whole point of a builtin delay
> cycles function was to have an accurate delay.

It's not uncommon that users complain that non-constant delays are not supported.

It works that same way like const delays except that no constant has to be
loaded and the delay is not 100% exact, i.e. might be up to 15 ticks too slow.

For delays like 100000 it does not matter whether or not it is 15 ticks longer,
most crystals are not exact enough you'll ever notice the difference.

IMHO, using delays in a application is a design flaw in the first place (except
for very short delays to wait for slow I/O), but the users want it, as you know
very well.


In cases of variable delays the inexactness comes from computing the amount of
ticks at run time, not __builtin_avr_delay_cycles itself.  But that's up the
user that calls __builtin_avr_delay_cycles, it's not a problem of
__builtin_avr_delay_cycles.


Johann