On 25/04/2014 09:44, David Gálvez wrote:
Alan and anybody else who wants to give an opinion, what ColdFire
udelay approach do we take?
As Markus said, the BaS (used by EmuTOS on the FireBee) and FireTOS
(FireBee and EVB) use the Slice Timer 0 (SLT0) for internal usage.
When EmuTOS runs on the EVB, there is no BaS (yet) so it has to do
anything by itself. Currently, it uses delay loops for small delays
and the General Purpose Timer 1 (GPT1) for minimal Timer C 200 Hz
emulation. It uses hardcoded values depending on the generated binary
(FireBee or EVB). The SLT0 is not used in such configuration. As a
result, anything based on SLT0 will not work on EmuTOS on the EVB.
Currently, for small delays on any machine, EmuTOS uses a calibrated
delay loop. While this is ugly, it seems to be perfectly accurate on
any machine. Linux seems to use a similar approach.
But in any case the delay with SLT0 won't work with FireTOS on
evaluations boards, but I don't think there are many users (if any)
running MiNT on those boards.
In early days, FreeMiNT had been patched for FireTOS on EVB, and it
worked fine. I'm not sure if it still works, if not that should be
fixed. Currently, FreeMiNT does not work over EmuTOS on EVB. There are
a few minor things to fix, that's on my TODO list.
As a result, I would say: let's keep David's current patch based on
delay loops, as it is supposed to work in the general case. Then we
could fix it later (or improve it) if something appears to be wrong on
some machine.