Hi Wolfgang,
On Tue, May 31, 2011 at 4:03 PM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message BANLkTikZUkk1EaYqCg=5mB2npva2iE6Lew@mail.gmail.com you wrote:
Don't forget the API will have a get_current_ms() so we can do duration
I don't think we will have this.
We have get_timer() (or, as recently suggested, renamed it into time_read() or similar). We don't need yet another function that dioes the same just by a different name.
No, I did not mean a new function which does the same as an existing function - I just meant there would be a function to give us current ms which means any 'wait_until_ms(x)' style function is ripe for 'abuse'
bypassing the resolution correction. If time_reached() did the resolution correction, would this solve the problem of API misuse (yes, I know it puts a complicated calculation back in the loop)
Complicated? Come on, guys.
And please don't forget thatthese are usually delay or timeout loops, so who cares how long it takes?
Yetch! - We will not be exposing ticks!
Oh, I'm no so sure about this. We will not use it in common code, but the interface should be available for special purposes.
Well yes, the suggested API does expose ticks via get_ticks(). And my current demo implementation also stores ticks in global data as a storage for 'last ticks' in order to do tick deltas to calculate us/ms deltas...
I like simple as much as the next guy - I also like hard to misuse ;)
NAK. What you today consider "misuse" might actually be a clever solution to my problem tomorrow.
Well now that we are doing much more stringent peer reviews on new code (and re-written code) I guess the misuse argument does become a little bit irrelavent
An SPI is good then the standard solution actually covers 99.9% of all use cases and is so convenient to use that you don't even think about doing it differently. But it is extremely useful when you also can use it for things the designer/implementor never even dreamt of.
So don't try to prevent "misuse".
OK
Regards,
Graeme