Hi Lefty,Rationale for that statement is the fact that a function call takes approx 1 usec. Checking the param takes some clock cycles too. So before one can start to count down, too much time may have passed already (for small values). The root cause is that one is near the cpu speed. But mapping 0 usec on 16K usec is a serious Bug - with capital B For the Due which is 84(?) Mhz I expect a re-implementation for this function. However no experience yet with the Due.
// busy wait __asm__ __volatile__ ( "1: sbiw %0,1" "\n\t" // 2 cycles "brne 1b" : "=w" (us) : "0" (us) // 2 cycles
The delayMicroseconds() implementation ends withCode: [Select] // busy wait __asm__ __volatile__ ( "1: sbiw %0,1" "\n\t" // 2 cycles "brne 1b" : "=w" (us) : "0" (us) // 2 cycleswhich is a tight loop decrementing the var us. So I think the timing is quite precise for values > 2. This loop takes 4 cycles so it is executed 4 times per usec (16Mhz assumed).The stepsize of 4 usec is the precision of the micros() function so if you want to measure time smaller than 4 usec you need a HW timer solution. Can't find the link now.
Find test program and patch below : NOTE the patch does not include the 1.0.2 20Mhz addition as I cannot test it .