ESP32-2432S028 - 2.8" LCD ILI9341 XPT2046 Resistive Touch screen - rotation / x y mirror swap / colors / ... issues

[espruino-discuss3]

Posted at 2025-01-26 by @allObjects

Trying to update the https://espruino.com/ui, I noticed this integrated device - no wiring needed on my part - and was also told that there is an Espruino build out there that could work... sorts of, for me...

Flashing did go well, but on restart, the display initialization is either missing or off... and so are the colors g.setColor(r,g,b). Touch though -built-in too - works perfect ( E.on("touch",(t)=>console.log(t.x, t.y, (t.b) ? "touched" : "untouched")); ).

Right after flashing and reset by esptool.py without power cycle, the Espruino uninitialized area shows content from before, horizontally mirrored - see attached shot showing Shop, FPS - frames/s - and CPU % horizontally mirrored. After power cycle, same display initialization and random noise in at the uninitialized area. Playing around with .setRotation(...) - and drawing a filled rectangle for visualization - did not yield results - see 2nd attachment. Originally loaded demo is landscape.

Since this is the first time venturing into ESP32 and more so an integrated one, I need some shoehorning about pins, SPIs - to do a setup and initialized ILI9341 correctly. The device seems to be a newer version, because it has next to micro USB also a USB-C.

Since touch is integrated it delivers a lot of events, and because even staying at a point with the pen, a constant barrage goes on and is detrimental to the use w/ javascript. So I came up with a touch tamer - like a tiller tamer in sailing - about which I will have another conversation.

---

Attachments:

• flashResetNoPowerCycle.jpg
  
• flashResetRots.jpg
  
• backLabeled.png

[espruino-discuss3]

Posted at 2025-01-27 by @MaBecker

Same same but different....

When starting with LCD_SPI_UNBUF LCD Library Gordon recommend not to include the display initialisation into firmware because things like this can happen easily. To be honest, I am very happy that you Gordon implemented the ESP32_CYD board, because it is a perfect example howto integrated a display with touch into firmware.

---

Posted at 2025-01-27 by @MaBecker

@allObjects I guess there are two settings that need to be adapted

1. Display Inversion Control (B4h)
2. MemoryAccessControl (36h)

---

Posted at 2025-01-27 by @MaBecker

some quick hack for additional lcd functions for ESP32_CYD

lcd_cmd = function (c, d) {
    D2.reset();
    SPI1.write(c, D15);
      if (d !== undefined) {
          D2.set();
          SPI1.write(d, D15);
      }
};

// check datasheet for valid values
g.lcd_rotate = function (v) {
      lcd_cmd(0x36, v);
};

g.lcd_inv = function (s) {
     if (s) {
          D2.reset();
          SPI1.write(0x21, D15);
     } else {
         D2.reset();
         SPI1.write(0x20, D15);
     }
};

g.lcd_backLight = function (s) {
     if (s) {
         D21.set();
     } else { 
         D21.reset(); 
     }
};

https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

Chapter 8. Command

and

Chapter 9.3. MCU to memory write/read direction

---

Posted at 2025-01-27 by @gfwilliams

Hopefully @MaBecker's code will work?

So you're running with the ESP32_CYD build @allObjects? It's really strange - I've tried on both the micro usb and USB-C variants and it works great for me. I wonder if maybe the display library should just be waiting a bit longer after power on before it initialised the display in your case?

---

Posted at 2025-01-27 by @allObjects

@gfwilliams, 2V25.40... good point, that the display setup could kick in too early... so far I have no application code that is drawing immediately... What you see is what is flashed... only the rectangle is custom drawn with a delay of 1000ms and 250ms (both delays show same result).

Did not rerun the init with different values yet - as @MaBecker's suggested.

---

Posted at 2025-01-27 by @MaBecker

lcd init sequence from firmware

https://github.com/espruino/Espruino/blob/672e95948d9e1a74f739d6b1cda1c12cdab78aaa/libs/graphics/lcd_spilcd_info.h#L22-L49

