Re: 8ms Timer for serial port access
From: Floyd Davidson (floyd_at_barrow.com)
Date: 10/30/03
- Next message: Grant Edwards: "Re: 8ms Timer for serial port access"
- Previous message: Floyd Davidson: "Re: 8ms Timer for serial port access"
- In reply to: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Next in thread: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Reply: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Oct 2003 11:23:05 -0900
byron@cc.gatech.edu (Byron A Jeff) wrote:
>In article <BBC5EE32.1D21%jens.schumache@gmx.net>,
>Jens Schumacher <jens.schumache@gmx.net> wrote:
>-Am 29/10/03 17:05 Uhr schrieb "Floyd Davidson" unter <floyd@barrow.com> in
>-87ism7vgx1.fld@barrow.com:
>-
>-> Let me add a few comments to what Grant has indicated here.
>
>And I'll add a few more.
>I realize that I have the solution too. And it won't require a bunch of work
>to implement. I ran into these same types of timing issues when I was building
>my digital synthesizer for my PhD.
>
>-> The only time one would want to call a function like
>-> serial_check_buffer() is if data is arriving asynchronously at
>-> random intervals and the program thread has something to do
>-> while waiting for data to arrive.
>
>Correct.
>
>-> Moreover, if that is the case
>-> then the only sane way to write a serial_check_buffer() function
>-> is to include a minimal sleep, which will cause 10ms of that
>-> timing granularity to be given to other processes!
>
>Correct again. sleep has a grainularity of 10ms. But my question is now
>does read and/or select have the same grainularity? What about usleep or
>nanosleep? If so then I can see why Jens is upset.
Yes. Any sleep function will give up the process's current time
slice, and that process then will not be rescheduled until at
least the minimum HZ time interval has passed.
The effect is that any sleep will have a granularity of 10ms.
>I'm interested now, so I guess I'll spend a couple of minutes setting up
>some experiments. I'll be back. OK I'm back with the first test. I have this
>loop:
>
>-------
> for(i=0;i<10;i++) {
> delay.tv_sec = 0;
> delay.tv_usec = 100;
> select(0,NULL,NULL,NULL,&delay);
> TIMER_GET(ticks[i]);
> }
>------------
>TIMER_GET is a macro that simply marks the time with gettimeofday. I have
>another routine that converts into microseconds from a start time. Here are
>the results:
>
>0: 2533
>1: 12367
>2: 22483
>3: 32533
>4: 42552
>5: 52388
>6: 62441
>7: 72364
>8: 82694
>9: 92360
>
>So there is no doubt that even though we told select to delay 100 uS, that
>it took 10 ms for it to get back to us. Bummer.
Yes, but your results (even though they are accurate) are probably not
valid! :-)
It depends on how you coded TIMER_GET. If you saved the values in
an array, and analyzed them outside of the for loop shown above,
they are valid. Otherwise...
>Here's a quick look at the sleeps [usleep, and nanosleep].
[huge snip of stuff that is interesting an accurate]
>-> But that just points out that you don't really need to read the
>-> data every 8 ms. You could read the data every 16 ms or every
>-> 32 ms and be just fine. You just get twice or four times as
>-> much data with each read that way.
>-
>-No I can't the reason comes later...
>
>I do understand. You are correct.
I don't think so... :-)
Whether the data is collected in real time, or not, just isn't
going to change what happens later. Whether that is 32ms later
or 32 days later makes no difference if the data is being fed to
a display device that updates the screen every 14ms instead of
less than every 8 ms. And, regardless of whether it did or not,
no human can actually *see* data on the screen being changed
that fast!
>-> My understanding of what Jens said earlier (and he can correct
>-> me if I'm wrong here, because I might well be) is that he is
>-> graphing the data for display, and he believes that if he
>-> doesn't grab the data as it becomes available there will be
>-> buffer overflows and he will lose the data.
>->
>-...basically right I want to display something on the monitor.
>-The reason why I have to read the data when it arrives is pretty easy.
>-I wrote earlier that I have to detect saccades. I'm doing this with a
>-5 point differentiator. Because I'm doing this online this means that I take
>-the current point and use the 4 data frames I got before. You see here is
>-already a delay of more than 2 frames for the detection.
>
>Right. So as you pointed out from the beginning, it's a soft real time process.
>
>-When I'm reading the data every 32 milliseconds, and the subject starts to
>-make a saccadic eye-movement after 8 ms, the possibility to detect the
>-saccade and to react gets pretty small. This is why it's important to get
>-every frame of data as soon as possible.
>
>Correct. So make the process run on the real time scheduler, Make sure that
>it usleeps when it's waiting, and it'll wake up right on time.
>
>-> However, if this data is being *used* for something that is time
>-> critical, then yes there is a problem. For example, if you need
>-> to read the data, and send feedback to the device *before* it
>-> sends another packet of data... that is a serious real time
>-> constraint that a standard Linux kernel is not going to provide.
>-
>-I don't need to send a feedback, but how I described, I need the data pretty
>-was after the eye-movement occurred.
>
>I hope this helps. I used the real time scheduling queue to get precise timing
>for my PhD results. I'm sure that it'll help you in your application.
Note that his input timing is *not* what determines the data
quantization intervals. That is predetermined by the device
connected to the serial port. As a result, how accurate the
timing of data collection is makes absolutely no difference in
what the data is. In fact, the data is stored a 4k byte buffer
by the serial port device driver, and it would clearly be
possible to grab chunks out of that buffer that are at least up
to 1 whole second apart, and it would not affect the data
integrity in the slightest.
Displaying the data is a whole different bag of worms though,
and nothing relating to data input is going to affect that.
-- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com
- Next message: Grant Edwards: "Re: 8ms Timer for serial port access"
- Previous message: Floyd Davidson: "Re: 8ms Timer for serial port access"
- In reply to: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Next in thread: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Reply: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
