RE: [avr-libc-dev] _delay_us() - Documentation for maximum possible delay

[Boyapati, Anitha]

>-----Original Message-----
>From: Joerg Wunsch [mailto:address@hidden
>Sent: Monday, October 04, 2010 3:18 PM
>To: address@hidden
>Cc: Boyapati, Anitha
>Subject: Re: [avr-libc-dev] _delay_us() - Documentation for maximum
>possible delay
>
>As Boyapati, Anitha wrote:
>
>> The above link says, the maximal possible delay for _delay_us() is
>> 768 us / F_CPU in MHz. However, as per the below computation, it
>> should be 765us.  (Max value of _ticks when it is of uint8_t type is
>> 255.)
>
>No, the max value is 256, even though it is represented as 0. ;-)

I went on revisiting this. Sure I was missing something. Now I know what. 
Please correct me if I go wrong somewhere :-)

I agree that max value of _ticks is 256 which is actually represented as 0. But 
as per the current implementation:

else if (__tmp > 255)
 {
     _delay_ms(__us / 1000.0);
        Return;
}

i.e. as soon as the _tmp value becomes little more than 255, _delay_ms() is 
called. _ticks therefore never becomes zero. Thus _delay_loop_1() is never 
called with '0'. So, technically a maximum delay of 765us can be achieved but 
for all values above 765us, _delay_ms() will be called. However no difference 
in the output will be observed as _delay_ms() gives necessary delay.

In my opinion, this is probably a minor issue. Either the documentation needs 
to be corrected or the implementation (conditional check can be (_tmp>256)). 
Right now, they are a little out-of-sync.



Anitha