[Freemint-list] Broken udelay() for m68000

[Miro Kropáček]

>
> Maybe i didnt explain it clearly. Yes, i totally agree, using cpu cycles
> for
> timing matters isn't going to work well. You can only do that on embedded
> systems, where you know the hardware in advance, and probably don't have
> any
> better choice because there is no timer hardware.
>
You did, I was just reading too early in the morning. :-)

You are right, resolution less than 5ms is a problem. Two observations:

a) majority of mdelay() calls requires more than 5ms (usually even on 5ms
boundaries)
b) majority of mdelay() calls is new code (!) like usb or network drivers,
i.e. super time critical stuff communicating with hardware

So I think at some point in time there was a bad decision taken ("Look,
mdelay()! What an useful call!") and quickly got spread in the other parts
of the code.

What about using the well known, kernel treated, Tgettimeofday():

*The time value will be calculated from the number of
200-Hz-timer-interrupts.  This will give an accuracy of 5000 ms *(I think
they mean 5000us here)*.  The microseconds inbetween are interpolated from
the value found in the timer-c data register.  This counter down from 192
to 1 once per timer interrupt period.  This provides an accuracy of little
more than 26 us.*

This sounds pretty good to me, certainly much better than literally a
random value returned by mdelay().

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20171015/47a8efe0/attachment.html