>-----Original Message----- >From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de] >Sent: Monday, October 04, 2010 3:18 PM >To: avr-libc-dev@nongnu.org >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 _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
