Dear "J. William Campbell",
In message 4E1CF2E0.1030702@comcast.net you wrote:
Yes, this is true. However, the time_elapsed_since routine can dothis dynamically (i.e. add twice the timer resolution) . I think you had
That would IMHO be a very bad idea. We have a number of places where we have to deal with pretty long timeouts (usually because of protocol specifications that require this - often in the order of several seconds), where the normal path is very fast. The typical approach is to break the timeout into a large number of very short loops. Sometimes we use udelay() for this, other places use get_timer().
So assume we have a timeout of 5 seconds, and implement this as 50,000 loops of 100 microseconds. If you silently turn each of these into 20 milliseconds on NIOS, the timeout would become 1,000 seconds instead of 5 - users would return boards as broken and report "it just freezes" because nobody expects that it will wake up again after some 16 minutes.
another function name (at_least) involved, but you can define time_elapsed_since as always compensating for the resolution. That will fix any resolution questions in a processor-specific way. It is either that or the ifdefs. One way or another, the resolution must be addressed. Up to now, the implicit resolution has been 1 ms, but we now know that is not general enough.
It's not as simple as this. You have to change a lot of code to make this work for such slow clock systems.
Best regards,
Wolfgang Denk