Hi !
In fact I have good news for everyone who wants to communicates (Read/Write) with those chips and an Arduino as master (or any other kind of I2C master, like RPi or VGA card) : I think it is completely possible ! (Just take care about 3.3v). But I didn't tried.
I Guess you should also tells you Arduino that the address you want to write is 0x78 (0b111 1000) + W and then the first data byte you send should be 0x01, 0x02, 0x03, 0x04 or 0x05.
Before any read, you will also need to write 0x78 + W, 0x0N (1 2 3 or 5), your desired register(s), and Restart, then just 0x78 + R (on a read, you're only able to write 1 byte of address before receiving, so you can't put the full 10 bit address. But the slave chip will recognize himself since just before the restart, you were talking to it).
What we don't succeeded in, with the Arduino, was to watch as input only into the operating bus between printer and cartridges and being able to catch everything sent/received between everybody without any interaction and without any bit of error : coding a software read-everything using software poll and/or interrupt on PD0 / PD1 changes was to slow to :
- copy of the SDA/SCL value (PORTD) immediately on any change
- interpret the copy by looking at the 2 values with some if/else and masks (0x02, 0x01, 0x03)
- putting the results into a dedicated buffer
- and to be ready for the next change at time
Of course, sending the values by Serial Port should be done in a second time because it's very long too (talking about too many µs of course, not minutes
).
We were loosing a lot of bits, starts and stops. Copying the SDA/SCL values on another output port and seeing the time offset with a 2-way oscilloscope revealed that we had no chance to be fast enough to do everything in time because SDA was changing too fast after an SCL change and vice-versa (we were often reading the PORT D too late).
May be some Assembly's kings would have done better than us, but anyway, that's why we said it was pretty impossible without a faster controller (and I discovered 70MIPS dsPIC, it solved the problem, but it's a little bit complicated to code with : lot of registers to set everywhere to do any simple thing).
I've tried to interpret the data on the big headers as ASCII. That's a little bit poor because it's mainly binary, but there is some ASCII information anyway. It seems that those are serial number, and the model of the compatible printer.
There is also a check on the Imaging Drum reference : CAH171303CD6 is written into the Imaging drum's chip but also in the cartridge's chips.
Pretty interesting, after all ! May be it's for a compatibility check with what's installed into the printer.
Black :
CAH171331C86
38C4237
6MBF4
CAH171303CD6
75272394
Lexmark CX417de
Blue :
CAH1713218DA
38C4234
6MBF46MBF4
CAH171303CD6
75272394
Lexmark CX417de
Magenta :
CAH171350F7B
38C4235
6MBF46MBF46MBF4
CAH171303CD6
75272394
Lexmark CX417de
Yellow :
CAH1713208AA
38C4236
6MBF4
CAH171303CD6
75272394
Lexmark CX417de
Imaging Drum :
CAH171303CD6
38CB0001