BenF:
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:
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.
I don't see this fix in the release note for 023 or 1.0. Did it make it?