Jonathan Larmour wrote:
In practice I don't think there are any timers which require better than
100ms granularity, and I doubt a little inaccuracy delaying a timeout by up
to 55ms would really affect much (as long as it isn't up to 55ms _early_).
Although in any case, PC hardware is actually pretty standard - with
backward compatibility still present for obscenely ancient devices. Usually
you can use the Periodic Interval Timer anywhere. You can see a usage
example in eCos here(hal_pc_clock_initialize and hal_pc_clock_read):
http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/i386/pcmb/current/src/pcmb_misc.c?rev=1.9&content-type=text/x-cvsweb-markup&cvsroot=ecos
with some info from:
http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/i386/pcmb/current/include/pcmb_intr.h?rev=1.5&content-type=text/x-cvsweb-markup&cvsroot=ecos
It uses interrupt IRQ0 i.e. 32.
IRQ 0 is INT 8 in the BIOS environment, not 32.
And yes, PC hardware is pretty standard... but there isn't a whole lot
of arbitration (who owns what resources) in the pre-OS environment. As
such, you risk finding something else trying to play the same tricks.
Once the OS boots, the OS is resource manager, and that particular
problem doesn't exist in the same way.
Sounds like 55 ms is adequate resolution, so doing more advanced PIT
hackage is probably not necessary.
-hpa
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
