>-----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. ;-)
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 _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev