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

[Anitha Boyapati]

Update of bug #30363 (project avr-libc):

                  Status:                   Fixed => In Progress            

    _______________________________________________________

Follow-up Comment #9:

>> 2) How to round cycle delay values (up, down, closest)
>> Maybe have a compile time ifdef to set this? 


Compilation time #ifdef sounds logical with truncate possibly as a default
value. A quick implementation would probably look like:

        #if defined(__DELAY_REQUIRES_ROUNDING__)
                //FIXME: what if _tmp is -ve?
                __ticks_dc = (uint32_t)(__tmp+0.5);

        #elif defined(__DELAY_REQUIRES_CEILING_)
                __ticks_dc = (uint32_t)(ceil(__tmp));

        #else
                //truncate by default
                __ticks_dc = (uint32_t)__tmp;
        #endif

 So, ticks less than zero now will not have special treatment. They have to
be either rounded up, down or closest as is chosen at compile time.


>> 3) How to deal with very long delays that go beyond
>> the longest delay possible with the underlying delay
>> mechanism.

I think it may not be prudent to support longer delays in milli seconds and
in micro seconds. The maximum delay that was supported in the older code
(prior to fix) is 6.5535seconds with decreased resolution. The current fix
makes it 4294967.295 ms or appx 4294.9s. Any delay beyond this, in my opinion,
is definitely possible but probably as a new function _delay_seconds().
Comments ...?


>> 4) backward compatibility 

So far I haven't got any clue on how to make it backward compatible.
_HAS_DELAY_CYCLES_ is used during avr-libc compilation itself. As of now, once
the file delay.h is generated from delay.h.in, it is not possible to use the
old code. 

Given that current implementation has much better granularity, I think old
code should probably be deprecated. I really would like to know others opinion
on this.


>> 5) supporting delays using variables (non constants). 

Can you give one use case for this that would be help me understand better?
If this is something new and not related to current bug, maybe it is good to
file a new bug and resolve it.


Thanks for suggestions. They are really helpful. Also, I just realized that
the patch I had submitted earlier contained couple of issues.

If we agree on issue #2 and #4, then the patch is ready :-)




    _______________________________________________________

Reply to this item at:

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

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