Axel Thimm wrote:
This makes byte transmission speed at best ((3 *
8) + 3) * udelay or 25 udelay = 25us. 1 / 0.025s = 40 bytes/s max.
You probably mean 27 udelay * 10us/udelay = 270us, which would be 1 /
0.00027s = 3703 bytes/s. Since the firmware is 14K that would lead
indeed to about 3.8 sec. :(
haha yeah you're right. I used to be good at math, but not at 8am.
I don't know how my wild inaccuracy made sense at all; I'm glad you
managed to salvage it. Just using jiffies to time the firmware load, it
consistently takes 4096 jiffies on a HZ=1000 kernel (4 sec).
Perhaps the bit-shift algorithm should not be used, but instead
something else. Is there something else, or would one need to write a
new one?
I'm pretty sure that's the only algorithm that is supported by the
cx25840 (while in two-wire serial mode). As someone already pointed out
though, the cx25840 supports a 400Mhz bus speed so the chip itself it
capable of a 3us delay (which would be 333Mhz if my math has improved
since this morning). Of course, doing this probably screws up other
devices on the bus, which is probably the "problems" spoke of by
engineering.
There's also the VIP interface which is supposedly faster, but you
can't run I2C and VIP at the same time, and I'm pretty sure you can't
switch back and forth. I don't know anything about VIP either.
Are they sure they abandoned it?
They sounded quite firm.
I'd be frustrated, except I had to chuckle that you used the word
firm when we're talking about firmware upload :)
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