static const unsigned char SPILCD_INIT_CODE[] = {
   // CMD,DELAY,DATA_LEN,D0,D1,D2...
  0xCF/*ILI_PCB*/, 0, 3, 0x00, 0xC1, 0X30,
  0xED/*ILI_POSC*/, 0, 4, 0x64, 0x03, 0X12, 0X81,
  0xE8/*ILI_DTCA_ic*/, 0, 3, 0x85, 0x10, 0x7A,
  0xCB/*ILI_PCA*/, 0, 5, 0x39, 0x2C, 0x00, 0x34, 0x02,
  0xF7/*ILI_PRC*/,0, 1, 0x20,
  0xEA/*ILI_DTCB*/, 0, 2, 0x00, 0x00,
  0xC0/*ILI_PWCTRL1*/, 0, 1, 0x1B,
  0xC1/*ILI_PWCTRL2*/,0, 1, 0x01,
  0xC5/*ILI_VMCTRL1*/, 0, 2, 0x30, 0x30,
  0xC7/*ILI_VMCTRL2*/, 0, 1, 0XB7,
  0x36/*ILI_MADCTL*/, 0, 1, 0x48,
  0x3A/*ILI_PIXSET*/, 0, 1, 0x55,
  0xB1/*ILI_FRMCTR1*/, 0, 2, 0x00, 0x1A,
  0xB6/*ILI_DISCTRL*/, 0, 2, 0x0A, 0xA2,
  0xF2/*ILI_E3G*/, 0, 1, 0x00,
  0x26/*ILI_GAMSET*/, 0, 1, 0x01,
  0xE0/*ILI_PGAMCTRL*/, 0, 15, 0x0F, 0x2A, 0x28, 0x08, 0x0E, 0x08, 0x54, 0XA9, 0x43, 0x0A, 0x0F, 0x00, 0x00, 0x00, 0x00,
  0xE1/*ILI_NGAMCTRL*/, 0, 15, 0x00, 0x15, 0x17, 0x07, 0x11, 0x06, 0x2B, 0x56, 0x3C, 0x05, 0x10, 0x0F, 0x3F, 0x3F, 0x0F,
  0x2B/*ILI_PASET*/, 0, 4, 0x00, 0x00, 0x01, 0x3f,
  0x2A/*ILI_CASET*/, 0, 4, 0x00, 0x00, 0x00, 0xef,
  0x11/*ILI_SLPOUT*/, 120, 0,
  0x29/*ILI_DISPON*/, 0, 0,
  0x36/*ILI_MADCTL*/, 0, 1, 0x68,
  // End
  0, 0, 255/*DATA_LEN = 255 => END*/
};

0x20/* ILI_INVERS_OFF */ is missing

Power on and this is what you get

---

Attachments:

• IMG_4389.jpg

---

Posted at 2025-01-27 by @allObjects

Just applied the definitions from espruino.com/modules with delay after power cycle reset of the hardware, ESP32 'os', Espruino 2v25.40 init:

// cydIliInitTest.js

// derived from ILI9341 module at espruino.com/modules/ILI4391.js

// exports.connect = function(spi, dc, ce, rst, callback) {

// ESP32 CYD specifics:
var spi = SPI1
  , dc  = D2 
  , ce  = D15
  , rst
  , callback
  ;

function writeCMD(d){
    ce.write(0);
    spi.write(d,dc);
}
function writeCD(c,d){
    ce.write(0);
    spi.write(c,dc);
    spi.send(d);
    ce.write(1);
}

 // not (yet) used in this exploration / test code
function lcdCB() {
  var LCD = Graphics.createCallback(LCD_WIDTH, LCD_HEIGHT, 16, {
    setPixel:function(x,y,c){
      ce.reset();
      spi.write(0x2A,dc);
      spi.write(x>>8,x,(x+1)>>8,x+1);
      spi.write(0x2B,dc);
      spi.write(y>>8,y,(y+1)>>8,y+1);
      spi.write(0x2C,dc);
      spi.write(c>>8,c);
      ce.set();
    },
    fillRect:function(x1,y1,x2,y2,c){
      ce.reset();
      spi.write(0x2A,dc);
      spi.write(x1>>8,x1,x2>>8,x2);
      spi.write(0x2B,dc);
      spi.write(y1>>8,y1,y2>>8,y2);
      spi.write(0x2C,dc);
      spi.write({data:String.fromCharCode(c>>8,c), count:(x2-x1+1)*(y2-y1+1)});
      ce.set();
    }
  });
  return LCD;
}

function lcdInit() {
  ce.write(1);
  dc.write(1);
  if (rst) rst.write(0);
  setTimeout(function(){
    if (rst) rst.write(1);
    setTimeout(function(){
      writeCMD(0x01);
      setTimeout(function(){
        writeCMD(0x28);ce.write(1);
        writeCD(0xCF,[0x00,0x83,0x30]);
        writeCD(0xED,[0x64,0x03,0x12,0x81]);
        writeCD(0xE8,[0x85,0x01,0x79]);
        writeCD(0xCB,[0x39,0x2C,0x00,0x34,0x02]);
        writeCD(0xF7,0x20);
        writeCD(0xEA,[0x00,0x00]);
        writeCD(0xC0,0x26);
        writeCD(0xC1,0x11);
        writeCD(0xC5,[0x35,0x3E]);
        writeCD(0xC7,0xBE);
        writeCD(0x36,0x48);
        writeCD(0x3A,0x55);
        writeCD(0xB1,[0x00,0x1B]);
        writeCD(0xF2,0x08);
        writeCD(0x26,0x01);
        writeCD(0xE0,[0x1F,0x1A,0x18,0x0A,0x0F,0x06,0x45,0x87,0x32,0x0A,0x07,0x02,0x07,0x05,0x00]);
        writeCD(0xE1,[0x00,0x25,0x27,0x05,0x10,0x09,0x3A,0x78,0x4D,0x05,0x18,0x0D,0x38,0x3A,0x1F]);
        writeCD(0xB7,0x07);
        writeCD(0xB6,[0x0A,0x82,0x27,0x00]);
        writeCMD(0x11);ce.write(1);
        setTimeout(function(){
          writeCMD(0x29);ce.write(1);
          setTimeout(function(){
            if (callback!==undefined) callback();
          },100);
        },100);
      },5);
    },5);
  },1);
}

// /---- module like code

function onInit() {
  lcdInit();
}

setTimeout(onInit,999);

and attached is what I get: Note the text is reversed (screen colors too... but not relevant).

---

Attachments:

• initFromModule.jpeg

---

Posted at 2025-01-28 by @MaBecker

@gfwilliams Is there a way to Read Display MADCTL (0Bh) value?

---

Posted at 2025-01-28 by @allObjects

Did some more work. Took espruino.com/module in pieces as app into IDE, supplied SPI and port info, ran the initialization, rotated and displayed rectangles, text and touch coordinates - with the results shown in attached picture and .mp4 clip. g.rotation(2,1) - rotation and x/y swap do the trick. As a note for the future: since rotate does not synchronize w/ touch, there will be a module that has to bind both together and also include a touch enhancer (rate tameer without precision loss).

I can conclude a workable version. Colors still need a look and touch raw values as well as processing rage needs adjustment. The upper line of coordinates shows the expected coordinates for the left top corner of the bottom large right rectangle. Touching there shows an average error of 7+. Touching in the 0/0 - top left - and 320/240 - bottom right - corner shows significant errors too that need adjustment in a module... and a damper/tamer on the event ratio...

In the next post I will show the code and the differences in initialization of flashed Espruino 2v25.40 version vs. module's verison.

---

Attachments:

• cydLandscape.jpg
• cydLSwTouch.mp4

---

Posted at 2025-01-28 by @allObjects

The code I used to play around with a better initialization and the touch information:

// cydIliInitTest.js
// 20250127_ao
//
// init a 2nd time in app/user code after firmware init
// and figure proper display and touch w/ rotation, etc.

// initialisation derived from ILI9143 module @
// espruino.com/modules/ILI4391.js

// exports.connect = function(spi, dc, ce, rst, callback) {
// ESP32 CYD

var spi = SPI1 // CYD specific...
  , dc  = D2   // ...used in 2nd/re-init 
  , ce  = D15
  , rst
  , callback
  ;

