Changing the order to this #define microsecondsToClockCycles(a) ( ((a/1000L) * (F_CPU / 1000L)) ) will avoid the overflow
The re-ordering above will break for values of (a) less than 1000 and so no good as other parts of the core depend on this working.
A simple fix might be to divide timeout by 16 prior to calling microsecondsToClockCycles as in the following: unsigned long maxloops = microsecondsToClockCycles(timeout / 16); Then you should be good up to about 4 seconds. Adding a note on this limitation to the pulseIn page wouldn't hurt either.
unsigned long maxloops = microsecondsToClockCycles(1) * timeout / 16;
unsigned long maxloops = microsecondsToClockCycles(1) * (timeout / 16);
What I proposed was just a quick fix to keep you out of trouble, but as is we will loose out on granularity and we should try to improve on this as well before proposing a change.The following patch might be a better candidate:Code: [Select] unsigned long maxloops = microsecondsToClockCycles(1) * timeout / 16;For a 16MHz clock, there will be 16 cycles per us and so we should be good up to 2^32 / 16us without overflow. That is equivalent to about 268 seconds (4 minutes and 28s). In comparison, the 022 core version will overflow for timeout's above 250ms. Granularity will be as for the current implementation across the full timeout range. No impact on other parts of the core.