What is stored in register 0 of the chip? Could that contents be 255? Try to read more registers to verify this, but if restart isn’t used then the chip will always start reading from address 0. I had the same problem with my capacitive sensor chip…
@ ianlee74 - look at page 2 of this thread. Do you remember when i suggested a few things that are incorrect in your code? I wanted to refresh my memory but those posts are incomplete…
It can be, it is related to input port 0 = GP IOPort 0 that is 0xff at POR, so may be reading it (although not set as input) may return the latch on the pin of port 0.
I confirm that some strange thing happens with sw i2c. I’ll try hw I2C and I will attach the logic/protocol analyzer to check the difference.
@ gralin - I made those changes and they had fixed the problem I was having. Not sure what happened to your posts. Looks like maybe the transition to the new site truncated them Are you seeing somewhere that I made the mistake again?
@ dobova - Thanks for checking out the hardware I2C. I’m about to head out for the day for mother’s day activities. I’ll check back this evening. We’ll have ourselves a nice paperweight if it turns out it doesn’t work with SoftwareI2C…
Restart is part if the I2C standard and some chips require the use of restart. Sending a Stop resets it’s state machine, so it forgets things that are only stored in the state machine, like the address you sent to it before the stop.
If this isn’t added then ALL I2C Gadgeteer Modules must require an “I” socket. I have already made all my I2C modules reliant on “I” sockets because I have had problems with software I2C.
If we refer back to the examples in the application notes doc, they all make extensive use of the restart command. I think it’s likely that’s the problem.
I’ve posted my source code on a temporary basis to the following CodePlex project (under Gadgeteer → IO60P16). It’s far from finished but if anyone can look at what is there and help figure out why I can’t properly read values or help prove that the problem is indeed in the SoftwareI2C class then we’ll be able to make more progress. Until we can get this problem figured out, it’s difficult to deal with more than one active pin at a time. I apologize for the mess, it’s still very much in the experimental state. This source code will be removed once the driver is complete and rolled into the GHI CodePlex area. The main function that needs help right now is IO60P16Module.ReadRegister().
@ dobova - have you had any luck with the hardware I2C? I tried briefly but so far no luck. In the code I checked in, you can set a “HARDWARE_I2C” conditional compile symbol to use what I’ve setup so far. Of course, you’ll also need re-map pin #5 → #8 and #4 → #9 to be able to use an “I” socket.
@ Ian
I completely forgot mother’s day … my wife stopped my i2c fun …
An other problem arise with sockets pin not right for hw i2c… so need two extender board for faster pin rearrangement.
I’ll post today if I’ve results. A good test could be chip eprom w/r with adiacent address … in this case, if it’s a problem of restart, it will not work.
I agree that’s where we need to end up. I’m such a noob to RLP and I2C internals that I’m avoiding it if at all possible to make this driver work If we can prove that it works fine with hardware I2C using the restarts then I’ll start fixing SoftwareI2C next.
I’m looking into protocol from sw I2C.
This is entire transaction sent to IO64 board correspondig to:
..
// Write to reg 0x0B (Port3) the byte in value, that is output byte on pins 0..7 of port 3 (I have connected 8 leds)
public void WriteRegister(byte reg, byte value)
{
byte[] data = new byte[] { reg, value };
int send = i2c.Write(DEV_ADDR, data);
}
In the attached image the start is the small orange area (start+address). I don’t understand why there is so looong time (500uS) between address and data and then between data and stop. It seems that CYP9560 is very slow to sattle data, it takes long to send ACK.
One question :
The hw I2CBus class of GTI does use (inherit) Microsoft.SPOT.Hardware.I2CBus or is a completely different implementation ? I didn’t look in the sorce code due to lack of time.
Attached is the same code running on hardware I2C, not much differences except that it’s little more reliable. With sw I2C I got 1-2 errors in 512 port writing normally on LSB. No error with hw I2C. No use of restart in this test.
What you can see, Cypress IO chip has very long time to ack the master, always around 400-500us.
Is the current I²C pin mapping an error or deliberate on this board ?
I’ve ordered it mainly because of I²C support and its (relative) simplicity, at least connection-wise, but I didn’t read carefully the pin mapping. Too bad
Please note : this is not a criticism at all, as I should have verified this point before ordering, so don’t get me wrong with my first question
There’s not an error in pin mapping. The board was designed to be an “X” socket module (using SoftwareI2C). The pin re-mapping above was done to test it using hardware based I2C on an “I” socket.
Are you seeing somewhere that I made the mistake again?
If we can prove that it works fine with hardware I2C using the restarts then I’ll start fixing SoftwareI2C next.