On 7/12/2011 8:23 AM, Scott McNutt wrote:
Dear Wolfgang
Wolfgang Denk wrote:
What exactly is the reason that we cannot have better timer resolutions in NIOS?
You _can_ have better timer resolutions in Nios. However, there are legacy systems that implement timer(s) with a fixed period of 10 msec. The use of such implementations is very common. How do I know? Because my customers have such implementations. Why not upgrade? Because most sane engineers are loathe to change their rtl just so they can fix a simple software bug or add a simple custom feature.
My obvious preference is to continue to use the latest u-boot in such systems ... without having to create a custom branch for customers with older Nios implementations, where I use the old timer interfaces ... simply because we "improved" the API.
Scott, maybe you can comment here?
I have only one comment: Out of pure frustration, I have been avoiding any discussions regarding this timer re-write effort.
At the moment I'm trying to understand if we really have a problem on NIOS2 that cannot be fixed in a way that is compatible with our current plans.
This is where my frustration begins. I've said this several times before, and I don't know how else to say this ... but I'll give it one more try:
This is not a Nios problem.If I can't use a 10 msec timer interrupt to detect a simple timeout condition when I'm programming a flash memory, then the timer API design is garbage.
Hi All, I agree with the idea that mandating a particular timer resolution is an un-desired limitation. You may need it for some cases, but not for all. Proof of this concept is the number of legacy UNIX systems running on 10 ms timer ticks, or for that matter the number of systems running on line cycle interrupts (16.666 ms in the US). It is also however true that one cannot ignore the timer resolution. That is what produced the problem in the first place. Asking for a delay that is less than the resolution isn't going to work as expected. This problem can be easily fixed by always adding twice the timer resolution to any requested delay, to ensure you waited at least two ticks , or by having a routine that does this for you (like the suggested API does). Right now, there are many places in the u-boot code that wait a certain small number of milliseconds under the assumption that the timer resolution is either 1) not an issue at all, or 2) is 1 ms. Both cases are wrong, the first case more so than the second. I wonder how many delays in the program that say "wait 5 ms" are aware that you could exit the loop after 4ms plus epsilon every so often, even with 1 ms resolution? Perhaps the tolerance is built into the number 5, perhaps not. However, it is surely not if the timer resolution is 16.666 ms.
And quite frankly, the enormous amount of discussion in this matter reminds me of an undergraduate science project.
Or any government project. But when you will effect lots of people, you often must kill a few trees to make sure nobody (such as yourself and other NIOS users) somehow gets a bad deal.
I am now returning to "real work" and will be offline for a while. Good Luck All.
Best Regards, Bill Campbell
We also have to deal with decrementing counters, but this is just aan unimportant detail. And it appears that we actually can have this, even on NIOS.
Wow! Even on Nios! Arrggghh!
The only architecture I remember that seemed prolematic was NIOS
Really? There have been occasional issues that have required a patch here and there. But I consider most of them far from "problematic."
This is exhausting. As I recall, this entire fuss was born out of an issue with nested calls to get_timer() ... and that begat removing reset_timer ... and that begat ... and so on. And we're still spilling lots of intellectual seed here. And now we have what? A jack-of-all-trades API that can do everything with exacting precision ... other than handling a 10 msec interrupt?
Best Regards, --Scott
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot