Seb, You wrote: > IIRC internal _usec_delay() procedure is valid for speed >= 4MHz (have seen > it in a > doc somewhere).
You probably read the unequalled (but outdated) manual of Javier, Dave and Vasile ;) It states: > For clock speeds 4MHz and higher, the delay is exact assuming interrupts are > not enabled. And together with the test results I suspect this means that below 4 MHz, loops can be inaccurate due to rounding issue's - a single instruction takes more then 1 us. It looks that longer delays still are accurate. The the trouble is in the overhead code - calling the delay procedure, conditional code and loops.No problem if we have multiple ms delay, but it is when we have a 10us resolution. A work around would be to add delay_100us - delays shorter then 1ms but more accurate then 10us-based. Or... we should count the # of overhead instructions, calculate the time required at the current clock speed and subtract this from the actual delay generated. Joep PS I intend to change the 1ms_delay paramater from byte to word, so delays up to 65 sec are supported. Or does anyone see a reason not to? 2009/8/4 <[email protected]>: > > > Comment #2 on issue 83 by jsuijs: delay.jal accuracy varies > http://code.google.com/p/jallib/issues/detail?id=83 > > first results: > > Target clock: 1000000 ---------------------------- > Test us delays > Test 0 us, measured 0 us > Test 1 us, measured 4 us > Test 2 us, measured 4 us > Test 5 us, measured 8 us > Test 9 us, measured 12 us > Test 10us delays > Test 10 us, measured 76 us > Test 20 us, measured 104 us > Test 50 us, measured 312 us > Test 100 us, measured 472 us > Test 200 us, measured 792 us > Test 500 us, measured 1752 us > Test 1000 us, measured 3352 us > Test 2000 us, measured 6552 us > Test 1ms delays > Test 1000 us, measured 1088 us > Test 2000 us, measured 2080 us > Test 5000 us, measured 5152 us > > Target clock: 4000000 ---------------------------- > Test us delays > Test 0 us, measured 0 us > Test 1 us, measured 1 us > Test 2 us, measured 2 us > Test 5 us, measured 5 us > Test 9 us, measured 9 us > Test 10us delays > Test 10 us, measured 24 us > Test 20 us, measured 38 us > Test 50 us, measured 108 us > Test 100 us, measured 178 us > Test 200 us, measured 318 us > Test 500 us, measured 738 us > Test 1000 us, measured 1438 us > Test 2000 us, measured 2838 us > Test 1ms delays > Test 1000 us, measured 1016 us > Test 2000 us, measured 2016 us > Test 5000 us, measured 5016 us > Test 10000 us, measured 10024 us > Test 20000 us, measured 20040 us > > Target clock: 8000000 ---------------------------- > Test us delays > Test 0 us, measured 0 us > Test 1 us, measured 1 us > Test 2 us, measured 2 us > Test 5 us, measured 5 us > Test 9 us, measured 9 us > Test 10us delays > Test 10 us, measured 16 us > Test 20 us, measured 27 us > Test 50 us, measured 74 us > Test 100 us, measured 129 us > Test 200 us, measured 239 us > Test 500 us, measured 569 us > Test 1000 us, measured 1119 us > Test 2000 us, measured 2219 us > Test 1ms delays > Test 1000 us, measured 1004 us > Test 2000 us, measured 2004 us > Test 5000 us, measured 4996 us > Test 10000 us, measured 9988 us > Test 20000 us, measured 19964 us > > Target clock: 20000000 ---------------------------- > Test us delays > Test 0 us, measured 0 us > Test 1 us, measured 1 us > Test 2 us, measured 2 us > Test 5 us, measured 5 us > Test 9 us, measured 9 us > Test 10us delays > Test 10 us, measured 10 us > Test 20 us, measured 20 us > Test 50 us, measured 54 us > Test 100 us, measured 100 us > Test 200 us, measured 192 us > Test 500 us, measured 468 us > Test 1000 us, measured 928 us > Test 2000 us, measured 1848 us > Test 1ms delays > Test 1000 us, measured 1000 us > Test 2000 us, measured 1995 us > Test 5000 us, measured 4982 us > Test 10000 us, measured 9965 us > Test 20000 us, measured 19928 us > > So pretty good from ms and up; 10us() could be better. > Would 1, 4, 8 and 20 MHz be good measure / calibration points? > Or would just 20 and 8 be enough? > > (Seb: chang of clock speed is not supported - target_clock definition > determines > delay). > > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
