On Tue, May 24, 2005 at 08:46:58AM -0400, Bryan Mayland wrote: > Axel Thimm wrote: > > >Is this true? The firmware is 14KB, that would be a rate of less than > >3KB/sec or 23739 bits/sec. Isn't that too low for a 100KHz i2c > >transmission? Theoretically the tranferrate should be more like 10-12 > >KB/sec > > > > > Yes, ideally you could get 12KB/s out of 100KHz. The bit-shift > algorithm used to send the bits however has some overhead. (This > information is from linux-2.6.8-24.14 i2c-algo-bit.c) > > For every bit sent: > setSDA > udelay > sclHI (set and wait for SCL to go hi) > udelay > setSCL(0) > udelay > > For every byte sent: > sdaHI > udelay > sclHI > udelay > getSDA > sclLO > udelay > > So for every bit, there's minimum 3 * udelay, and for every byte an > additional 3 * udelay. 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. :( > >ivtv is using i2c_master_send on the whole image, does anyone know if > >i2c_master_send framents the block into too many small messages? That > >could explain the delay. Alternatively perhaps the comuptation of > >fw->size in request_firmware is wrong? > > > > > i2c_master_send just calls the i2c-algo-bit sendbytes() with the > entire 1000 byte buffer, which is then transmitted as above without > being fragmented. fw->size appears to be accurate too. I think > everything is going as planned. 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 contaced Hauppauge engineering and asked about this. This was done > >in older code and was abandonded due to problems (I have no > >information about the nature of the problems). > > > I've dug through the their driver code from pvr150_inf.zip, > hcwpp2.sys (dated 2004/10/6) and this is the only firmware upload > routine that exists (to the best of my disassembly knowledge, which is > pretty good). The "Win-TV PVR Update" pvr150_22_22292.exe does not > contain an updated hcwpp2.sys at all. Are they sure they abandoned it? > I don't have a windows box I can check driver versions on, but I'm > resonably certain I'm looking at the right driver. They sounded quite firm. -- Axel.Thimm at ATrpms.net
pgpBUXjkayw6K.pgp
Description: PGP signature
