Problem getting i2c bus to work with SSD1803a based LCD

I am trying to get my BBB to talk to an SSD1803a based LCD
(specifically a Midas MCCOG42005A6W) and I'm failing miserably at the
moment. :frowning:

I bought the MCCOG42005A6W because it's 3.3 volt and I2C bus so
thought it would be simple.

I'm fairly certain I have the connections correct etc. but I can't get
the i2cdetect command to 'see' the MCCOG42005A6W. Presumably until it
can see the device I'm not going to get any further.

However I'm not absolutely sure that the MCCOG42005A6W works in a way
that i2cdetect will understand, I'll try and explain.

The MCCOG42005A6W only brings out the I2C interface from the
underlying SSD1803a, each 'command' to the SSD1803a comprises a
control byte (of which only two bits are significant) and an 8-bit
command (which is a superset of the HD4478OU command set). Thus the
SSD1803a (and in turn the MCCOG42005A6W) *always* needs 16-bits to be
sent to it before it will respond with anything useful. Hence any
detection program that tries sending an I2C address followed by an
8-bit 'command' will not get any sort of response, will this confuse
i2cdetect?

I do have a 'scope but not a logic analyser, I can't detect anything
useful happening on the clock or data lines with the 'scope but that
may simply be because it happens for too short a period for me to see
anything.

Can anyone suggest how I can progress this?

I am trying to get my BBB to talk to an SSD1803a based LCD
(specifically a Midas MCCOG42005A6W) and I'm failing miserably at the
moment. :frowning:

I bought the MCCOG42005A6W because it's 3.3 volt and I2C bus so
thought it would be simple.

I'm fairly certain I have the connections correct etc. but I can't get
the i2cdetect command to 'see' the MCCOG42005A6W. Presumably until it
can see the device I'm not going to get any further.

However I'm not absolutely sure that the MCCOG42005A6W works in a way
that i2cdetect will understand, I'll try and explain.

The MCCOG42005A6W only brings out the I2C interface from the
underlying SSD1803a, each 'command' to the SSD1803a comprises a
control byte (of which only two bits are significant) and an 8-bit
command (which is a superset of the HD4478OU command set). Thus the
SSD1803a (and in turn the MCCOG42005A6W) *always* needs 16-bits to be
sent to it before it will respond with anything useful. Hence any
detection program that tries sending an I2C address followed by an
8-bit 'command' will not get any sort of response, will this confuse
i2cdetect?

I do have a 'scope but not a logic analyser, I can't detect anything
useful happening on the clock or data lines with the 'scope but that
may simply be because it happens for too short a period for me to see
anything.

Can anyone suggest how I can progress this?

First you should read up on how i2c works. What you are looking for is a
ACK or a NACK which occurs at the end of each byte transmitted. The slave
keeps SDA pulled low to slow down the communications, but after that, it
should go high on the next clock to indicate an ACK. I believe that
i2cdetect is looking for a ACK to confirm that a device exists. The first
byte should be the address and if you don¹t have the correct address, you
won¹t see an ACK.

Regards,
John

cl@isbd.net wrote:

I am trying to get my BBB to talk to an SSD1803a based LCD
(specifically a Midas MCCOG42005A6W) and I'm failing miserably at the
moment. :frowning:

[snip]

The problem turned out to be my misunderstanding of the reset line on
the SSD1803a. On the example circuits it just shows it as /RES with
no connection at all, so I assumed it had a pull-up resistor and just
needed a momentary 0v to reset. No, it needs a pull-up resistor.

I can now 'see' the SSD1803a using i2cdetect so I think I'm on my way.