#Guition S3 320x480 LCD JC3248W535EN Dev Board configuration
266 messages Β· Page 1 of 1 (latest)
you should added to the device docs! π
https://github.com/esphome/esphome-devices
also, super minor, but might be worth saying "external component" in your README, since "custom component" is a different, now deprecated concept in ESPHome
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..
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.
I just use google for that, hopefully my repo will get picked up in search results
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
yeah not sure.. most of those ones im using are too new to be on there π
@haughty bramble what are the GPIOs of the various connectors on the back?
Does it have any extras like RS485 transceiver etc?
If it's the same as this one (which I think it is) I'm not seeing RS485
https://www.aliexpress.us/item/3256807380001174.html
This one supposedly does though
https://www.aliexpress.us/item/3256807364497678.html
what about it?
Does it have AXS15231B...?
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?
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.
@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?
i'm collecting displays at the moment π€£ please don't tempt me to buy more π€¦ββοΈ
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.
yes it's addictive ... especially with LVGL.
Guition S3 320x480 LCD JC3248W535EN Dev Board configuration
Thanks for sharing, ordered the screen, can't wait to experiment further!
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
Awesome! Get it on GitHub and share a link to YAML π
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
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.
If those resistors are missing C to C PD power supplies won't deliver 5V on connection.
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..
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.
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.
yes I got it running using a usb-a cable + adaptors. It also worked on a pi PSU. Bit of a pain tho
it wouldn't power up when I was trying to flash it using my mac, until I used a usb-a cable.
This is probably a really stupid question, but can you use this with LVGL? I assumed your code used it, but can't see the entry, so assume is custom.
I wish getting starting with the basics was a bit easier. Anyone know of a guide or youtube video?
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.
Fab. I don't really get the lambda stuff. Will try to find an easy entry point to start playing around with lvgl. Thanks π
@haughty bramble with LVGL ESPHome it doesn't work normally
What is your YAML?
File and photos of my friend, I do not have this device
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
Unfortunately, it didn't help. It's possible (this is just an assumption) that the display flips when touched. It seems to work fine with text, but with graphics, miracles begin. Could you test the LVGL ESPHome code, for example with a grid, which would work stably? Or can we ask someone to refine and test the library for subsequent implementation?
will try see what I can get working now
I just made that quick demo and its working, but haven't tried all the functions yet:
https://github.com/clowrey/ESPhome-JC3248W535EN/blob/main/guition-320x480-jc3248w535-lvgl-minimal.yaml
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
add spinner ((
- spinner:
x: 150
y: 300
spin_time: 2s
arc_length: 60deg
id: spinner_id
indicator:
arc_color: 0xd4d4d4
arc_color: 0xff0000
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
data_rate: 40MHz #20mhz is default maybe that's too fast?
You're right it does have issues with the spinner! it looks like its actually duplicating the data at the first pixel locations.. It still displays the spinner at correct location for me, but there is a glithcy one at the start of the display pixel area too.. I am trying things to fix
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.
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
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
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
These upstream commits 48 minutes ago may be fixing it! "always redraw complete display"
https://github.com/buglloc/esphome-components/commit/2dbdac577006318481fd0db71bd8c67b12370a59
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
yes of course, just trying to get it to work for now
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?
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 π
maybe something with this command this->set_addr_window_(this->x_low_, this->y_low_, this->x_high_, this->y_high_);
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
Oh, I think I saw in one of the esphome's display drivers that this method has uint8_t arguments or logic...
Ah, I now see that this is an external component..
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
on github says it is JC3248W535EN but on aliexpress link it is JC3248W535C is this right or? ,
They're the same I believe
C means capacitive touch but they only come with that I believe
work ok. too low update rate . set update_interval: 100ms did not lead to the desired, animation is very bad
that's because it takes a long time to redraw the entire screen
Yes, someone with more experience programming these display drivers will hopefully get one and tinker with it π
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.
AWESOME!!!
Rotation to landscape still not possible in hardware, but the LVGL PR has optimisation for SW rotate, works quite satisfactorily.
Cool! thanks so much for implementing that! I'll try it out when I can in a few days.
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.
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
I have that one too, but yes it is very different - I don't myself have the ability to make a driver for it. And have no way to use it currently with ESPhome. It is very nice otherwise though.
@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
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.
Hi Clyde - another day...another display π€¦ββοΈ do you know if this would also work for the guition JC4827W543 ESP32-S3 ?
@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?
If there is the correct sequence, it should work properly
Anytime asking for help like that you should share your current YAML
It looks like it is doing something though so thats good!
yeahοΌ This is the YAML I am currently using
did you get the init sequence from the Guition source files?
https://github.com/modi12jin/IDF-S3_ST77916-QSPI_CST816T-I2C_LVGL/blob/main/main/main.c No, I obtained the initialization sequence from here.
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!
π
Should do, all you gotta do is find the pins and init sequence. It is apparently a QSPI chip also.
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?π
Use the color test card for testing like this, can sometimes make issues easier to spot
https://esphome.io/components/display/index.html#using-the-color-test-card
The color is completely incorrect and the size is also incorrect. I cannot find the cause of the error. unfortunatelyπ€¦ββοΈ
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);
}
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.
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
This is the specification sheet for st77916. I hope it will be helpful to you
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
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},
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.
The init sequence from modi12jin you linked above and the Guition example are identical
The one here is the same too https://github.com/esp-arduino-libs/ESP32_Display_Panel/blob/master/src/lcd/base/esp_lcd_st77916.c
I just realized that is the library that the manufacturer provided example uses too
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..
using the latest DEV here is my example for it, based on @dawn rock original, just fixed the init part. And mostly thanks to @tribal egret who made the QSPI component extensible for the external init: https://github.com/clowrey/esphome-guition-360x360-jc3636w518/tree/main
With LVGL works perfectly too - I added LVGL example to my github repo for it
That init sequence should get rolled into a model:, and then add it to the docs!
https://github.com/esphome/esphome-docs/
Edit: I mean a page on https://github.com/esphome/esphome-devices/
Definitely.. I get lazy at that part though.. and suck at GIT.. but you or anyone else who feels like it please add to the docs etc
Or just documented in devices.esphome.io.
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
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 π
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.
Back on track with the 320X480 Guition display π I just tried and its now working with the native qspi-dbi component!
Updates are very smooth!! @thin viper Try out this code π Make sure you use DEV version of ESPhome or it wont compile.
https://github.com/clowrey/ESPhome-JC3248W535EN/tree/main
@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?
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.
You may need to set a y_offset. These displays sometimes have fewer pixels than the driver chip, and some rows or columns are unused - if they're at the end that's fine, if at the beginning you need to set the offset to match. Trial and error may be needed.
@tribal egret What gets the offset? I've tried display, pages, widgets, lvgl...
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.
ah! ok.
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.
Maybe init still slightly off, the datasheet linked way above may have hints
Ah, ok, I'll take a look.
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..
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.
Are you still working with the 320x480 display?
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
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
- repeat:
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
It's quite suitable for making fan animations
Yeah, I saw your configuration. I will make the necessary modifications
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
what did you put on lvgl?
- 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 archPossible crash, please use with caution
no
as i saw the first video it looked like vnc
Are you referring to sdl and host platform?
Yes
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
on my codes that I use in animation I was obliged to make an interval
for info I'm waiting for this screen
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.
yes it's true, as I'm on a 33 small screen box so it works well surely on the big screens often crashes
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.
Well seen
That's on me.. not sure where I copied it from originally lol
π€£
I did just try the config again and noticed I still had LVGL full refresh in the code from before... It actually doesn't work without that still, but the refresh of the full screen was so fast I hadn't noticed. This is what it looks like without full refresh.
You aren't using the right display driver.
Use the ESPHome driver. It's in dev.
Oh wow didn't realize you added that too
Oh, the docs didn't mention the new model.
It's doing this now it's in the right spot but some weird artifacts around the updated area
Yeah full screen refresh seems doable! pretty neat. Thanks for the help its compiling now π
works now!! Thanks! Ill update my github..
Your 320x480 should work with this config: https://github.com/clowrey/ESPhome-JC3248W535EN/blob/main/guition-320x480-jc3248w535-native-qspi_dbi.yaml
I found this old 2.1-channel speaker in my scrap warehouse. They work very well togetherπ
Yes, it works! Thank you.
And no garbage lines. It's perfect.
I spoke too soon, @haughty bramble are you seeing garbage in semi-random places when you update the screen?
For example:
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?
Yes
what if you add the full refresh?
its probably something again with how it updates parts of the display, not being perfect
Lowering the rate to 20 didn't work. Removing data_rate: didn't work. but that defaulted to 10
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
lvgl.widget.redraw: worked. This is a very slow-acting display so that's probably ok.
It's glued onto my kids' mirror.
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
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.
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
That's what I normally do. But putting full_refresh: true worked so I'm happy. Thanks for that sample!
Yeah just will need to get it fixed for full functionality.. thats basically a bandaid fix
Do you happen to know if this unit has a light sensor? I can't see one specified anywhere.
not that I know of
I'm using the JC3248W535C
home_image ??
What rotation are you using?
90
There was a bug in the 90 degree rotation code in the lvgl component (270 worked fine) that is now fixed in dev.
I think he means he fixed it just now, it will take time for you to get it.
An image stored locally, you only need to reference the path in the configuration file
If you're using the docker image, there is a delay. If using a cloned git install, just pull. Well, either way, you need to pull the latest π