Thank you ianlee but it seems that I was not clear enough : since a gadgeteer socket can be X and I at the same time, why did GHI choose to not do it ? The board could then have been controlled by either implementation of I²C, software or hardware.
You see what I mean ?
I see what you mean and I mentioned this in a previous post. I think the [small] problem would have been that it would have meant *upgrading" the X to a Y since the “I” pins needed aren’t covered by an “X” socket. I would vote that if there’s ever a hardware revision that this change also be made. In fact, I would recommend that any module using I2C follow this same pattern and have drivers that provide hardware & software based I2C support (when possible).
I don’t understand where is the problem 
An “X,I” socket can have pins 3,4, 5 & 6 dedicated to X (GPIOs) and pins 8 & 9 dedicated to I²C (SDA/SCL). Pins features do not overlap, so “X,I” socket is viable.
Sorry for insisting but I really don’t understand.
[em]Edit: [/em]
this would give a socket like this (pin 1 to 10):
+3.3V +5V GPIO! GPIO GPIO GPIO [UN] SDA SCL GND
I’m sorry. My OCD is kicking in… I was trying to force SDA & SCL on the same pins for both socket types. You are right. Since SoftwareI2C allocates it’s pins dynamically, this could indeed work upon inspection of the socket type. It would be a much nicer implementation though if I2CBus & SoftwareI2C had a common interface so that only the object creation had to be different.
How would you wire it up? An X only socket on the motherboard doesn’t have pins 8 and 9 connected to anything…
Also, a hardware I2C device isn’t allowed to have the pullups on the module as they are present on the motherboard, and a software I2C device must have the pullups as there are no pullups on GPIO on the motherboard…
@ GMod : that’s why I asked if it was “an error” or not.
I don’t understand why GHI did choose software I²C, in fact… All Gadgeteer boards do have hardware I²C, as well as all FEZ boards.
Having this in mind, and in my opinion, choosing software I²C is counter-productive and does not take advantage of the Gadgeteer concept. I would even say “on the contrary”, since it’s completely forgetting the core I²C implementation !
What I may do when I will receive the board is to remove R18 and R19, thus allowing hardware I²C on pins 8 & 9. Hardest part will be to connect them to the I²C pins of the chip, though
An extender will be useful here, I think. Of course, I will loose software I²C, but, as I said just above, I don’t really care since there’s hardware I²C. Unless there are known problems with hardware I²C, of course.
Software I2C works fine, so I don’t see why to hardwire Cyp9560 i2c to I socket. It’s not particularly diffcult to add circuitry to permit switching between the two interface type (hw/sw), but the chip is not particularly fast, so software i2c is nice enough in my idea of a board like this.
I suspect it was done to allow maximum compatibility with sockets since there is usually only one or two “I” sockets and they don’t usually chain. Again, a “YI” socket would be ideal (GMod, thanks for reminding me why I suggested this in the first place).
You seem to forget one big advantage of I²C : slaves are chainable… (as it should be for every good slave, if I can permit such black humor).
So, to me, it doesn’t really matter if there’s even only one “I” socket on a mainboard 
But this would of course imply 2 sockets on an (hardware) I²C capable board, so that chain is possible.
But enough “spam” on your thread The board is like that and we have to deal with it the way it is done. And I wouldn’t like to look like someone grumpy 
@ dobova - have you had any luck reading from the module yet?
I’m going to make code and wires in few hours.I’m out now.
I’m now trying to read (sw i2c) a port value from the Cyp9065 and really I can’t get correct value. This is not a repeated start problem.
I’m sending out a byte from port 1 and reding back on port 0. It return most of the reads 0xFF (but not always …).
I’m investigating, becouse the I2C data stream and states are correct.
Addendum:
Now I’m getting back value on the pins of the port
void Io60p_Thread()
{
iO60P16.SetPortMode(3, PORT_DRIVEMODE.RES_PULLDOWN);
iO60P16.SetPortMode(0, PORT_DRIVEMODE.RES_PULLDOWN);
iO60P16.SetPortMode(1, PORT_DRIVEMODE.HIGH_Z); // important setting to get back signal on port
iO60P16.SetPortOutput(1, 0x00); // pull down all bits
iO60P16.SetPortOutput(0, 0x00); // pull down al bits
iO60P16.SetPortDirection(1, 0xff); // set port 1 all pin input
byte rd_val = 0;
while (true)
{
if (cc > 255)
cc = 0;
iO60P16.SetPortOutput(0, (byte)(cc & 0x0f));
Thread.Sleep(2); // settle data ...
rd_val = iO60P16.GetPortInput(1);
Debug.Print("Val:" + rd_val.ToString());
iO60P16.SetPortOutput(3, rd_val);
cc++;
Thread.Sleep(48);
}
}
The very easy task is:
port 0 output a 4 bit value that is then read from port 1
the value is then written to output port 3 (i’ve leds on there).
@ dobova - outstanding! Can you post your SetPortMode() code here also for me to check out tonight?
@ ian
here it is:
public enum PORT_DRIVEMODE
{
RES_PULLUP = 0x1D, //Resistive Pull Up Resistive High, Strong Low (default)
RES_PULLDOWN = 0x1E, //Resistive Pull Down Strong High, Resistive Low
OPENDRAIN_HIGH = 0x1F, //Open Drain High Slow Strong High, High Z Low
OPENDRAIN_LOW = 0x20, //Open Drain Low Slow Strong Low, High Z High
STRONG_DRIVE = 0x21, //Strong Drive Strong High, Strong Low, FastOutput Mode
SLOW_STRING_DRIVE = 0x22, //Slow Strong Drive Strong High, Strong Low,Slow Output Mode
HIGH_Z = 0x23 //High Impedance High Z
}
...
public void SetPortMode(byte port, PORT_DRIVEMODE mode_reg)
{
byte hreg = 0x18;
WriteRegister(hreg, port);
byte breg = (byte)mode_reg;
WriteRegister(breg, 0xff); // be aware : this set all the pin of the port to the same mode
}
...
The test is running since 3,5 h ago without any glitch (Hydra board) and 4.1 netmf.
I’m adding a couple of considarations. This is really good chip not very fast indeed, but datasheet is absolutely a mess. I see that "Drive mode register 1Dh-23h has some important impact on chip applications. I suggest to start in pulldown mode (1Eh) for output and high z or pulldown for input. I didn’t try PWM but I think is better to put mode 21h
Thanks, dobova! PWM is the one area that I have working. So, with this I’ll hopefully be able to finish up the OutputPort & InputPort classes. 
I must admit that is getting interesting this chip.
I’ve tried interrupts and seems to work nice on the analyzer (not yet tried in the code). Looking at PWM I noted that each port bit can be mapped to PWM, to a maximum of 16. It seems that if you connect a pin of different port to the same PWMx, the last written has the control.
I’ve seen that you can interrupt on PWM only at a frequency of 367.6 / 255 = 1,44 HZ or every ~0.7 sec. That’s really interesting for eventing program. And more the status of a PWM pin (set other than xxxx100b in Config PWM) can be polled in the relative Status Port Register although it doesn’t rise an hardware int.
@ dobova -
What application are you using in you screenshot?
It’s the sofware included in my logic analyzer from Zeroplus, a taiwanese company.
I’m very happy with this instrument.
I must admit… You’re talking way above me. I’ll try and catch up 
I’m curious - why would you want to poll a PWM signal? Please keep an eye on the functions I’m providing in this driver and let me know if you see anything I may omit that you may need.
It’s definitely time to get a logic analyzer… I’ve tried to get that kind of info out of my two-channel scope and so far I can’t do it. There’s still a lot I don’t know about the scope but the software is no where near as informative as what you are showing.