function writeCMD(d) { // used by lcdInit() below
    ce.write(0);
    spi.write(d,dc);
}
function writeCD(c,d) { // used by lcdInit() below
    ce.write(0);
    spi.write(c,dc);
    spi.send(d);
    ce.write(1);
}

function lcdCB() { // ...not used here
  var LCD = Graphics.createCallback(LCD_WIDTH, LCD_HEIGHT, 16, {
    setPixel:function(x,y,c){
      ce.reset();
      spi.write(0x2A,dc);
      spi.write(x>>8,x,(x+1)>>8,x+1);
      spi.write(0x2B,dc);
      spi.write(y>>8,y,(y+1)>>8,y+1);
      spi.write(0x2C,dc);
      spi.write(c>>8,c);
      ce.set();
    },
    fillRect:function(x1,y1,x2,y2,c){
      ce.reset();
      spi.write(0x2A,dc);
      spi.write(x1>>8,x1,x2>>8,x2);
      spi.write(0x2B,dc);
      spi.write(y1>>8,y1,y2>>8,y2);
      spi.write(0x2C,dc);
      spi.write({data:String.fromCharCode(c>>8,c), count:(x2-x1+1)*(y2-y1+1)});
      ce.set();
    }
  });
  return LCD;
}

function lcdInit() {
  ce.write(1);
  dc.write(1);
  if (rst) rst.write(0);
  setTimeout(function(){
    if (rst) rst.write(1);
    setTimeout(function(){
      writeCMD(0x01);
      setTimeout(function(){
        writeCMD(0x28);ce.write(1);
        writeCD(0xCF,[0x00,0x83,0x30]);
        writeCD(0xED,[0x64,0x03,0x12,0x81]);
        writeCD(0xE8,[0x85,0x01,0x79]);
        writeCD(0xCB,[0x39,0x2C,0x00,0x34,0x02]);
        writeCD(0xF7,0x20);
        writeCD(0xEA,[0x00,0x00]);
        writeCD(0xC0,0x26);
        writeCD(0xC1,0x11);
        writeCD(0xC5,[0x35,0x3E]);
        writeCD(0xC7,0xBE);
        writeCD(0x36,0x48);
        writeCD(0x3A,0x55);
        writeCD(0xB1,[0x00,0x1B]);
        writeCD(0xF2,0x08);
        writeCD(0x26,0x01);
        writeCD(0xE0,[0x1F,0x1A,0x18,0x0A,0x0F,0x06,0x45,0x87,0x32,0x0A,0x07,0x02,0x07,0x05,0x00]);
        writeCD(0xE1,[0x00,0x25,0x27,0x05,0x10,0x09,0x3A,0x78,0x4D,0x05,0x18,0x0D,0x38,0x3A,0x1F]);
        writeCD(0xB7,0x07);
        writeCD(0xB6,[0x0A,0x82,0x27,0x00]);
        writeCMD(0x11);ce.write(1);
        setTimeout(function(){
          writeCMD(0x29);ce.write(1);
          setTimeout(function(){
            if (callback!==undefined) callback();
          },100);
        },100);
      },5);
    },5);
  },1);
}

// /---- end module like code

function onInit() {
  lcdInit();
  setTimeout(function(){  // safely after lcdInit()
    g.setRotation(2,1);
    g.clear();
    // 1st rectangle in top left quadrant
    g.setColor(1,0,0); g.fillRect(     10,      30,      70,     115);
    g.setColor(0,1,0); g.fillRect(     20,      50,      30,      60);
    g.setColor(1,1,0); g.fillRect(     45,      90,      60,     105);
    // 2nd rectangle in bot rght quadrant
    g.setColor(1,1,0); g.fillRect(160+ 10, 120+ 30, 160+ 70, 120+115);
    g.setColor(1,0,0); g.fillRect(160+ 20, 120+ 50, 160+ 30, 120+ 60);
    g.setColor(0,1,0); g.fillRect(160+ 45, 120+ 90, 160+ 60, 120+105);
    // Text
    g.setColor(1,1,0).setFontVector(20).drawString("Espruino",80,50);
    // touch coords
    E.on("touch",function(t){     // display
      if (t.b) g.setColor(1,1,0); // on touch    w/ frame
      else     g.setColor(0,0,0); // on untouch w/o frame
                      g.drawRect(  90,160,165,180);
      g.setColor(0,0,0).fillRect(  91,159,164,179);
      g.setColor(1,1,0).setFontVector(14);
      g.drawString(""+t.x+"/"+t.y, 97,164); // touch coords;
    });                                     // 2nd rectangle
      g.setColor(1,1,0).setFontVector(14);  // expected 
      g.drawString(""+170+"/"+150, 97,144); // touch coords
  }, 999); // safely after lcdInit()
}

