New commit: sn9c20x I2C protocol

[Dave Neuer]

Hi, all

I just pushed my I2C code (replacement for the former
sn9c20x_write/read_10c0_data); I thought about sending the patch first
for comments, but then realized that my 624f code was the only one
using the old function anyway.

I'm not getting a stream even with the code aTux pushed, but anyway
I'm less concerned about that than increasing my understanding of all
of this stuff anyway. My next move will probably be putting the
OV9653-specific stuff in where it makes sense.

If anyone needs help using the new I2C functions, let me know -- the
trickiest part is likely to be figuring out what your I2C flags should
be, and that's mostly a matter of figuring out the speed of the I2C
bus and whether the bridge and sensor are connected using a 2-wire or
3-wire interface (I'm guessing most people can use the same flags as
the 624f, but what do I know).

Dave

[GWater]

Hi Dave,
I really liked the previous function (make one array and one command
executes it all).
Firstly the new function lacks this feature.
Secondly the new function uses several defines - did you check if these
work for all cams?
Thirdly the new function uses much more arguments. I see they represent
the reality but is this really worth the effort?

Nevertheless - I currently have way to much time and will try the new
function this evening. If it works I will push my updated startstream.

GWater

Dave Neuer schrieb:

[Dave Neuer]

On Sun, Mar 16, 2008 at 4:57 PM, GWater <grew...@googlemail.com> wrote:
>
> Hi Dave,
> I really liked the previous function (make one array and one command
> executes it all).
> Firstly the new function lacks this feature.

That's true, all though you could (and I'm mulling over whether to do
this) still use tables, but they'd be tables like:

{ i2c_flags, slave_id, address, 0x44, 0x...}

or even just

{ len, address, 0x44, 0x...}

and you could iterate over them like

for(i = 0; i < num_i2c_tables; i++)
ret = sn9c20x_write_i2c_data(dev, slave_id, table[i][0],
table[i][1], table[i][2]);

For now, I'm just trying to capture the semantics.

> Secondly the new function uses several defines - did you check if these
> work for all cams?

No, but they're from the sn9c102 datasheet, so they should work for
all of the cams w/ the sn9c20(1,2) bridges, I think (don't know about
the sn9c325, but it looks like it will as well).

> Thirdly the new function uses much more arguments. I see they represent
> the reality but is this really worth the effort?

I think so, since they'll allow us to abstract things like
set_video_resolution, etc.

>
> Nevertheless - I currently have way to much time and will try the new
> function this evening. If it works I will push my updated startstream.

OK, let me know if you have questions or problems.

Dave

[Comer352l]

Hi,

I will use this message to re-enter the discussion:
I didn't have the time yet to work through all the messages from the
last weeks, but there seems to be a theory about address 10c0 and I2C.
If I remember right I2C is a kind of industrial serial bus and the
theory is that it is used to connect sensor and bridge, right ?
Assuming that, I think I have some problems to understand how all these
devices (USB-Controller, Bridge, Sensor) interact.
Is address 10c0 used to talk to the sensor directly ? Up to now, I
thought we only need to talk to the SN9C201-bridge. How the bridge
handles data exchange with the sensor shouldn't be of interest for us ?
Maybe you could give me some further explanations about that. I'm only a
mechanical engineer, so please be patient... ;-)

Frank

Dave Neuer schrieb:

[JoJo jojo]

Hi Frank

but...but...I thought mechanical engineers could do anything ;-)

You have to start here
https://groups.google.com/group/microdia/web
which links to
https://groups.google.com/group/microdia/web/1-introduction-on-webcams
which links to
http://www.beyondlogic.org/imaging/camera.htm

which has a nice image with info on how I2C is connected in the
overall picture....

think of uC (i.e microcontroller) as a multiplexer of sorts (since
multiplexer is a simple switch)
based on which switches are flipped, the current("data/instructions in
binary") takes a particular path through the circuit.

so to a programmer, the IC provides a nice abstraction layer to these
electronic "switches",
based on which register you write data/instruction to the signal goes
to image sensor/ RAM/ROM/usb fifo/ etc

now, the bridge has hardwired lines to the other circuits,
(BTW: IIC or I2C stands for Inter-Integrated Circuits)
so we can flip switches on other circuits through the circuit they are
connected to,
and we know most ICs are connected to the microcontroller (hence the
name "controller").

I wish I could make this more simpler, but I just know enough to "flip
the switches".
still.. ask what you want to know further.

(Infact, if you are upto it, take the images of sn9c201 uploaded to
files section on the group,
and ask around the internet on electronic forums on identifying all
the components & better understanding of it,
don't forget to document it in the pages section what you find out)

-JoJo

[Dave Neuer]

On Sun, Mar 16, 2008 at 6:34 PM, Comer352l <come...@web.de> wrote:
>
> Hi,

>
> Assuming that, I think I have some problems to understand how all these
> devices (USB-Controller, Bridge, Sensor) interact.
> Is address 10c0 used to talk to the sensor directly ?

The commands sent to 10c0 are a relatively thin wrapper around
commands sent directly to the sensor: the bridge takes the data we
send it and uses the I2C protocol to send that data on to the sensor.
So when I write

0xa0 0x30 0x12 0x80 0x00 0x00 0x00 0x10

to address 10c0 on the bridge, I'm really telling it to write 0x80 to
address 0x12 on whatever slave device (in this case the sensor) is
referred to by the identifier 0x30 on the I2C bus. So, yes, you can
think about it as commands sent directly to the sensor (as directly as
we can without cracking the case and soldering our own wires on).

> Up to now, I
> thought we only need to talk to the SN9C201-bridge. How the bridge
> handles data exchange with the sensor shouldn't be of interest for us ?

To some extent, we could ignore everything beyond the commands sent to
the bridge if we wanted. However, there are two reasons that I can see
to care:

1) It's interesting. I am much more interested in figuring out how all
of the pieces hang together than I am in merely copying data from the
output of the Windows driver into code I write. Slapping a bunch of
data I don't understand into a file and hoping it works is only barely
more preferable to me than running a binary driver;

2) Understanding how the hardware works together will enable us to
write a more full-featured driver, able to take fuller advantage of
that hardware's capabilities.

That's my 2 cents.

Dave

[Comer352l]

Hi JoJo,

thanks for your explanation. I thought the bridge is a more
"intelligent" device but now I see I was wrong. I have to keep in mind
that all this stuff here is much more "low level" than the communication
processes I usually have to deal with...

Frank

JoJo jojo schrieb: