Display with i2s "backpack"

[probonopd]

It would be nice if we could use a display module with a i2s "backpack" so that we have to wire up only 4 wires for the display instead of many.

[AnotherJohnH]

Agree that would be nicer.

Have recently added I2C support to the SDK "Platform". Having quickly looked up an I2C 16x2 LCD* can see that, unsurprsingly, the internal register set looks the same as the parallel LCD devices. So the work would be...

1. Write a new version of MTL/Lcd.h ripping out the raw GPIO use and putting in an instance of MTL::I2C MTL/rp2040/I2C.h
2. Add another hardware target to the build with some conditional compilation in picoX7.cpp to select the I2C LCD driver.

Might buy one to play with when I next order some bits.

*am going to assume that an I2C AlphaNum LCD and and a parallel LCD with a "backpack" are reasonably similar devices

[AnotherJohnH]

Have completed the trivial parts here 721a3eb
Remaining work is to complete implementation of Platform/MTL/AlphaNumLcd_I2C.h

[AnotherJohnH]

Support completed. Works for me with an AiP31068L based I2C 16x2 LCD from Waveshare via the I2C1 on pins 19 and 20. Thankyou for the suggestion that's a nice improvement. See the latest release v0.18

[probonopd]

Which i2c address does your display use?

[AnotherJohnH]

See Platform/MTL/AlphaNumLcd_I2C.h. The address is passed as the only argument to the display driver constructor. But has a default value that matches the display I use which is 0x3E. This values is masked with 0x7F and written unshifted into the RP I2C peripherals IC_TAR (target address) register. So if you need a different address add { <addr } to the instantiation of the LCD driver in picoX7.cpp e.g.

static MTL::AlphaNumLcd<MTL::I2C1_P19_P20,
                        /* COLS */ 16,
                        /* ROWS */ 2> lcd { 0xHH };

I notice in the official SDK that similar devices use an address of 0x27 so that might be worth trying. Maybe the device I have, a "Waveshare LCD 1602 I2C" is unusual. To be honest I struggled to find this rather important information for the display I have, on either the PiHut or Waveshare web pages. Until eventually I saw this line in a micro python example they published ...

#Device I2C Arress
LCD_ADDRESS  = (0x7C>>1)

Which, obviously, is a rather cryptic way of writing 0x3E.

[AnotherJohnH]

... will post a patch making the I2C address clearer in picoX7.cpp

[AnotherJohnH]

... see d2f7726

[probonopd]

Thanks @AnotherJohnH. Indeed all the generic displays I have use 0x27, so I will try that.

[probonopd]

All that really happens now is that the backlight on the display (the one from the original post) gets switched off, around the time when # 001 NAME BRASS 1 ALG 22 FBK 7 SYNC on PMS 3 TRN 0 appears on the serial console:

Program  : picoX7 (WaveShare Rev2.1 I2C LCD)
Author   : Copyright (c) 2023 John D. Haughton
Version  : 0.18
Commit   : 2a2902ada41b07839b052e695fa4de73233b510b
Built    : 07:49:14 Sep 30 2024
Compiler : 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

# 001 NAME BRASS   1  ALG 22 FBK 7 SYNC on  PMS 3 TRN 0
LFO WAV sin SPD 37 DLY 00 PMD 05 AMD 00 SYNC off
OP AMS FREQ    DET R1 R2 R3 R4  L1 L2 L3 L4  BPT   CURVE    DEPTH RTE OUT KVS
6   0  R  1.00  0  49 99 28 68  98 98 91 00  39  -exp -exp  54 50  4   82  2
5   0  R  1.00  1  77 36 41 71  99 98 98 00  39  +lin +lin  00 00  0   98  2
4   0  R  1.00  0  77 36 41 71  99 98 98 00  39  +lin +lin  00 00  0   99  2
3   0  R  1.00 -2  77 76 82 71  99 98 98 00  39  +lin +lin  00 00  0   99  2
2   0  R  0.50  7  62 51 29 71  82 95 96 00  27  +lin -exp  00 07  0   86  0
1   0  R  0.50  7  72 76 99 71  99 88 96 00  39  +lin +lin  00 14  0   98  0
PITCH EG           84 95 95 60  50 50 50 50

But apart from that, I just continue to see the 16 recatangles which the display shows by default when powered on.

[AnotherJohnH]

Ugg :-( I guess that means the I2C address is working but the I2C interface in the Waveshare device I have is not the same as the "generic displays" that usually live at 0x27. Will dig into this a bit further when I get a chance. Do you know the part number of the I2C device on your display?

[probonopd]

I think they are all using various PCF8574 compatible chips. Mine says "8574T".

Perhaps https://github.com/T-622/RPI-PICO-I2C-LCD/blob/main/pico_i2c_lcd.py can give a hint on the init sequence.

[AnotherJohnH]

So seems there are (at least) two types of I2C 16x2 LCD....

1. The one you have uses a generic I2C bridge chip (the PCF8574) to drive the parallel interface to the old style HD44780 LCD display driver. I guess back-pack was the clue I missed. I2C 16x2 Arduino LCD display module
2. The device I have, which uses an all in one I2C LCD driver chip (AIP31068L). LCD 1602 I2C module

[AnotherJohnH]

Have speculated support for an I2C back-pack LCD with this patch
Completely untested and so chances of working are possibly quite low!