setTimeout(onInit,999);

Since the colors do not look right yet, I'm comparing the initialization values from both module and source of flashed version. There are definitively differences between the values and the sequence, and also definitively also between the underlaying hw/sw, because my device initializes portrait w/ upside down - ESP32module on the bottom - and incorrectly vs other people's device that initialize landscape w/ ESP32 module on the left.

I'm curious what the cause might be... also that the colors are still not right. Because of (almost always wrapping in forum format), I also attache the comparison as text file.

For best UX viewing experience, you may need to find the sweet spot of browser window width so that not even the longest lines wrap... (may though still do depending on font size settings for accessibility in your browser); narrower window / smaller witdth is - counter-intuitively - better, because the two column post layout css break delivers widest text / code / image attachment box; 3rd column content becomes right-slide-in, accessible w/ forum menu [...] button) :\

`
// ILI9341 controller initialization comparison

//  Espruino module                    // ESP32 CYD .h
//  ----------------------------------   --------------------------------                                
//v^moved in init module

//       |cmd  |data                     |cmd    |data              |deltas
//       |     |                         |       |                  |
                                                     
    wCMD(0x28); ce.write(1);          //                         // ? in ESP32 CYD ?

    wCD (0xCF, [0x00,0x83,0x30]);     // PCB    ,0x00,0xC1,0X30, //     2nd   
    wCD (0xED, [0x64,0x03,0x12,0x81]);// POSC   ,0x64,0x03,0X12,0X81,//
    wCD (0xE8, [0x85,0x01,0x79]);     // DTCA_ic,0x85,0x10,0x7A, //     2nd 3rd
    wCD (0xCB, [0x39,0x2C,0x00,0x34,0x02]);// PCA    ,0x39,0x2C,0x00,0x34,0x02,//
    wCD (0xF7, 0x20);                 // PRC    ,0x20,           //

    wCD (0xEA, [0x00,0x00]);          // DTCB   ,0x00,0x00,      //
    wCD (0xC0, 0x26);                 // PWCTRL1,0x1B,           //
    wCD (0xC1, 0x11);                 // PWCTRL2,0x01,           //
    wCD (0xC5, [0x35,0x3E]);          // VMCTRL1,0x30,0x30,      // 1st 2nd
    wCD (0xC7, 0xBE);                 // VMCTRL2,0xB7,           //

    wCD (0x36, 0x48);                 // MADCTL ,0x48,           // ^ to here
    wCD (0x3A, 0x55);                 // PIXSET ,0x55,           //
    wCD (0xB1, [0x00,0x1B]);          // FRMCTR1,0x00,0x1A,      //     2nd
//v wCD (0xB6, [0x0A,0x82,0x27,0x00]);// DISCTRL,0x0A,0xA2,      // -v from here
    wCD (0xF2, 0x08);                 // E3G    ,0x00,           //
    wCD (0x26, 0x01);                 // GAMSET ,0x01,           //

                                      // PGAMCTRL,               // __ <-- deltas
wCD (0xE0, [0x1F,0x1A,0x18,0x0A,0x0F,0x06,0x45,0x87,0x32,0x0A,0x07,0x02,0x07,0x05,0x00]);
         // 0x0F,0x2A,0x28,0x08,0x0E,0x08,0x54,0XA9,0x43,0x0A,0x0F,0x00,0x00,0x00,0x00,
         //   --   --   --   --   --   --   --   --   --   --   --   --   --   --

                                      // NGAMCTRL,               // __ <-- deltas
wCD (0xE1, [0x00,0x25,0x27,0x05,0x10,0x09,0x3A,0x78,0x4D,0x05,0x18,0x0D,0x38,0x3A,0x1F]);
         // 0x00,0x15,0x17,0x07,0x11,0x06,0x2B,0x56,0x3C,0x05,0x10,0x0F,0x3F,0x3F,0x0F,
         //        --   --   --   --   --   --   --   --        --   --   --   --   --

      // 0x29                         // DISPON,                 // ? in Espruino module?
//^ wCD (0x36,0x48);                  // MADCTL ,0x48,           // -^ from here
    wCD (0xB7,0x07);                  //                         // ? in ESP32 CYD ?
    wCD (0xB6,[0x0A,0x82,0x27,0x00]); // DISCTRL,0x0A,0xA2,      // v to here, 2nd
                                                                 //     2nd and more data
    wCMD(0x11); ce.write(1);          //                         // ? in ESP32 CYD ?
        
 eod_20250128_ao
`

