In message FD2AC9A020DDD51194710008C7089B20053D4C16@dlee17.itg.ti.com you wrote:
About how accurate in practice does the udelay() & other time base functions have to be? especially for ethernet/networking devices? I've currently got
Have to be? Typically these functions are used either to implement some timeouts or delays, which usually have some reserve, or to implement user interface stull like the count down or sleep commands - which is not critical either. So probably nobody would notice if the timer was 20% fast or slow.
But then, these services are derived from the timebase, which runs with the same precision as your clocks. Only for very small delays (like if you try to get a bit-banging I2C driver with a bit clock over 100 kHz) you will notice that timings are inaccurate because of the function call overhead.
So - why are you asking? There is no problem with the accuracy of udelay() etc.
enough of the basics ported for my arm925/omap based board such that it comes to a u-boot shell, and things like sleep x work....I was thinking about moving on to getting my ethernet device working, and am a little
What has udelay() or other timing functions to do with ethernet?
uneasy about the way I (and it appears several others) have hacked the time conversions. Does gcc provide some nice 64 bit integer manipulation libraries which aren't huge? If so I'd be tempted to bring in some code
Which sort of libraries do you need? If you really think you must you could use "log long" data types, but I don't see any need for that.
which does the right thing and doesn't have to worry about integer over/under flows.
What exactly are you talking about?
Maybe you should explain the problem you are trying to solve. I feel you must be on a wrong track...
Best regards,
Wolfgang Denk