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.
-- Vincent Rivière