---

Attachments:

• cydInitCompare.txt

---

Posted at 2025-01-28 by @allObjects

As @MaBecker pointed out to me, command 0x36 controls direction of how memory is used - line #77 resp #43 - MADCTL - MemoruADdressConTroL. With below values no rotation is needed in application code anymore (line #103 in post #11) and colors are in R,G,B sequence accepted (rather than B,G,R) :

        writeCD(0x36,0x60); // portrait  RGB
        writeCD(0x36,0x00); // landscape RGB

---

Attachments:

• cydLS.jpg

---

Posted at 2025-01-28 by @gfwilliams

I think the display can be read, yes - miso seems to be connected.

In the spilcd code we have this hard-coded init code as you noted @MaBecker: https://github.com/espruino/Espruino/blob/672e95948d9e1a74f739d6b1cda1c12cdab78aaa/libs/graphics/lcd_spilcd_info.h#L22-L49

But in LCD_FSMC (the code used for the older STM32-based 320x240 LCD dev boards) we have some code that actually reads back the LCD model number and then applies the correct initialisation code based on that: https://github.com/espruino/Espruino/blob/672e95948d9e1a74f739d6b1cda1c12cdab78aaa/libs/graphics/lcd_fsmc.c#L679

I guess it might be we need to do something similar here - it'd be very interesting if you could read back the device code: https://github.com/espruino/Espruino/blob/672e95948d9e1a74f739d6b1cda1c12cdab78aaa/libs/graphics/lcd_fsmc.c#L662-L677

---

Posted at 2025-01-28 by @allObjects

@gfwilliams,

interesting, and thank you for providing this insight.

I'll give that a shot later today. There is anyway a layer needed that handles the raw touch data and synchronizes rotation of display and touch, and this code an include an optional function to take care of eventual differences.

I also noticed differences in the GAMSET / PGAMCTRL / NGAMCTRL that are gmma / color corrections, not impacting general functionality, but calibration of color, color tones... which for the newer of my LCDs are so much more blue-ish (it is of course also a different phone / camera with which I took the pics then and now).

---

Posted at 2025-01-29 by @gfwilliams

There is anyway a layer needed that handles the raw touch data

It should provide an E.on("touch", ...) event? But yes it doesn't handle rotation - it assumes the device is in landscape.

---

Posted at 2025-01-29 by @allObjects

Yes, it does deliver nicely the touch (and untouch events) with x and y in both touch and untouch event. - The XPT2046 standalone module delivered only x and y with defined values for a touch and x and y with undefined values for an untouch (and no boolean/0|1 for touch/untouch status. Touch status has to be derived from value presence of x and/or y.)

Since all is integrated, it is pretty fast and the event rate is pretty high on touch, even with no movement: the jitter by +-1...few pixels has to be filtered out / tamed, so that events with relevant moves show thru (its a bit more elaborate than just looking for a move of a number of pixel). I have built something and will show in a bit.

This piece of code can become an umbrella module for both display and touch screen to provide rotational synchronization and touch calibration. Rotation calls would go thru that module to the Graphics object as well as to an (included) wrapper for the touch event. The wrapper takes takes care of touch coordinates for rotated displays an delivers the proper x and y with a tamed rate without loosing precision (small or slow movement / drag).