[Patch,avr] Implement PR56254
Fri Feb 8 17:25:00 GMT 2013
> -----Original Message-----
> From: Georg-Johann Lay
> Sent: Friday, February 08, 2013 9:00 AM
> To: Weddington, Eric
> Cc: email@example.com; Denis Chertykov; Joerg Wunsch
> Subject: Re: [Patch,avr] Implement PR56254
> Weddington, Eric wrote:
> > What does this do? How does it work?
> > Could you explain the statement in the documentation "if ticks is not
> > compile-time constant, the delay might be overestimated by up to 15
> > Why would we want to do that? I thought the whole point of a builtin
> > cycles function was to have an accurate delay.
> It's not uncommon that users complain that non-constant delays are not
> It works that same way like const delays except that no constant has to
> 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
> 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
> for very short delays to wait for slow I/O), but the users want it, as
> you know
> very well.
It is not necessarily a design flaw. We cannot judge someone else's application in that way.
And this is what I have a problem with: As you said, most of the time users will implement a very short delay waiting for I/O. It is exactly these short delays where being 15 cycles too slow will have the biggest impact, as it is a bigger percentage of the overall time being delayed.
We already have variable delays in avr-libc. How does this patch solve an existing problem? Does this patch make it more accurate than avr-libc?
> 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
More information about the Gcc-patches