pmodpmon1 connection to DRR4 NEXYBoard

[OCI]

hi

i want to connect a pmodpmon1 which has male 2x4 male terminal to a pmod port of 2x6 female terminal how am i going to achieve this?

if its with the of use of cable ,what type of cable is require for a high speed signal?

how can I2C that will be 2X4 female port be achieve from a 2x6 pmod female port?

how best can multiple of  pmodpmon1 be use on a single I2C interface?

[D@n]

@OCI,

Digilent treats the I2C Pmod's different from the other PMods since they can share wires across many PMods.  As a result, you can't really "plug them in" to a standard PMod port, since you'd no longer be able to share wires among them.

As I recall, @JColvin did a good job of explaining this difference on this post.

Dan

[D@n]

@OCI,

Oooh ... here's a nice I2C blog post on the topic.  I'd be remiss if I didn't mention it.  (Thanks, @JColvin!)

Dan

[OCI]

thank you very much for your response,

now that the new spec of the pmon1 with 2x6 pin is yet to be available, then using the present version not to be plug in directly to the pmod port except by the use of cables i guess then

if its with the of use of cables ,what type of cable is require for a high speed signal?

how can I2C that will be 2X4 female port be achieve from a 2x6 pmod female port? i dont mind a diagram

how best can multiple of  pmodpmon1 be use on a single I2C interface?

 

[D@n]

@OCI,

High speed?  I'd hardly call an I2C port high speed.  They tend to only run at about 100kHz or so.  Any basic wire should do for those.  A Pmod cable should work as well, although it will limit what the port could eventually do.

How they work ... gosh, an I2C port explanation could lead to a very long explanation.  Okay, let's see what I can do ...

The difficult part about sharing wires between multiple electrical components driving the wires is avoiding a short circuit.  By "driving" a wire, I mean that a CPU connects the wire to either positive voltage or ground.  If one CPU connects a wire to positive voltage while trying to send one value, and another sets it to ground, you have a short circuit, extreme current flow, bad things happen, and ... what voltage actually shows up on the wire will be "driving" device dependent.  Uncertain results, short circuits, etc ==> bad thing.

Many busses deal with this by either only ever having single bus master (USB), or perhaps a single bus arbiter telling other "masters" when they are allowed to drive the bus (SPI, but arbitration tends not to be standard).

The I2C has a different approach to this problem.  All I2C wires are connected to power via a resistor.  Hence, when no bus drivers are "driving" the bus, the line floats to '1'.  If any device wants to drive the bus, they can connect the wire to ground.  There won't be any short circuits, since the wire is connected via resistor to power.  Since the wire is just a wire, then if one device "pulls" it to ground (i.e. connects the wire to ground), then all of the other devices examining that wire will measure it at ground.  If all of the devices let go of the wires, the result will be read as one.

This then turns into the arbitration on an I2C port.  I2C bus masters either pull wires to zero (i.e. connect them to ground), or let them float (return) back to 1 (i.e., not connect the wire internally).  If one device thinks it is mastering an I2C bus, but yet sees the bus at zero when it thinks it should be a one, then that device can recognize that another master is trying to drive the bus (i.e. a collision), back off and let the other master finish whatever it was saying.

There's a protocol that takes place on the wires as well.  The master starts, identifies the slave it wants to talk to by an ID, and the slave acknowledges anything the master writes.  (Or it doesn't ... letting the master know the slave isn't there)  If the master wants to read from the slave, once it is done identifying that it wants to read from the slave, and done identifying where it wants to read from, then the slave starts transmitting and the master acknowledges.  Further, during all of this, the master drives the clock, the slave only ever drives the data wire.  (The slave is allowed to slow the clock down, if it can't keep up.)  The point here is ... you'll need to make certain that all of the slaves you have chained together (if you have multiple things connected to this I2C port, you don't need to), all have different addresses.

All this is to say ... if you just connect all of the I2C SCL (clock) or SDA (data) lines together (clocks with clocks, data with data), they can all share the port.  If ever two things try to drive the bus at once, the two items can tell that this is happening and back off.  That will all work as long as you make sure that no two slaves share the same I2C address.  That, by the way, is why only 4 of the 6 PMod pins are used: I2C only ever uses two wires (SCL and SDA).  The other two are for power and ground.  (SPI requires 4 wires, CSn, SCK, MOSI, and MISO, hence the PMod connector requiring 6-pins)

Speed, though, becomes an issue as well.  Because the line is never driven high, when any device "lets go" of the line (i.e. stops connecting it to ground), then it make take a bit before the wire returns back to the high voltage level.  This limits the speed of an I2C interface, and keeps it relatively slow.

If any of this doesn't make sense, then you might wish to consider the Wikipedia I2C article.  They're usually pretty good at explaining things.  If you actually want to dig deeper into how this all works, the I2C specification is posted on line, and available for reference.  Indeed, you might find the resources on the I2C-bus site to be valuable as well.

Dan

[OCI]

thanks