#Guition S3 320x480 LCD JC3248W535EN Dev Board configuration

266 messages Β· Page 1 of 1 (latest)

haughty bramble
#

JC3248W535EN 320x480 LCD Dev Board configuration

worldly tree
#

also, super minor, but might be worth saying "external component" in your README, since "custom component" is a different, now deprecated concept in ESPHome

haughty bramble
#

I agree - was just looking at that..

#

I wish I liked the esphome devices website more πŸ˜‚ its interface is not polished enough to me

#

I like that with the github page I just control everything etc.. if someone else wants to add it to the esphome-devices page go ahead using my data

#

esphome-devices has not section for LCD dev boards for instance so they are all lumped togeter in Misc which is a huge category of randomness..

worldly tree
#

I'm not sure how most people use it, but I think it's more intended for "I have X device, can it run ESPHome?" in which case it happens to have whatever ESP already in it. At least that's how I've used it.

haughty bramble
#

I just use google for that, hopefully my repo will get picked up in search results

worldly tree
#

I use google for the same, and it usually brings me to the esphome devices page for it πŸ™‚ but maybe that's because I've searched for various other esphome pages enough

haughty bramble
#

yeah not sure.. most of those ones im using are too new to be on there 😜

timber parrot
#

@haughty bramble what are the GPIOs of the various connectors on the back?
Does it have any extras like RS485 transceiver etc?

worldly tree
timber parrot
worldly tree
#

what about it?

timber parrot
#

Does it have AXS15231B...?

worldly tree
#

Unclear, it appears to be the waveshare esp32s3 4.3 inch type-b board, but their website seems to be down. Using archive.org, I can see their pages about it
https://web.archive.org/web/20240723222055/https://www.waveshare.com/esp32-s3-touch-lcd-4.3b.htm
https://web.archive.org/web/20240723095153/https://www.waveshare.com/wiki/ESP32-S3-Touch-LCD-4.3B
but neither provide much detail about how the display is driven.

You'll probably be able to tell by downloading their libraries and example, but you can't do that through the archive. I guess take a look whenever their site is back online?

haughty bramble
#

This one does not have rs485 - but it has general purpose IO connectors so you could connect an isolated CAN or Rs485 transceiver to it easily.

#

The linked 4.3" wave share ones do have CAN + Rs485 built in - I have one of those too but haven't used it yet.

#

On lots of my projects I want isolated interfaces now though which the wave share aren't so in that case you're better off with any general GPIO and a separate isolated transceiver module.

#

But I am planning to use one of the wave share ones to monitor CAN data from a BYD electric car and provide a supplementary dashboard with battery information.

brazen sedge
#

@flint quest new babe to play with? It has some i/o pins, and dedicated speaker output - probably will be interesting DIY alternative to the S3-BOX?

flint quest
haughty bramble
#

I know same here πŸ˜† my collection is getting out of hand.. I want to create a wall display with them all running some example ESPhome code, I have example configs for most in my ESPhome already.

flint quest
#

yes it's addictive ... especially with LVGL.

haughty bramble
#

Guition S3 320x480 LCD JC3248W535EN Dev Board configuration

novel burrow
#

Thanks for sharing, ordered the screen, can't wait to experiment further!

flint quest
#

I've had a Guition 4.3" screen in a drawer for ages... thought I would give your config a whirl with a couple of tweaks - i've got it working! couldn't find a display component for it previously. Thanks for sharing πŸ‘ for ref: this is a JC4827W543

haughty bramble
novel burrow
#

I just got this screen, but am struggling to get it to power up on usb-c cables. Very odd, never had this issue with other devices

#

Code works well though, thanks for sharing

haughty bramble
#

Did you use simple USB C to USB A like this? The C to C cables and USB PD power supplies can require extra resistors on the USB C port to deliver the 5V power which some of these dev boards don't have.

haughty bramble
#

It has to be 2 separate resistors also not one

#

I just looked and don't think it has them.

