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. ;-) > 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. _delay_loop_2 uses a 16-bit value, and that's what _delay_ms() is based on. That doesn't imply you could not achieve shorter delays, since e.g. _delay_ms(0.8) is completely acceptable. It's just the increased granularity of _delay_loop_2 makes it preferrable for longer delay. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
