[En-Nut-Discussion] Low level timer functions
Ole Reinhardt
ole.reinhardt at kernelconcepts.de
Fri Jun 10 11:04:27 CEST 2005
Hi Harald,
> How do we say in Germany? "Offer him a little finger and he will
> pull off your arm." :-)
Right. I'm realy used to do so :-)
> My problem with additional timer/counter functions is, that
> it seems to be no easy solution for a hardware independent
> layer. But I'd agree that even some AVR specific functions
> will be helpful.
Yes, there won't be a real hardware independend solution, but we could
create an API for let's say the minimum common set of operating modes.
Will say, some simple timer / counter nearly every MCU has. So we could
create an api where we could ask the features of the current hardware
and then register one / two or more timers. But you'r right, this will
be hard to implement.
On the other hand hardwarespecific implementations for every plattform
would be ok to. One could try to design the api as commom as possible.
> In the meantime I think I have a nice solution for the
> crystal frequency detection, which no longer depends on
> wait states of external RAM. 'counter' is an u_long and
> just needs to be multiplied by 128 the get the frequency
> in Hz.
This one looks quite nice.
If you'r just working on the timers. I have not realy understood, why
the minimum timer resolution of the current NutOS is 62.5 ms. Could'nt
this be speeded up? Do we need the external crystal to clock timer 0 or
woul'nt it be ok to only calculate the crystal frequency and let our
clock run with only internal clocked timer0. Or even: Could'nt we run
the system timer on timer1 for example to gain a more fine granular
timer? I just was in need of shorter timeouts for several times.
Bye,
Ole
--
kernel concepts Tel: +49-271-771091-14
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen E+ : +49-177-7420433
--
More information about the En-Nut-Discussion
mailing list