Hi Arnold,
The device has been fine for me with standard graphics. I did note, however, that the display went crazy if any activity went outside the display area. So, in my code I use the ‘clip’ function for the visible area then it behaved correctly. That should really be something that driver handles.
Thanks for the reply and sorry it’s taken a while to respond, we’re in between hurricanes in Florida and it’s taking all my concentration at the moment. I’m having the same issues with LVGL on this and jumped over to one of the 4x4 screens that is comparatively a joy to use. I think I’ll order one of those larger ones too to have a try with it. Not giving up on these 320x240 ones though, as it’s perfect for a particular decade of mine; just needed a break before I flung it across the yard
navigate to the ‘axs15231_display.cpp’ file. At line 253 you will find the function ‘AXS15231Display::display_’
modify the 4 lines (commented with #######) as follows…
void AXS15231Display::display_() {
if ((this->x_high_ < this->x_low_) || (this->y_high_ < this->y_low_)) {
return;
}
// we will only update the changed rows to the display
// ########### force the next 2 lines to full width and height
size_t const w = this->width_; //this->x_high_ - this->x_low_ + 1;
size_t const h = this->height_; //this->y_high_ - this->y_low_ + 1;
size_t const x_pad = this->get_width_internal() - w - this->x_low_;
// ########### force the window to full screen
this->set_addr_window_(1, 1, this->width_, this->height_);
// this->set_addr_window_(this->x_low_, this->y_low_, this->x_high_, this->y_high_);
this->enable();
// ########### force the next line to always draw the full screen
if (true) { //(this->x_low_ == 0 && this->y_low_ == 0 && x_pad == 0) {
this->write_cmd_addr_data(8, 0x32, 24, 0x2C00, this->buffer_, w * h * 2, 4);
} else {
this->write_cmd_addr_data(8, 0x32, 24, 0x2C00, nullptr, 0, 4);
size_t stride = this->x_low_ + w + x_pad;
for (int y = 0; y != h; y++) {
size_t offset = ((y + this->y_low_) * stride + this->x_low_);
this->write_cmd_addr_data(0, 0, 0, 0, this->buffer_ + offset * 2, w * 2, 4);
}
}
this->disable();
this->invalidate_();
}
save and recompile.
This prevents the quick screen updates and forces a complete redraw so it wont be quicker. but at least the display should work until we get a better fix.
I’ve tested with the standard graphics and still ok.
Any issues, let me know.
Derham
It works here also, now trying to see if whe can only update the part that is altered.
i will try to look at it in the weekend, little less in time at the moment.
This is a working LVGL config that does some partial updates, using the existing qspi_amoled driver. The display driver chip appears to only write data from 0,0 so proper partial updates don’t work. I’ve added some code to the LVGL component to partially work around this.
All the usual LVGL stuff should work with this.
Some notes:
The display can be rotated 180 or mirrored using mirror_x and mirror_y, but swap_xy does not work.
Software rotation using rotation: 90 works (also for 270) but requires full screen redraws so is slow. The display itself is quite fast so it’s still usable though.
Hi Clyde,
Thanks for looking at this. The yaml compiles and works fine although it does give an error in esphome…
[draw_from_origin] is an invalid option for [lvgl].
Displays the button, checkbox and rotating arc nicely though.
but at least the display should work until we get a better fix.
