Display lambda issues (st7789v)

[carlosV2]

The problem

I'm unable to get anything meaningful rendered in my st7789v 2inch waveshare display.

I've wired the pico and the screen as shown in this page. Sure enough, when I run the code in that page it works without a problem (discarding this is a wiring issue).

When I try with ESPHome, however, I get nothing rendered at all. I thought it could be a problem with a mismatching driver version so I started to code my own component based on the st7789v platform. I quickly realised the coding in ESPHome should be fine as it follows the screen's specification.

I then attempted to get anything rendered so during the screen setup, I added the following line:

this->draw_filled_rect_(0, 0, 100, 100, 0x00FF);

This does indeed render a blue square in the screen (discarding this is a GPIO or SPI issue).

Since it has been ignoring anything inside the lambda, my last attempt has been to add the following line at the end of the draw_absolute_pixel_internal function:

this->write_display_data();

This makes the screen to render a Christmas tree of colours (like a colourful version of the old static signal in the old analog TVs).

From this, I can only conclude that either the internal buffer is not being filled correctly, the lambda is not working at all, or a combination of the both of them.

Which version of ESPHome has the issue?

2023.11.2

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

n/a

What platform are you using?

RP2040

Board

Waveshare 2inch LCD Display Module IPS Screen 240×320 Resolution Onboard driver ST7789v

Component causing the issue

st7789v

Example YAML snippet

esphome:
  name: tester
  friendly_name: Tester

rp2040:
  board: rpipico
  framework:
    # Required until https://github.com/platformio/platform-raspberrypi/pull/36 is merged
    platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "Sp5tdR/+bHwQ8jVskqv+mW+Z1JyMxRqyqDEqSn9Rn1U="

ota:
  password: "f6c24d2e89bfc58d8cb1755ec6b3a7fc"

network:

spi:
  clk_pin: 14
  mosi_pin: 15

display:
  - platform: st7789v
    model: Custom
    height: 320
    width: 240
    offset_height: 0
    offset_width: 0
    cs_pin: 13
    dc_pin: 12
    reset_pin: 11
    backlight_pin: 10
    lambda: |-
      it.print(0, 0, id(roboto_20), "Hello World!");
      it.filled_rectangle(0,  0, 100, 100, id(my_yellow));

font:
  - file: "gfonts://Roboto"
    id: roboto_20
    size: 20

color:
  - id: my_blue
    blue: 100%
  - id: my_red
    red: 100%
  - id: my_green
    green: 100%
  - id: my_white
    red: 100%
    blue: 100%
    green: 100%
  - id: my_yellow
    hex: ffff00

Anything in the logs that might be useful for us?

I can't access the logs :-(

Any idea on how can I do so? Both plug in options for logs throw a timeout.

Additional information

I've also tried every solution proposed in the issues on this repository that seemed vaguely related plus the mandatory internet searches. Both unsuccessfully.

In addition to this, I also tried with the st7735 component to keep discarding options (in this case, to use a different implementation even it was buggy). Of course it didn't work either.

[carlosV2]

I've found the problem!

It seems like ESPHome isn't clever enough to know that I'm using a Raspberry Pi Pico (not the wireless version) so when it sees the network component, it happily compiles it. At this time I don't know how this affects the board but my guess is that it sets all the peripherals up (so I could render the blue square during setup) and then it tries to connect to some network which, in my case, it was surely failing so it got stuck somehow. This also prevented the logging from working.

In summary, removing the network component (which forces you to remove the ota and api components too) fixes the issue and the lambda is beautifully executed.

The reason why I had those components was because they came already set when I selected the pico board (not the W).

The interesting bit is that I created this device with a pre-2023.11.2 version. On the new version, the new devices are created with the wifi component instead. This component is equally silly on a non-wifi device but, at least, it fails the firmware compilation so the issue is prevented before runtime (not ideal but way better than before).