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
