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. ;-)

Ok! I see it that way in delay_basic.h

Actually I have calculated for _delay_ms() and it turned out to be 262.144ms 
when the maximum value of _ticks is taken as 65536 and 262.140ms when it is 
65535.

Since avr-libc library says it 262.14ms, I thought max value is 65535, not 
realizing that 262.144ms might have been truncated as 262.14ms! Hence I tried 
to apply the same for _delay_us() :-(


>
>> Also, any reason why _ticks is chosen to be uint8_t type (but not
>> uint16_t or uint32_t)?
>
>Because the underlying _delay_loop_1 uses an 8-bit value.

Yes. But why didn't we go for _delay_loop_2 kind of implementation? 

I am trying to see what factors influenced to go for a 16-bit counter in one 
case and only 8-bit counter in the other. Why not 16-bit counter for both? 

One point that can explain me is: 16-bit counter in case of _delay_us() is not 
required as for longer delays it can be promoted to _delay_ms(). But is that 
all? 

Anitha