JC3248W535 - axs15231b - driver

JC3248W535 - LCD+Touch : axs15231b

  • ESP32-S3 3.5-inch capacitive touch IPS module 8M PSRAM 16M 320*480

GitHub - straga/micropython_lcd - axs15231b driver
for GitHub - lvgl-micropython/lvgl_micropython: LVGL module for MicroPython

Thank you for sharing. I think I will buy one when AliExpress has BF sale.

Is it ready to use when I upload your firmware *.bin files and the axs15231b driver or does it any require more configuration? I’m just asking since I have no experience building firmware and my attempts were always unsuccessfull when I tried.

Hi,
as you could see in LVGL 9.2 + esp32-s3 + display axs15321b - Get started - LVGL Forum I got axs15231b working with esp-idf 5.3 and LVGL9.2.2.

Actually it works only in full_refresh mode, but I can’t make it working in partial mode / direct mode.

It seems that command 0x2A and 0x2B doesn’t have any effects, so coloumn/page start/stop are stuck at (0,0) (319,479) … thus only a full display refresh management is possibile…
I also tried to put it in landscape mode via 0x36 command but works only the up-down/left-right mirroring settings.

I fully read the datasheet of axs15231b but I didn’t get any tip for me.

Do you have any idea what’s I’m missing or doing wrong?

Best regards and thank you anyway.

Bye.

Not support hardware. I think that not real axs15231b.
Esphome or arduino use software method for rotation. and use fullframe render too.

Sadly :frowning_face:, I have to agree with you.
That’s the only explanation: it’s not a real axs15231b.
Thanks a lot for your support and suggestion.
Best regards.
Bye

I am working on making the software rotate so it is able to be used across all the different bus types supported by my library. It’s a tricky thing because I want to keep the impact of doing the software rotate so it is as minimal as possible. I think I am going to need one additional frame buffer for each frame buffer the user allocates for LVGL. The buffers the user allocates doesn’t need to be DMA memory but it would perform better if it was internal memory. The frame buffers allocated for rotating will need to to use DMA memory.

It is quite a bit of work to get the code so it is able to be used across all of the different display busses. I am also adding into the mix the ability to dither RGB565 buffer data as well and also add in the RGB565 byte swapping. This way everything will be be able to be done all at the same time instead of iterating over the frame buffer multiple times.

Works great for me.
Is it possible to initialize the display in landscape mode?

It looks like the display does support hardware rotation… if using that driver add

display.set_rotation(lv.DISPLAY_ROTATION._90)

after the touch driver has been started.

Thanks for your answer, unfortunately this produces a distorted screen.
I’ve attached an image. Sorry for the bad quality, my phone sucks.

I have done some reading and as it turns out hardware rotation is not supported only software rotation is. I have been working on expanding software rotation so it works with all display bus types but I have not finished it yet.

I’m not sure what you mean by hardware rotation. I’m not so experienced in programming hardware drivers.
In theory, rotation should be possible using

_MADCTL_MX | _MADCTL_MV

according to the datasheet. Is this hardware or software rotation?
However, when I use this the content is displayed still in portrait mode and only the touch functionality seems to use “rotated” coordinates.

Hardware rotation means that the rotation is done by the actual display IC where as software rotation is done by repositioning the pixels in the buffer before it gets written to the display. How hardware rotation works is by setting different flags inside of the display IC it instructs the Display IC as to hot to store the pixel data in the internal memory of the IC.

There is a flaw in that display IC and hardware rotation doesn’t work properly which is why I had said it is not supported.

The touch being rotated is a function of LVGL.