Follow-up Comment #13, bug #30363 (project avr-libc):
My guess is that many people either don't use these
routines or use the delay routines
for fairly long >1ms gross/rough delays as
many of the responses to my comments in the AVR freaks forum
threads when I brought up issues about cycle accuracy particularly
at the low end suggested just using "a few NOPs" for short hardware setup
time delays rather than use these routines.
For long delays, I'm assuming that usually the rounding style really doesn't
matter because at several milliseconds or more,
being off by a clock cycle (too long or too short) may not matter.
And given the granularity of the current delay routines
that used the basic loops, the majority of people could
not have been caring too much about the delay accuracy -
especially down to the individual cycle.
My focus has always been to make the functions work more predictably and for
hardware setup times, where there is no alternative to CPU busy-wait delays,
such as NOPs, loops or etc because things like a timer are way too long.
Hardware setup times need a delay "at least as long as"
a certain period of time. The delay can be longer but never
shorter.
With "round up" a delay may be longer than requested, but for hardware setup
timing that is desirable over getting a delay that is too short that can cause
the code to violate the hardware timing.
That is what drove me to abandon
the current <util/delay.h> routines.
It is also why I lean twards "round up" being the default.
But I'm also assuming (which may be incorrect)
that if somebody wants a long delay say >1ms they probably don't care if they
get an extra clock cycle of delay; however, at the short end for hardware type
delays you don't want 0, and you need it to be "at least as long as" as you
ask for.
That said, it is just my preference, and it can
probabaly be argued either way, there may be cases
where people want delays "up to but no longer than" a
certain value. (truncation of cycle count)
So I could live with "round up" not being the default as long it can be
configured to round up
Implication wise, I think "round up" with the better granularity
of the new delay cycles code is better and more predictable behavior than
what is there now.
I think no matter which method is the default going forward, it becomes
primarily an issue of documentation.
With respect to picking a default (round, vs truncate vs round up)
It seems easier and clearer to describe by being able to say, the
delay functions by default always provide the shortest possible delay that
satisfies the requested delay without being shorter than the requested delay.
vs if you round or round down/truncate the delay is a little less
predictable. Depending on the requested delay and F_CPU,
it might be longer (in the case of rounding calculating to round up)
or shorter or even eliminated in the case of rounding down
and allowing the cycle count to drop to 0.
==
It also seems like there is agreement that without some define
to insert the old code, there is no way to provide complete
backward compatibility and that people may want/need
different styles of cycle rounding.
=========================================================
So I'll toss out a suggestion:
What about if by default delay routines provide a delay of
"at least as long as" a delay as was requested. (round up)
*And* that there are additional defines to manipulate how
the cycle calculation is done along with a temporary
define (that will eventually be deprecated) that reverts
back to the existing code for all those that want/need
something different?
So
Round up by default
1 define to round to nearest value (up or down)
1 define to round down/truncate
1 define (that will eventually be deprecated) that
generates the old/current 3/4 loop count rounding
using the basic loop functions.
While my preference is for "round up" being the default,
any of the 3 methods could be the default.
(although allowing a delay to be reduced to 0 by default still hurts my
head)
That way everybody can get what they want and this
can be put to bed.
The only other thing that would be nice would be either
issue a warning or even crash the compile if the argument
passed to _delay_xx() was not a constant.
(But this kind of relates to the enhancement to
support variable delays and not this current bug fix)
--- bill
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?30363>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
