I2C - and first SMD experience :-(

[Marten Feldtmann]

Here is another module - this time for I2C and I had to make my first experiences with SMD - I think I've killed the chip :-(

The module is based on the PCF8584 - the DIP-version is not available any more, so I bought a SO-20 converter to DIP and I thought everything would be ok, but the SO-20 chip did not fit into this converter (Grrrr), so I had to soldier the SMD chip ... well, we will see, when I test it.

Actually all my PCB's frm China took very long and customs here in German hold the package for nearly 4 weeks before I was notified ...

Marten

[Samster]

There are still few PCF8584 DIP parts available on e-bay, although you might end up with a tube of 20 :(

Have you manged to revive your chip? I would be interested to know how you get on as I've still got a couple of "dummy" writes in my PCF8584 driver code that I can't explain the need for when compared the data sheet

[Marten Feldtmann]

Yes, actually the chip is working (Hurrray), SCL and SDA seems to emit signals,  but I have to buy some I2C devices to test it ... without ACK signals from clients not much is working ...

[Marten Feldtmann]

Well, I decided to make another revision of this board (fix stupid copy/paste errors in the schematic), I throw away the DIP socket and change the port address selection to get away from the 6-piano (inverse) style stuff back to the old jumper style selection.

[Samster]

I used a CPLD to control the reset line with a register and decode the address logic rather than jumpers/pianos. ATF1504 was probably overkill (PLCC socket) and I could probably get away with an ATF22V10 now that I've figured out (almost reliably) how to program them from a Raspberry Pi (I'm struggling with the ATF16V8C currently). The AF22V10 built-in flip-flops aren't useful here though (because they are all tied to the same external clock pin) so any registers seem to have to be made from combinatorial logic. But the full 8-bit address decode works well in a single IC.

One after thought that I had was that whilst I had a reset line to the PCF8584 I didn't extended it to the I2C peripherals. Also, I only prototyped with a 5V I2C bus and no interrupts yet which makes the diver code somewhat busy. Now that there have been some discussions on the forum about interrupt line daisy chaining I might revise my board.

My specific problem with the dummy writes is that the first full cycle through either the master-transmitter or master-recieve flows ended up with the I2C bus not being released by the  PCF8584. An undocumented dummy write to the PCF8584 register seemed to clear the issue and a new cycle could start. I suspect a timing issue as others have reported not seeing this issue (although using slightly different setups).

I used the MCP23008 port expander as a test device on my PCB.

[Marten Feldtmann]

So, this is the current state of the next version - but I have to check it. The idea is to offer plain old connectors and Qwiic connectors. It seems to be possible, that the 8584 migh handle 3.3V I2C busses. Another idea is to use newer chips, but they are even smaller (TSOP). Actually not because of the chips - but simply due to newer designs and perhaps less errros.

Marten

[Marten Feldtmann]

So the next test candidate - this time with PCA9665 I2C controller. This chip is working with 3V power - so I used my power module to give me 3V.

[Marten Feldtmann]

The good thing is - its - over all - working. The bad thing is, that the first device ( played with -  a PCF8475 from a LCD display) is not responding. Whatever I do - no ACK is sent. Then I tried a device from Grove and this one sends the ACK without problems.