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. And quite frankly, the enormous amount of discussion in this matter reminds me of an undergraduate science project.
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