Problem with Display: LCDI2CAddress= issue?

[MD5567]

Hi All
I am having trouble getting the display to work. At the moment it displays all black on the top line. I think that the problem lies with finding the correct address LCDI2CAddress=

I am using a raspberry PI 4B.

I am using a DF Robot LCD1602 Module v1.1.
Here is the data sheet: https://dfimg.dfrobot.com/nobody/wiki/ee1c5bd150fc6b78f8cb8e8306898ab9.pdf

And here is the code I have in the minidexed.ini file:

My code is:

HD44780 LCD

LCDEnabled=1
LCDPinEnable=17
LCDPinRegisterSelect=4
LCDPinReadWrite=0
LCDPinData4=22
LCDPinData5=23
LCDPinData6=24
LCDPinData7=25
LCDI2CAddress=0x6B

I initially tried the suggested LCDI2CAddress=0x27. That didn't work.

I then found information about the DF Robot LCD1602 Module v1.1 and found a number of different suggestions for the address and tried them all: including -- 0x60, 0x6B, 0x3E, 0x07. None of these worked.

I also found this information: "I2C address is 1 1 0 1 0 1 1 (R/W)"

But I do not know what that means or how to represent it in the format of 0x...

Thanks for your help.

[Banana71]

Good morning MD5567,

I2C address is 1 1 0 1 0 1 1 (R/W)

1+2+8+32+64=107
107 / 16= 6,xxxx
107 - 6 x 96 = 11
11 = B
6B
According to your information, "0x6B" would actually be correct.
And can you rule out the possibility of a wiring error?

[MD5567]

Thanks for the quick reply, banana71.

I used a multimeter to check the wiring.
SCL-- pin 5
SDA -- pin 3
VCC -- pin 2
GND -- pin 6

I moved VCC from pin 2 to pin 1 (which is 3v), to see if that made any difference. It just made the screen a little dimmer.

BTW: It does receive midi and output sound (a brassy sound, with just a square ADSR envelope).
I changed midi channels, but the sound remained the same.
Playing randomly with the rotary encoder made no difference to the sound.

Is it possible that the problem is that I am using a Raspberry PI 4B? Would an earlier model be better?

[soyersoyer]

But I do not know what that means or how to represent it in the format of 0x...

Open a python interpreter and write hex(0b1101011) or ask Google 0b1101011 in hex

I see an address in the documentation of your display.
AiP31068L ( LCD ) Slave Address : 0X7C.

I changed midi channels, but the sound remained the same.

The default performance listens on every MIDI channels.

The audio output of the PI 4B is very noisy. A DAC is recommended.

[diyelectromusic]

The issue with I2C addresses is that last R/W bit. Some devices list the address as a 7-bit value, ignoring the last R/W bit (which I think is the correct way to do it). Some devices list it as an 8-bit value with the last bit 0.

So, for example, the 6B address is the 7-bit version, but needs shifting right 1 bit to generate the 8-bit version so:
1101011(R/W) -> 11010110 or 0x6B becomes 0xD6.

MiniDexed uses the 7-bit version, so yes, 0x6B should work fine if 1101011(R/W) is listed as the address.

One thing I'm not clear on - in that datasheet, it lists two I2C devices: AIP31068L for the display and PCA9633DP2 for the backlight.

The AIP31068L datasheet shows this for the 2-wire interface as follows:

So that looks like the address should be 0111110(R/W) or 0x3E. But I wonder, with nothing setting the backlit driver, it might not make the contrast work properly...?

The PCA9633 has the following address options, depending on how it is wired into the DFrobot board:

But we've nothing in MiniDexed that could deal with that and the reset state is apparently:

"The Software Reset (SWRST) Call allows the controller to perform a reset of the PCA9633 through the I2C-bus, identical to the Power-On Reset (POR) that initializes the registers to their default state causing the outputs to be set HIGH (LED off). This allows an easy and quick way to reconfigure all device registers to the same condition."

Looking at this line in the DFRobot Arduino library:

DFRobot_RGBLCD1602(uint8_t RGBAddr,uint8_t lcdCols=16,uint8_t lcdRows=2,TwoWire *pWire=&Wire,uint8_t lcdAddr=LCD_ADDRESS);

It looks to me like it is using 0x6B as the "RGBAddr" which is presumably the backlight, and lcdAddr itself defaults to:

#define LCD_ADDRESS     (0x7c>>1)

which is 0x3E.

At this point, I'd run it up in RPi OS and run i2cdetect and see what it returns or wire it up to an Arduino and run the i2c_scanner sketch...

Kevin

[MD5567]

Thanks so much for going to all that trouble to help me.

At this point, I'm just going to order a different screen -- one that explicitly states "The address can be set from 0x20-0x27" and also has a contrast adjustment pot.

[Banana71]

BTW: It does receive midi and output sound (a brassy sound, with just a square ADSR envelope). I changed midi channels, but the sound remained the same. Playing randomly with the rotary encoder made no difference to the sound.

You hear the default performance. The MIDI channels are set to Omni. Without experience with the menu, it is difficult to change a performance blind.

Is it possible that the problem is that I am using a Raspberry PI 4B?

The RPi 4B is a very good choice.

Would an earlier model be better?

It will always sound the same from the RPi Zero 2 to the RPi 4. With the RPi 4 you have more options in terms of polyphony or number of TGs.
For good audio quality you should definitely get a DAC.

[diyelectromusic]

Seeing as we seem a lot more amenable to building in support for bespoke hardware these days (Arturia) then I might revisit the use of PCF devices as IO expanders and also see if there is a configurable/generic way to support displays with IO driven back-lighting. There are a few out there and it has come up before... some of them would be pretty neat "all in one" solderless solutions for MiniDexed - I'm thinking of some of the other DFRobot and Adafruit ones.

I'll have a think.

But yes, simplest for now is a I2C "backpack" style LCD with a pot for contrast :)

Kevin

[probonopd]

To address the OP's point:

How about we programmatically scan the i2c bus for addresses and just use the first one we find (if any)? I have implemented this approach here, and it seems to work well for me there:

probonopd/mock-arturia-controller@ecf7112

[diyelectromusic]

I'd be hesitant to assume that the I2C pins are always used for I2C with a display and not used for general purpose IO or something else (I still think there is great value in support I2C IO expanders for example, like I mentioned above and here: #509).

Then there is slight uncertainty about if it is a PCF-based 1602 expander display or a ssd1306 or something else... But I guess we could consider a "wildcard" address that means "I'm using an I2C display of this type - just find it please"

However, in my view, with an embedded system, it is much better for the user to specify what they have connected than attempt to assume or scan as one would with a general purpose OS/system... in a general purpose OS you're much less likely to drive an IO pin the wrong way or write a dodgy value to a hardware register and so on, and break something...

Kevin