#

I'll ask the developer to add them to future devices. Allot of Chinese boards forget to add them unfortunately. I think C to C PD power supply are not as common in the development cycle so it does not get tested.

#

Its not that big a deal either just dont run it off a USB C PD supply..

worldly tree
#

I wasn't able to power a similar guition screen via USB either (with A-to-C or C-to-C), but connecting the 5V and GND from a USB-A cable to the header pins on the back worked just fine. πŸ€·β€β™‚οΈ

I don't think PD resistors or triggering logic would be needed for that (especially with an A-to-C cable) and it seems like they'd have to add extra componentry to prevent it from being powered that way.

haughty bramble
#

This one works fine with USB A to C - your other one maybe had some defect on the board like missing soldering etc. They all should power from USB, but maybe one of their boards isn't designed that way.

novel burrow
novel burrow
novel burrow
haughty bramble
#

Yes you can use LVGL the example just uses the default display Lambda, nothing custom.

#

I will be using LVGL with it sometime soon but haven't gotten around to it yet.

novel burrow
fickle cloak
#

@haughty bramble with LVGL ESPHome it doesn't work normally

haughty bramble
#

What is your YAML?

fickle cloak
haughty bramble
#

You need "update_interval: never" option in the display section, not sure if that will fix your issue but it is in the instructions for any display using LVGL

fickle cloak
haughty bramble
#

will try see what I can get working now

haughty bramble
#

Maybe try the "clean build" option? sometimes that fixes weird issues, or its something in those other included YAML files that I cant see

#

And here it is with a "bar" so I think the basics work

thin viper
#

hi. within 5 minutes

haughty bramble
#

It works fine vertical too just by changing rotation to 0

thin viper
thin viper
#

