[mythtv-users] HDPVR IR blaster slow

[Joseph Fry]

>
> >> > I know that i2c_master_send can handle up to 64k... so I think I may
> try
> >> > and
> >> > force it to send everything in one go rather than breaking it up.  I
> >> > doubt
> >> > it will work, but it would be interesting if it did.
>
> i2c_master_send() does indeed have that 64K limit, but many actual I2C
> master hardware implementations can't support anywhere near that.
> It's not uncommon for them to have length limits on the order of 16 or
> 64.  In other words, don't assume that just because the Linux
> framework supports sending messages up to that size that the hardware
> itself can support it.
>
> >> > Beyond that, I can't see anything else to do to make this faster.
> >>
> >> You will likely have to look at the IC datasheets, HD-PVR schematics,
> >> and HD-PVR firmware (only the first is likely publicly available) to
> know
> >> what can be sent across the i2c bus.  It can be fun experimenting and
> >> reverse engineering, but it may not be successful.
>
> Bear in mind that the Windows driver implementation for the ZIlog was
> originally written for the much older PVR-x50 cards (which is what got
> copied through reverse engineering into the Linux implementation).
> Hence it's likely that I2C masters in newer hardware designs such as
> the HDPVR don't have the 4-byte limit - but bear in mind that if you
> change the driver than it will likely be rejected upstream since it
> would break interaction with older products that use the same driver.
>
> >> At some point, it is likely going to be worth your time to simply
> purchase
> >> another transmitter (but you probably already knew that).
> >>
> >> Good luck.
> >
> >
> > Believe it or not... it works fine passing all 400 bytes at once.  Shaved
> > the time for 10 key presses from over 10 seconds to under 9 seconds...
> sigh.
>
> Correct, the I2C master on the Ambarella doesn't have the 4-byte
> limit.  I have an implementation which I've used in house which puts
> the whole blob out in a single transaction.
>
> The bulk of the time won't be clocking out the bytes for the
> particular RC code.  It's the last I2C message which says "go" once
> the RC blob is fully loaded which is going to block until the code is
> fully transmitted (and RC codes themselves can have a delay at the end
> after clocking out the last pulse).  Also bear in mind that how long
> it takes can vary based on the particular RC codeset and protocol that
> your particular STB requires.  Hence it's entirely likely that other
> people may say that it works much faster if they're talking to a STB
> that doesn't require as much delay between keys.
>
> Just as a test, you may wish to fire the HDPVR up under Windows and
> see if it exhibits the same behavior.  That will tell you definitively
> if the Linux driver is doing something that is outright dumb (i.e. not
> properly emulating the Windows behavior), or it it might just be a
> limitation of the particular RC codeset required for your STB.
>

Well... testing in windows does seem to indicate that it's an issue with
the codeset as it's every bit as slow there as in linux.

I guess I will just have to accept it as is for now, until I can find
something better.

Speaking of better, I know the MCEUSB devices are the best supported, but I
can't seem to find anything that has multiple transmitters.  I know I had
an old ehome unit that had two emmitter ports, but I am not sure they were
independently addressable.

I would welcome suggestions of a working solution for 4 emitters that is
dirt cheap and easily implemented (would rather not have to compile drivers
for each one and whatnot).

Thanks everyone for your input on this... it's been fun getting into the
code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150620/9ae947fc/attachment.html>