[avr-libc-dev] [bug #30363] _delay_xx() functions in <util/delay.h> are broken

[Anitha Boyapati]

Follow-up Comment #11, bug #30363 (project avr-libc):

>> Other than loop/cycle count truncation was the previous way of
>> doing things, what is the reasoning for preferring truncation 
>> to be the new default vs "round up" as the default going 
>> forward?

It is mostly driven by the previous implementation. 

>> "round up" as a default would require the user to have to 
>> define something to ever get a delay that is less than what 
>> is asked for

I think it can be argued either wise - "round up" or "round down". Both have
trade-offs. When "round up" is used, the user might end up wondering why delay
is a little more than what he bargained for. 


>> I am worried about delays being reduced or even eliminated 
>> due to cycle count truncation to 0 or rounding cycle count 
>> down to 0 because this is creating a different behavior than 
>> the previous code. 

>> For example, if somebody called _delay_us(.500) and was 
>> running on 1Mz clock. Previously they got a 3us delay, but if 
>> truncation is the default and there is no bump to a non zero 
>> number of cycles, they would get no delay, which might not 
>> work. 

Even if "round up" is used, a clock cycle of '1' is given out for cases where
cycle count is 0.*. It is still different from the expected 3 cycle clock.
This has to be corrected anyway. How would "round up" solve the situation? or
rather how can introducing non-zero delay make any difference?

I am open to considering "round up" as default option. However, I am trying
to understand the full implication of it, if there is any.


>> I'm assuming ceil() is a gcc builtin or
>> could be something like this?

ceil() is from avr-libc. I planned to re-use available functions for
optimization considerations.

http://www.nongnu.org/avr-libc/user-manual/group__avr__math.html#ga61470611f23ceef5d3e9cf63d84cd8a7

I'll talk about backward compatibility in next comment.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?30363>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/