add spinner ((

#
  • spinner:
    x: 150
    y: 300
    spin_time: 2s
    arc_length: 60deg
    id: spinner_id
    indicator:
    arc_color: 0xd4d4d4
#

arc_color: 0xff0000

thin viper
#

pages:

- id: main_page
  bg_color: 0x000000
  widgets:
    - spinner:
        x: 150
        y: 280
        spin_time: 1s
        arc_length: 45deg
        id: spinner_id
        indicator:
          arc_color: 0xff0000
#

without out text before not correct X Y coordinates of spinner

worldly tree
#

data_rate: 40MHz #20mhz is default maybe that's too fast?

haughty bramble
#

It looks like it's actually correct the first time it displays, but then any updates to the display are not correct.. There may be some problems with the display init

#

I think it is something with selective redrawing parts of the display not working..

#

like the spinner just wants to redraw the middle pixels, but that does not work so it redraws the 0,0 pixels on the display

#

I tried 20mhz no difference

#

okay with "update_interval: never" it never displays anything.. So something must be up with how LVGL draws to the display..

#

That's with the update interval

#

Without it never shows anything but the default static pattern this display has after starting.

haughty bramble
#

Update: the issue is not really to do with the update interval.. That was something else

#

but it is always trying to redraw the spinner in the top left corner not where its supposed to be, and its corrupted looking

#

but the first draw of the entire display upon startup looks perfect

thin viper
#

problem with coordinates, x is destroyed almost always. also noticed if the area is larger than the matrix size
width: 480 height: 480 LVGL includes scrolling and no distortion in some positions

haughty bramble
#

Maybe something to do with this? not sure..

// custom x/y transform and color order
  uint8_t mad = MADCTL_RGB;
  // TODO(buglloc): MADCTL_MV is broken
  // if (this->swap_xy_)
  //   mad |= MADCTL_MV;
  if (this->mirror_x_)
    mad |= MADCTL_MX;
  if (this->mirror_y_)
    mad |= MADCTL_MY;```
https://github.com/clowrey/esphome-components/blob/main/components/axs15231/display/axs15231_display.cpp
thin viper
worldly tree
#

it would be better to not have to always redraw the complete display (since that can be pretty slow and eats up a lot of CPU cycles to do so), but better than drawing incorrectly

haughty bramble
#

yes of course, just trying to get it to work for now

worldly tree
#

adding more logging around what regions are being redrawn might help. e.g. some displays can only redraw in multiples of 8 pixels wide and/or high, which maybe it's not doing, or doing incorrectly?

haughty bramble
#

yeah I see that stuff in the source code, but dont understand it all

#

This branch with full display redraw fixes the issue of data updates not being put in the correct location. But makes it slow of course.

external_components:
  #- source:  github://clowrey/esphome-components
  - source:  github://clowrey/esphome-components@redraw-full
    components: [axs15231]
    refresh: 0min```
#

So it looks good now just slow 😁

haughty bramble
#

maybe something with this command this->set_addr_window_(this->x_low_, this->y_low_, this->x_high_, this->y_high_);

haughty bramble
#

that is with the original partial refresh external component, and full_refresh: true in LVGL config

external_components:
  - source:  github://clowrey/esphome-components
  #- source:  github://clowrey/esphome-components@redraw-full
    components: [axs15231]
    refresh: 0min

display:
  - platform: axs15231
    data_rate: 40MHz #20mhz is default
    id: my_display
    spi_id: display_qspi
    dimensions:
      height: 480
      width: 320
    cs_pin: 45
    backlight_pin: 1
    brightness: 50
    transform:
      swap_xy: false
    rotation: 0 # 90 for landscape, 0 for portrait
    #update_interval: never
    auto_clear_enabled: false
    #show_test_card: true # must enable update_interval, auto_clear_enable

lvgl:
  full_refresh: true
  displays:
    - my_display
  touchscreens:
    - my_touch
  theme:
    bar:
      radius: 0
      indicator:
        radius: 0
        arc_color: red
      
  pages:
    - id: main_page
      widgets:
        - label:
            align: TOP_MID
            y: 2 # distance down from top
            text: 'Battery Power kW'
        - bar:
            align: TOP_MID
            x: 0
            y: 20 # distance down from top
            id: bar_power
            indicator:
              arc_color: green
              radius: 0
            mode: symmetrical
            arc_color: blue
            value: 25
            width: 320
            height: 20
            min_value: -50
            max_value: 100


        - label:
            align: TOP_MID
            y: 50 # distance down from top
            text: 'Battery Volts'

        - spinner:
            align: TOP_MID
            x: 0
            y: 200
            spin_time: 5s
            arc_length: 20deg
            arc_color: 0x00ff00
            id: spinner_id
            indicator:
              arc_color: 0xff0000

hallow vortex
#

Ah, I now see that this is an external component..

haughty bramble
#

yes, it may need that too though

#

at least two others created it - one is still working on it but I have not been able to contact them

#

I modified the display init code to make it work with this display

#

it only works with ESP-IDF since its based on that framework which already supports these displays natively

gilded citrus
#

on github says it is JC3248W535EN but on aliexpress link it is JC3248W535C is this right or? ,

haughty bramble
#

They're the same I believe

#

C means capacitive touch but they only come with that I believe

thin viper
#

work ok. too low update rate . set update_interval: 100ms did not lead to the desired, animation is very bad

worldly tree
#

that's because it takes a long time to redraw the entire screen

haughty bramble
#

Yes, someone with more experience programming these display drivers will hopefully get one and tinker with it 😁

tribal egret
#

I have completely solved the partial update problem in https://github.com/esphome/esphome/pull/7594. Still needs a new feature in LVGL to align updates to 8 pixel boundaries, also in PR. It works quite nicely now. Touchscreen driver in PR too.

haughty bramble
#

AWESOME!!!

tribal egret
#

Rotation to landscape still not possible in hardware, but the LVGL PR has optimisation for SW rotate, works quite satisfactorily.

haughty bramble
#

Cool! thanks so much for implementing that! I'll try it out when I can in a few days.

tribal egret
#

You'll need to clone my repo, there is a core change (constant migrated to const.py) that stops it compiling with just external components, sadly.

dawn rock
#

Hi! Guition JC3636W518 comes from the same supplier and uses different display ICs and touch ICs. Do you have time to make a driver for it?@haughty bramble

haughty bramble
dawn rock
#

@haughty bramble The microphone and DAC/CST816 are both working properly, and I have tested the voice assistant component and it is also working properly. It only shows that it cannot work. I do not have the ability to write C++code and cannot create effective drivers for it. I hope someone in the community can take notice of it

tribal egret
#

The qspi_dbi driver will almost certainly work with the correct init sequence, which can be provided in YAML, no C++ needed. Just need to take a known working init sequence and put it in YAML with the right pin definitions. There's a HA forum thread that appears to have that information.

flint quest
dawn rock
#

@tribal egretI used the dev version of ESPHome and your QSPI DPI component, and it worked. I may have added the initialization sequence incorrectly. The work is very strange and shows confusion. I am unable to obtain its correct sequence, can you provide me with a prompt?

dawn rock
#

If there is the correct sequence, it should work properly

haughty bramble
#

It looks like it is doing something though so thats good!

dawn rock
haughty bramble
#

did you get the init sequence from the Guition source files?

dawn rock
haughty bramble
#

The demo with the source for the board init is in this file I believe. It may be the same I didnt check it fully yet.

#

looks somewhat different, maybe you can try that one. I better go to sleep.. goodluck!

dawn rock
#

πŸ‘Œ

tribal egret
dawn rock
#

It appears that the size is incorrect. This screen is 360 * 360. When I set it to 180 * 180, the x-axis is exactly right. The y-axis is missing a part@tribal egret

#

I have tried many sequences, but they have always been incorrect. My luck is very bad.

#

This is the sequence included in the official routine, and I am currently using it.

#

@tribal egretMay I ask if you can provide me with more tips on initialization sequences?😁

haughty bramble
dawn rock
#

The color is completely incorrect and the size is also incorrect. I cannot find the cause of the error. unfortunatelyπŸ€¦β€β™‚οΈ

haughty bramble
#

There is more custom stuff in the display setup I linked above possibly? I am not an expert but near the bottom maybe..

#

The way in which it's incorrect is hints to whats wrong though.. that's why the test screen helps to debug

#

This may be non standard too, not sure

static void my_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p)
{
  ESP_PanelLcd *lcd = (ESP_PanelLcd *)disp->user_data;
  const int offsetx1 = area->x1;
  const int offsetx2 = area->x2;
  const int offsety1 = area->y1;
  const int offsety2 = area->y2;
  lcd->drawBitmap(offsetx1, offsety1, offsetx2 - offsetx1 + 1, offsety2 - offsety1 + 1, (const uint8_t *)color_p);
}
dawn rock
#

You said this part should be from lvgl. I have reviewed the document for st77916. I can't understand the write and read commands at all.also need to configure the color format.

haughty bramble
#

LVGL / not doesn't really matter?

#

I can try some tests on mine later today

dawn rock
#

It's great that you can continue testing. It's my turn to sleep. All peripherals except for the screen are currently working. Come on, buddy

haughty bramble
#

I tried your YAML above and it does this with the test routine upon first boot - you can see the previous image still above so it's not writing those pixels. Upon rebooting it the top part is static. Just putting this here for reference

haughty bramble
#

The init sequence in the .h file from Guition I included above has extra data for some bytes, the 1, 0 #1287891890330533959 message

    {0xA5, (uint8_t[]){0xC3}, 1, 1},
    {0xA3, (uint8_t[]){0x2E}, 1, 0},
    {0xA5, (uint8_t[]){0xC3}, 1, 1},
    {0xA3, (uint8_t[]){0x2F}, 1, 0},
    {0xA5, (uint8_t[]){0xC3}, 1, 1},
    {0xA3, (uint8_t[]){0x30}, 1, 0},
    {0xA5, (uint8_t[]){0xC3}, 1, 1},
    {0xA3, (uint8_t[]){0x31}, 1, 0},
    {0xA5, (uint8_t[]){0xC3}, 1, 1},
    {0xA3, (uint8_t[]){0x32}, 1, 0},
    {0xA5, (uint8_t[]){0xC3}, 1, 1},
haughty bramble
#

I think they are delays.. I added like this

      - [ 0xA3, 0x2E ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
      - [ 0xA3, 0x2F ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
      - [ 0xA3, 0x30 ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
      - [ 0xA3, 0x31 ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
      - [ 0xA3, 0x32 ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
      - [ 0xA3, 0x33 ]
      - [ 0xA5, 0xC3 ]
      - delay 1ms
#

Doesn't work yet though, finding more init sequence.

haughty bramble
#

The init sequence from modi12jin you linked above and the Guition example are identical

#

I just realized that is the library that the manufacturer provided example uses too

haughty bramble
#

Oooh I uncommented the 16bit line and then this! The end of the init looks like this now

      - delay 10ms
      - [ 0x4C, 0x00 ]
      - [ 0x2A, 0x00, 0x00, 0x01, 0x67 ]
      - [ 0x2B, 0x00, 0x00, 0x01, 0x67 ]
      - [ 0x21, 0x00 ]
      - [ 0x3A, 0x55 ] # color=16
      - [ 0x11, 0x00 ]
      - delay 120ms
      - [ 0x29, 0x00 ]
#

right when I had just about given up again lol

#

This should really be on its own "show-off" post though lol maybe @dawn rock wants to create it since he started this whole endeavor of the 360x360 display..

haughty bramble
haughty bramble
worldly tree
haughty bramble
tribal egret
worldly tree
#

Oops, that's actually what I meant to link to πŸ™ˆ although I guess there should be a list of possible models in the docs as well

dawn rock
#

When I woke up and saw this picture, I was very excited. It was all worth it. All peripherals of this device are now supported by ESPHome. I cannot add any extra threads or pull it to devices.
esphome. io because my English is really poor. I hope someone can do these things.
Thank you @haughty bramble for your effortsπŸŽ‰ . Thank you for the qspi-dbi component of @tribal egret πŸŽ‰

dawn rock
#

https://community.home-assistant.io/t/respeaker-lite-new-seeed-studio-voice-assistant-development-kit-hardware-combine-esp32-with-xmos-xu316-dsp-chip-for-advanced-audio-processing-as-a-esphome-based-home-assistant-assist-satellite-voice-devkit/756944/212?u=niub I tested the new media_player and nabu components on top and they worked very well. They can make announcements without stopping the music. During the announcement period, the concert will be avoided by lowering the volume. I didn't dodge successfully and may need more settings.

haughty bramble
wet iron
#

@haughty bramble I basically copied your config and it works but on my display I see perhaps three or four rows of garbage on the very top. Any suggestions?

haughty bramble
#

I think I saw that too, barely noticeable on my display, it may be some part of that init sequence slightly off, you could try change things around.

tribal egret
wet iron
#

@tribal egret What gets the offset? I've tried display, pages, widgets, lvgl...

tribal egret
#

The display. Per the docs.
dimensions (Required): Dimensions of the screen, specified either as width x height (e.g 320x240) or with separate config keys.
height (Required, int): Specifies height of display in pixels.

width (Required, int): Specifies width of display.

offset_width (Optional, int): Specify an offset for the x-direction of the display, typically used when a display is smaller than the maximum supported by the driver chip. Default is 0

offset_height (Optional, int): Specify an offset for the y-direction of the display. Default is 0.

wet iron
#

ah! ok.

wet iron
#

I set both offset_width: 50 and offset_height: 50 and I see no difference. Could I be doing something wrong?

#

Hmm. I asked the parent container to draw a border and the border appears within the garble-y area. Very strange.

haughty bramble
#

Maybe init still slightly off, the datasheet linked way above may have hints

wet iron
#

Ah, ok, I'll take a look.

haughty bramble
#

the height offset like Clyde said worked for me, will post code once I have correct offset

#

looks like 2 is all that's required for mine.

display:
  - platform: qspi_dbi
    model: CUSTOM
    data_rate: 40MHz
    id: main_display
    spi_id: display_qspi
    color_order: rgb
    invert_colors: true
    dimensions:
      height: 360
      width: 360
      offset_height: 2
    cs_pin: 10
    reset_pin: GPIO47
    # transform:
    #   mirror_x: true
    #   mirror_y: true
    rotation: 180
    #show_test_card: true # must enable update_interval, auto_clear_enable
    #update_interval: never #comment out for LVGL
    auto_clear_enabled: false #set to false for LVGL
#

oh lol I just noticed I have a gap on the bottom now! so the resolution must be 362!

#

not sure doing more testing.. switching rotation to 0 also for testing..

haughty bramble
#

With rotation zero you can see that the missing lines are at the bottom, trying 362 pixel again

#

Ya setting the height to 362 fixes it for me. Zero offset.

wet iron
#

Are you still working with the 320x480 display?

haughty bramble
#

Ya but I thought you had the round one for some reason lol.. I think because I had noticed the 2 extra pixel lines yesterday on the round one before you mentioned it and assumed it was the same. it also needed slight changes obviously..

#

It's probably same issues though offset or display resolution, I can try it later

dawn rock
#

I was planning to use it to create a menu animation, but it doesn't seem worth the effort. But it can be shared with those in need.😁

#

script:

  • id: home_image_siyecao_update_angle
    then:
    • repeat:
      count: 100
      then:
      - lvgl.widget.update:
      id: home_image_siyecao
      transform_pivot_x: !lambda |-
      return 128;
      transform_pivot_y: !lambda |-
      return 128;
      transform_angle: !lambda |-
      static float angle = 0;
      angle += 0.36 * 100;
      return angle;
      - delay: 7ms
haughty bramble
#

interesting! im surprised it as as smooth as that! I see you have the slight extra pixels too, change your display "height" to 362 to fix

dawn rock
#

It's quite suitable for making fan animations

#

Yeah, I saw your configuration. I will make the necessary modifications

worldly tree
#

Yeah calculating arbitrary image rotations is pretty computationally expensive, especially without a gpu. In addition, the size of your widget basically means almost the entire display needs to be redrawn, which can take "a while" to transfer even over qspi

sinful arch
dawn rock
#
  - file: "image/home.png"
    id: home_image
    resize: 256x256
    type: RGB565pages:```
   ``` - id: home
      widgets:    
        - image:
            align: CENTER
            src: home_image
            id: home_image_siyecao
            antialias: true
        - button:
            id: clover_top_center
            align: CENTER
            width: 50
            height: 50
            radius: 50           
            on_press:
               then:
                  - script.execute: home_image_siyecao_update_angle

script:
  - id: home_image_siyecao_update_angle
    then:
      - repeat:
          count: 100
          then:
            - lvgl.widget.update:
                id: home_image_siyecao
                transform_pivot_x: !lambda |-
                  return 128;
                transform_pivot_y: !lambda |-
                  return 128;
                transform_angle: !lambda |-
                  static float angle = 0;
                  angle += 0.36 * 100;
                  return angle;
            - delay: 7ms```
sinful arch
#

πŸ‘

dawn rock
#

@sinful archPossible crash, please use with caution

sinful arch
#

Ok thanks

#

Have you done any tests with VNC?

dawn rock
#

no

sinful arch
#

as i saw the first video it looked like vnc

dawn rock
#

Are you referring to sdl and host platform?

sinful arch
#

Yes

dawn rock
#

Yeah, the first video is from the host platform. The same configuration has resulted in high latency and possible crashes on the ESP32 platform! Clyde is trying to improve the animation implementation

sinful arch
#

on my codes that I use in animation I was obliged to make an interval

#

for info I'm waiting for this screen

dawn rock
#

A shorter interval can cause lvgl blockage. So we have to lengthen the interval. However, extending the interval will result in the entire screen taking too long to complete. So it's difficult to use in interaction. But it does not hinder its use in some other use cases. For example, creating a small animation with a fan turned on.

sinful arch
#

yes it's true, as I'm on a 33 small screen box so it works well surely on the big screens often crashes

tribal egret
#

I notice in the yamls in this thread a couple of places where psram is set to 120MHz - this does not work, 80MHz is the max. Setting to 120 makes it fall back to 40 so is actually slower.

sinful arch
#

Well seen

haughty bramble
#

That's on me.. not sure where I copied it from originally lol

sinful arch
#

🀣

haughty bramble
tribal egret
#

You aren't using the right display driver.

haughty bramble
#

Ooh there is a new one by that name I guess? I will try

tribal egret
#

Use the ESPHome driver. It's in dev.

haughty bramble
#

I am using dev with no external components

#

But maybe not the right driver

tribal egret
#

Model should be axs15231 or something like that.

#

No init sequence needed.

haughty bramble
#

Oh wow didn't realize you added that too

tribal egret
#

Oh, the docs didn't mention the new model.

haughty bramble
tribal egret
#

In the lvgl config you need draw_rounding: 8

#

It's a fussy chip. Damn fast though.

haughty bramble
#

Yeah full screen refresh seems doable! pretty neat. Thanks for the help its compiling now πŸ™‚

#

works now!! Thanks! Ill update my github..

dawn rock
wet iron
#

And no garbage lines. It's perfect.

wet iron
#

I spoke too soon, @haughty bramble are you seeing garbage in semi-random places when you update the screen?

#

For example:

haughty bramble
#

no, but I have not used it extensively yet.. You could try lower the clock rate or maybe there is still some small bug in the setup.

#

and you have the draw_rounding: 8 in the LVGL right?

wet iron
#

Yes

haughty bramble
#

what if you add the full refresh?

#

its probably something again with how it updates parts of the display, not being perfect

wet iron
#

Lowering the rate to 20 didn't work. Removing data_rate: didn't work. but that defaulted to 10

haughty bramble
#

I'm guessing full_refresh: true will fix it at least temporarily. This display is so fast it may be fine like that too for your uses

#

Clyde will probably see this and know what the problem is and potentially have to update how the driver is configured on the backend πŸ˜‰ don't want to disturb him until he notices on his own though

wet iron
#

lvgl.widget.redraw: worked. This is a very slow-acting display so that's probably ok.

#

It's glued onto my kids' mirror.

haughty bramble
#

Adding full_refresh: true to the LVGL config should work too

#

If you can post a full yaml that duplicates the issue that would help it get fixed later

wet iron
#

Yes, that worked as well.

#

Is there a preferred way to post full yml? I mean my full file is bruuuutal - something like 400 lines.

haughty bramble
#

when you paste it in here it will turn it into a file so not too bad

#

or you can just paste a smaller one with the relevant parts to generate error

wet iron
#

That's what I normally do. But putting full_refresh: true worked so I'm happy. Thanks for that sample!

haughty bramble
#

Yeah just will need to get it fixed for full functionality.. thats basically a bandaid fix

wet iron
#

Do you happen to know if this unit has a light sensor? I can't see one specified anywhere.

haughty bramble
#

not that I know of

wet iron
#

I'm using the JC3248W535C

tribal egret
wet iron
tribal egret
#

There was a bug in the 90 degree rotation code in the lvgl component (270 worked fine) that is now fixed in dev.

wet iron
#

Recently? I've been using 2024.11.0-dev

#

Thanks for the tip!

haughty bramble
dawn rock
tribal egret
wet iron
#

I pull the latest.

#

I don't use docker.