For th 4 byte i2c exchanges: Those are basically writing to two
conseuctive registers with only one i2c command, so the following d0
5d 03 03 ce 05 02 10 would look like this in your init { 0x03, 0x03ce
}, { 0x4, 0x0502 }. Notice the registers used only differ by 1 not two
since micron sensors use a register that is two bytes wide.
Also yes when working from windows usb dumps you will see multiple
writes to the same register usally you cna trim most of those out
using only the last written value. however if you are trying to make
it work its probably best to copy the i2c writes that windows does and
after it works trim out unneeded ones.
On Wed, Feb 4, 2009 at 2:15 PM, Korvin <[email protected]> wrote:
>
> After some usb sniffing I made own init table based on actual data going
> through.
>
> I wrote simple script that parses SniffUSB's logfile and grabs meaningful
> information, then formats it according to I2C proto, mainly from
> sn9c20x_write_i2c_data_ext() function.
>
> here it is (assuming that start.log is the input file):
> #!/bin/sh
> cat start.log | grep -P -B5 'Value\s+\=\s+000010c0' | grep -n -P '00000000:
> (b0|d0)' > dump
> cat dump | grep -P ':\sb0.*' | awk '{print $1 " { 0x" $5 ", 0x" $6 $7 " }, "}'
>> table_b0
> cat dump | grep -P ':\sd0.*' | awk '{ printf("%s { 0x%s, 0x%s%s }, { 0x%x,
> 0x%s%s },\n", $1, $5, $6, $7, strtonum("0x" $5)+2, $8, $9) }' > table_d0
> cat table_b0 > table_unsorted
> cat table_d0 >> table_unsorted
> cat table_unsorted | sort -n > table_sorted
> cat table_sorted | sed -r 's/[0-9]+\:\s+//' > table
>
> Of course it's not as pretty as it may be, but it works at least for me :)
>
> Note: script is written in assumption that we need to parse only two types of
> commands:
> 65: 00000000: b0 5d 3a 73 00 00 00 10
> 79: 00000000: b0 5d 06 90 1c 00 00 10
> 93: 00000000: b0 5d f0 00 00 00 00 10
> 107: 00000000: d0 5d 01 00 10 00 60 10
> 121: 00000000: d0 5d 03 03 ce 05 02 10
> 149: 00000000: b0 5d c8 00 03 00 00 10
> 163: 00000000: b0 5d 0a 00 01 00 00 10
> 177: 00000000: b0 5d 06 00 06 00 00 10
>
> Status bytes b0 (1011 0000) and d0 (1101 0000) encoding
> 11b - 1 = 2 and 101b - 1 = 4 byte data lenghts. MSB and lower 4 bits are
> ignored.
>
> Other command appeared only with zero sized data blocks (90), and strange
> sequence a2 5d 00 00 00 00 00 10 which I don't know how to handle. Write to
> zero address? Or it is sensor detection as I heared somewhere?
>
> One thing I need to ask: I2C exchange contains four byte writes. I do not
> know, how to parse it correctly. Now it is translated into two consecutive
> writes with address increment by 2.
>
> Final otput of the script:
> { 0x0d, 0x0000 },
> { 0x0d, 0x0008 },
> { 0x0d, 0x0009 },
> { 0x0d, 0x0008 },
> { 0xf0, 0x0001 },
> { 0x3a, 0x7300 },
> { 0x06, 0x901c },
> { 0xf0, 0x0000 },
> { 0x01, 0x0010 }, { 0x3, 0x0060 },
> { 0x03, 0x03ce }, { 0x5, 0x0502 },
> { 0xc8, 0x0003 },
> { 0x0a, 0x0001 },
> { 0x06, 0x0006 },
> { 0x05, 0x00c0 },
> { 0x20, 0x0000 },
> { 0x20, 0x0000 },
> { 0x09, 0x0190 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x0020 }, { 0x2d, 0x0020 },
> { 0x2d, 0x0020 }, { 0x2f, 0x0020 },
> { 0x0d, 0x0008 },
> { 0x01, 0x0010 }, { 0x3, 0x0060 },
> { 0x03, 0x03ce }, { 0x5, 0x0502 },
> { 0xc8, 0x0003 },
> { 0x0a, 0x0001 },
> { 0x06, 0x0006 },
> { 0x05, 0x00c0 },
> { 0x09, 0x01b0 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x00a4 }, { 0x2d, 0x00bd },
> { 0x2d, 0x0034 }, { 0x2f, 0x00a4 },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x00d5 }, { 0x2d, 0x01c9 },
> { 0x2d, 0x00bf }, { 0x2f, 0x00d5 },
> { 0x0d, 0x0008 },
> { 0x09, 0x03f0 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x00d8 }, { 0x2d, 0x01cb },
> { 0x2d, 0x00c0 }, { 0x2f, 0x00d8 },
> { 0x0d, 0x0008 },
> { 0x09, 0x0900 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x00dc }, { 0x2d, 0x01cf },
> { 0x2d, 0x00c4 }, { 0x2f, 0x00dc },
> { 0x0d, 0x0008 },
> { 0x09, 0x0990 },
> { 0x0d, 0x8008 },
> { 0x2b, 0x00de }, { 0x2d, 0x01d1 },
> { 0x2d, 0x00c5 }, { 0x2f, 0x00de },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x2c, 0x01d0 }, { 0x2e, 0x00c6 },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x2c, 0x01cf },
> { 0x0d, 0x0008 },
> { 0x0d, 0x8008 },
> { 0x0d, 0x0008 }
>
> I have no idea why commands appeared many times with different args. Anyone
> may explain that? Some commands are similar to those existing in micron.c,
> others not. Some commands have slightly different args (or maybe I incorrectly
> parsed them).
>
> My log files and registry entries are located here:
> http://www.deeptown.org/korvin/MI1320.zip
>
>
> P.S: I still can not achieve correct color processing. Patches from Brian
> aren't working. Flipped image looks ok in color, but when we add (or remove)
> flip commands -- it gets corrupted.
>
> P.S2: When I start mplayer it displays garbage for around 3 secs, then shows
> the picture. dmesg says
>
> usb 1-1: New USB device found, idVendor=0458, idProduct=704c
> usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> usb 1-1: Product: USB20 Camera
> sn9c20x: Iso frame 0 of USB has error -18
> sn9c20x: Iso frame 1 of USB has error -18
> sn9c20x: Iso frame 2 of USB has error -18
> sn9c20x: Iso frame 3 of USB has error -18
> sn9c20x: Iso frame 4 of USB has error -18
> sn9c20x: Iso frame 5 of USB has error -18
> sn9c20x: Iso frame 6 of USB has error -18
> sn9c20x: Iso frame 7 of USB has error -18
> sn9c20x: Iso frame 8 of USB has error -18
> sn9c20x: Iso frame 9 of USB has error -18
> sn9c20x: Iso frame 0 of USB has error -18
> sn9c20x: Iso frame 1 of USB has error -18
> sn9c20x: Iso frame 2 of USB has error -18
> sn9c20x: Iso frame 3 of USB has error -18
> sn9c20x: Iso frame 4 of USB has error -18
> sn9c20x: Iso frame 5 of USB has error -18
> sn9c20x: [E] Empty buffer queue.
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Lets make microdia webcams plug'n play, (currently plug'n pray)
To post to this group, send email to [email protected]
Visit us online https://groups.google.com/group/microdia
-~----------~----~----~----~------~----~------~--~---
