Re: Can I expect in-kernel decoding to work out of box?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 28, 2010 at 10:36 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote:
> As an example of simple hardware glitch filter, here's an excerpt
> from the public CX25480/1/2/3 datasheet on the IR low-pass (glitch)
> filter that's in the hardware:
>
> "the counter reloads using the value programmed to this register each
> time a qualified edge is detected [...]. Once the reload occurs, the
> counter begins decrementing. If the next programmed edge occurs before
> the counter reaches 0, the pulse measurement value is discarded, the
> filter modulus value is reloaded, and the next pulse measurement begins.
> Thus, any pulse measurement that ends before the counter reaches 0 is
> ignored."

You could make a small library that drivers could link in. That way we
won't get it implemented ten different ways. Devices that do the
filtering in firmware won't have to use the code.

There are lots of ways to design it. A simple one would be to sit on
each message until the next one arrives. Then make a decision to pass
the previous message up or declare the current edge a glitch and wait
for the next one.  It probably needs a timeout so that you don't sit
on long pulses forever waiting on the next one.

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux