high resolution timer

[Gu, John A. (US SSA)]

Thank you so much for the direction.

John 

-----Original Message-----
From: fedora-list-bounces at redhat.com
[mailto:fedora-list-bounces at redhat.com] On Behalf Of Erwin Rol
Sent: Friday, January 20, 2006 10:22 AM
To: For users of Fedora Core releases
Subject: RE: high resolution timer

On Fri, 2006-01-20 at 09:07 -0500, Gu, John A. (US SSA) wrote:
> The ADC will do nothing until a trigger command written into its 
> register. It then makes a sampling, and within a usec it puts the 
> digital data in another latched register mapped into IO address for 
> the program to read. This is called the single operation, in other 
> words, no trigger no sampling. Though it is capable to have a maximum 
> sample rate of 10K per second, but it all depends on how fast and 
> accurate the program can do.
> 
> Assume this is the only thing the SBC is doing. Do you think the logic

> described below will work?
> 
> 1. The application (user space) initializes ADC 2. The application 
> issues a read() to the driver for data 3. The driver does not return 
> the read() until finishing 1000 loops for 1000 samples 4. Within each 
> loop, the driver issues a trigger command, waits for 1 usec,
>    reads the result, puts it in a buffer and waits for another 99 (may
> be) usec
> 5. Returned from the read(), the application receives 1000 data 
> sample, it then issues
>    another read() immediately. So it issues 10 read() per second
> 
> Does this operation impact the kernel operation, such as timeofday or 
> other interrupt driven events?

First of all, when you need to trigger your hardware 10000 per second to
get a steady stream of samples, you have pretty poor hardware. 

Than your example has some serious flaws.  For example what happens
between  step 4 and 5 ? Since your "userspace program" just used up
100ms it is highly likely it will have to make place for other usespace
programs, meaning it will take way more than 100us to restart the next
read. But even if it would start the next read in time it means you will
freeze your complete machine, since because it has no time for anything
but the busywait loop.

If you need a guaranteed stream of 10k samples/s you will not be able to
do it with the standard kernel. Your only options are to use one of the
realtime extensions, or to use hardware that can buffer the samples so
you only have to read, for example, a block of 1000 samples at the time.


With RTAI you could for example create a periodic task that runs every
100us (this is possible with a jitter of about 10-30 usec) . In that
task you only do trigger, read, store in FIFO. A userspace application
can than read from that FIFO. This still will put a high load on your
machine, but it has been done before.  Trying to do something like that
with the standard kernel will _NOT_ work. And even with RTAI it will be
hard to get it right, because you still have a jitter of about 20us on
your sample clock, and so the sample time is not very accurate (unless
it is supported by hardware in some way).

You really should take this discussion to the RTAI or rtlinux mailing
list, since the people there actually build systems like you want,
unlike the people on this list that "just" use Fedora.

- Erwin


--
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list