Boyapati, Anitha wrote: >>> I think it can be argued either wise - "round up" or "round down". Both have >>> trade-offs. When "round up" is used, the user might end up wondering why >>> delay >>> is a little more than what he bargained for. >> Round Up might take a cycle or two or more than was asked for, which >> I doubt would surprise anyone. > > So, is it generally ok to give more delay than that is requested? I > mean, would it not run into same problems as providing less delay run into?
No, the usual case is that you're waiting for some hardware limitation (wait for capacitor to charge, wait for propagation delay, etc.). If you wait a little longer, the only consequence is that your software runs slightly slower. If you give a shorter delay the program (or device) might simply malfunction, which is much worse. >> Any amount less than what was asked for might be a big surprise when >> something goes terribly wrong because the delay was not long enough. >> >> Always go for the operation of "Least Surprise". > > Yes, the problem is figuring out which turns out to be least surpring :( My vote is for round up too, and it is the standard for delay functions everywhere. See for instance: http://linux.die.net/man/3/usleep and notice the "(at least)" in the description. Just my two cents, -- Paulo Marques Software Development Department - Grupo PIE, S.A. Phone: +351 252 290600, Fax: +351 252 290601 Web: www.grupopie.com "To be, or not to be? That is ..... liable to be removed at -O2 and above." _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
