J. William Campbell wrote:
On 5/27/2011 6:07 AM, Scott McNutt wrote:
Graeme Russ wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message BANLkTik2SUm4Sm8aLjCrCmz+kcMGWgEzKw@mail.gmail.com you wrote:
Besides, Nios can return an increment of 10 (presumably ms) between two immediately consecutive calls. This causes early timeouts in CFI driver
Now this in turn is a bug in the timer implementation that needs to be fixed.
And this is what reset_timer() corrected.
Agreed, but that is not something I can achieve - I don't want to hold up this whole show that we have all put so much effort into for the sake of one weak function
And I don't want to see something that currently works become broken because we "improved" a feature ... simply because the resolution of the timestamp is 10 msec rather than 1 msec.
And just to be clear. This is not a Nios issue. Currently, if the timestamp is incremented via a fixed period interrupt, and the period of the interrupt is longer that 1 msec, calls to get_timer() may produce early timeouts ... regardless of platform.
<snip>
This can be fixed in get_timer, making the 8 ms delay become a minimum of 10 ms at the expense of it becoming up to 20 ms sometimes.
Ok. Now I get it. Thanks.
<snip>
This reset approach is bad in that it prevents proper nesting of timing loops.
In my particular case, because reset_timer() resets the timestamp to zero rather than simply restarting the timer. I believe leaving the timestamp alone would solve the nesting problem.
<snip>
The other fix is in my opinion nicer, because it affects the nest loops less. If the inner loop is executed 100 times, with the reset, the outer loop timeout is extended by up to 1000 ms.
Bill, thank you for explaining -- probably for the nth time -- but it did finally sink in.
Regards, --Scott