Adding support for 256x64 ssd1362 ELW2106AA (#268)

[xcarcelle]

Hi there,

thanks a lot for your great project and support. I have been adding a basic support for the ssd1362 oled screen (Futaba ELW2106AA) but the result is not great yet.

• Hardware :
  The screen is connected to a Rpi3 with 3-wire SPI connexion (MOSI, CLK, DC, RST, CS), it is powered with 16V for the OLED power supply and 3V3 for the VCI (Logic Supply).
• Software :
  The screen reacts to "luma.example" but only displaying a white line moving slowly from top to bottom.

~/dev/luma.examples $ python3 examples/demo.py --conf conf/ssd1362.conf 
Version: luma.oled 3.3.0 (luma.core 1.12.0)
Display: ssd1362
Interface: spi
Dimensions: 256 x 64
------------------------------------------------------------
Testing basic canvas graphics...
Testing contrast (dim/bright cycles)...   <-- screen starts to react
Testing display ON/OFF...
Testing clear display...
Testing screen updates...

Below is a small video of the current rendering (I have tried with two different new screens and same results).

May you guys have an idea of this issue ? Do I need some settings ? Does is seem to similar to previous issues ?
Any hardware/software ideas is testable to possibly quickly add a full support to luma.oled

[rm-hull]

Have you got a link to the breakout board you’re using?
How did you determine the init sequence and display drawing? Is there a datasheet?

[xcarcelle]

Hi Richard,
thanks for your reply and please see some more informations below :

• ELW2106AA : https://www.mouser.fr/datasheet/2/921/Futaba-10-02-2018-ELW2106AA_A_03_SHORT-1487521.pdf
• Breakout-board used to connect this screen to the RPi3 below

• Example of init sequence from Futaba (for ARM platform I believe) : attached
  PRG0032_ELW2106AA.txt

[xcarcelle]

More technical details on the set-up

• Full datasheet of the ELW2106AA (ssd1362 based)
  ELW2106AA.pdf
• Connexions of the ELW2106AA on the breakout board to the RPi3
  1.VCC : External 16V
  2.AGND : common GND
  3.FR : Not Connected
  4.CSB : CS on the RPi3
  5.RSTB : RST on the RPi3
  6.DC : DC on the RPi3
  7.SCLK : SPI0_CLK on the RPi3
  8.SDIN: SPI0_MOSI on the RPi3
  9.GND : common GND
  10.AGND : common GND
  11.VCI : 3.3V on the RPi3
  12.VDD : Common GND
  13.VCOMH : Common GND
  14.VCC : External 16V
• I have tried also the init sequence w/ the 100ms toggling of the RST and CS signals but not more success

[xcarcelle]

@rm-hull @thijstriemstra : have you seen such kind of patterns similar to the one in the video I pushed ?

[thijstriemstra]

i haven't.

[rm-hull]

Well clearly something is happening so you must’ve wired it up correctly and initialized it. I would suggest scrutinizing the code in the display() method against how the datasheet says how to drive the screen.

Are there any capacitors on your breakout board as per the datasheet?

Also what is the content of your ssd1362.conf file?

[xcarcelle]

Thanks @rm-hull for your comment, please more technical details below :

• Wiring details from the OLED ELW2106AA screen to the RPi3 through the breakout board
  1.VCC : External 16V -- connected to common GND w/ 4.7u
  2.AGND : common GND
  3.FR : Not Connected
  4.CSB : CS on the RPi3
  5.RSTB : RST on the RPi3
  6.DC : DC on the RPi3
  7.SCLK : SPI0_CLK on the RPi3
  8.SDIN: SPI0_MOSI on the RPi3
  9.GND : common GND
  10.AGND : common GND
  11.VCI : 3.3V on the RPi3 -- connected to common GND w/ 1u
  12.VDD : Common GND -- connected to common GND w/ 1u
  13.VCOMH : Common GND -- connected w/ 4.7u
  14.VCC : External 16V -- connected to common GND w/ 4.7u

Some testing on the decoupling capacitors
VCI : w/ 1u no reaction of the screen, w/o 1u lines
VDD : 1u needed (w/o no reaction)
VCOMH : 4.7u needed (w/o no reaction)
16V : 4.7u needed (w/o no reaction)

• The contents of "ssd1362.conf"

~/dev/luma.examples $ cat conf/ssd1362.conf 
--display=ssd1362
--interface=spi
--width=256
--height=64
--spi-bus-speed=16000000

• Concerning the "display()" method, I have copied the "ssd1322(greyscale_device)" class to make the "ssd1362" class, should I use the "ssd1322_nhd()" instead of ?

[rm-hull]

Firstly I would try reducing the spi bus speed - I have seen other devices not work at higher speeds.

Directly copying another display driver is probably the root problem here. The datasheet will give some indication how to address the displays GDRAM, and you would need to sequence the correct commands and data according to what the datasheet spec says.

[xcarcelle]

• SPI bus : I have tried with 500kHz SPI_CLK speed but same result
• Driver :

1. Init sequence : the init seems correct refering to the datasheet and the init example
2. Command : the write_command() is as followed in the example from the screen maker

void OLED_WriteCmdData(int cmdCnt,int dataCnt)
{
	PBYTE ptr;
	uint8_t i;
    uint8_t data;

    cd_lo();

	ptr =  param;

    while(cmdCnt != 0)
    {     
        data = *ptr++;
        
    	for(i = 0; i< 8; i++)
    	{
    		d1_lo();				// CLK is Lo
    		if(data & 0x80) d0_hi(); else d0_lo();
    		data = data << 1;
    		d1_hi();				// CLK is Hi
    	}

        cmdCnt--;
    }


    cd_hi();

    while(dataCnt != 0)
    {
        data = *ptr++;
        
    	for(i = 0; i< 8; i++)
    	{
    		d1_lo();				// CLK is Lo
    		if(data & 0x80) d0_hi(); else d0_lo();
    		data = data << 1;
    		d1_hi();				// CLK is Hi
    	} 
        dataCnt--;
    }       
    
}

<-- Could I follow this write_command() specifications using luma.oled device code ?
Is there a similar approach for another screen chipset ? Much thanks for your support.

[xcarcelle]

@rm-hull : sorry a display strategy question : while working on the ssd1362 we are prototyping with another screen ssd1322 (well supported by luma.oled), we would to modify some sections of the display while the other remain the same, what should be the best strategy ? Could I follow such an example ? Thanks

[xcarcelle]

• I have been modifying the ssd1351 sample code from here [1] as suggested in Problem with SSD1351 . Nothing shown on display #205 with the datasheet initialization sequence of the ssd1362 datasheet and leaving the WriteCmd and WriteData as-is. The screen "reacts" to "draw.line()" but does not do much more.
  Below the display with "draw_line()"
  
• The board on the picture is a custom PCB to breakout SPI, VCC(3V3), GND, RST, CS, DC from the ELW2106AA screen to the RPi3
• Do you guys think that I could try modifying "fbtft" to use the ssd1362 with fb ? I do think it should so different from adding to luma.oled or to other existing code out-there.

Much thanks for any hints or tests. @rm-hull : would you be interested by a ELW2106AA device for test ?

[1] : https://www.waveshare.com/wiki/File:1.5inch_RGB_OLED_Module_Code.7z

[xcarcelle]

Some updates : below is a picture of another test yesterday where the screen starts to be able to display patterns

• Hardware set-up : RPi3 (default RST/CS/DC wiring, SPI0.1), break-out board, ELW2106AA (ssd1362)
• Software set-up : attached is the mod from the waveshare ssd1351 python basecode
  

test_ssd1351_hack_for_ssd1362.zip

At this point, I would to integrate this "working" init sequence into "luma.oled" to work into the "luma" project. Any hints is welcome at this point of the road.

[rm-hull]

Closing - I have merged from this fork, but I don't have direct access to make further changes, so will proceed on a branch - track progress in PR #271