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.
Hi All, A more precise statement of the problem is that all timer delays may be shortened by the timer resolution. So this means that if you have a timeout of 1 ms in your get_time(0) { } while ( ... < 1), then your actual delay may be anywhere between 0 and 1 ms. The problem arises when some piece of common code uses a delay of say 8 millisec, expecting the actual delay to be between 7 and 8. If the resolution is 10 ms, the delay will be between 0 and 10 ms, 0 being particularly bad. 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. Since these delays are used mostly for error conditions, making them longer will probably be ok, and doesn't require changing any of the common code. It probably will not make things slower either, because the error timeouts should not be reached. The reset of the hardware timer would cause all "short" delays to become 10 ms. This reset approach is bad in that it prevents proper nesting of timing loops. However, in this case it isn't so bad, in that the nested loops are just extended, not shortened. Note that if the reset is only resetting the HARDWARE interrupt generator, not the actual timestamp itself, we are just extending all existing timeouts by 0 to 10 ms.. So this just lengthens all pending timeouts. 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.
Best Regards, Bill Campbell
--Scott