|
[DPRG] V4L capture loop timing constraints
Subject: [DPRG] V4L capture loop timing constraints
From: Dave Hylands
dhylands at gmail.com
Date: Fri Jun 1 09:09:04 CDT 2007
Hi Chris,
> My experience with this using the Michael Xhaard spca5xx driver
> on a 200 MHz ARM9 PC104 SBC is tight timing constraints between
> ioctl calls. In my application (Stella the robot), frame
> processing must be between 70 to 80 ms or else most captured
> images are corrupted. Unfortunately, I am stuck with a 2.4.x
> kernel so can not provide timing resolution better than 10 ms
> granularity.
Even with 2.4.x you can change the tick rate of the kernel. Some
hardware makes it easier than others. I seem to recall with the ARM
that there were a couple of hard-coded places I had to change along
with the standard change of HZ in param.h
For the Intel, there is a project called high-res timers which made
high resolution timers available.
http://high-res-timers.sourceforge.net/
I see downloads for 2.4.19 and 2.4.20.
> At 10 fps, 100 ms separates each frame. If 20 ms is spent in V4L
> and OS overhead, then 80 ms remains for processing each frame.
>
> I know some DPRG folks have worked on UAVs with video cameras
> running Linux. There were similar frame corruption problems.
> Was there a timing constraint in the capture loop of this kind?
The 10ms thing is just the frequency of the timer tick. You can
certainly process stuff faster in response to interrupts.
Ideally, you want to do as much processing in kernel mode as you can.
context swithces are expensive, and the kernel is non-preemptive. So
while one user-mode program is making a system call, other kernel mode
programs are blocked out.
The low-latency patch was available for the ARM in 2.4, but the
preemption patch wasn't.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
More information about the DPRG mailing list
|
