[Request] Support for AXS15231B

[michaelhthomas]

Hi all. I happened across this library while trying to determine how to drive my AXS15231B display from Rust on an ESP32-S3 (https://www.aliexpress.us/item/3256807379732075.html). The datasheet for this display indicates that it supports MIPI DCS, so theoretically it should be possible to support through this library.

I unfortunately have very little experience with displays / drivers / etc, so I don't really know where to start with implementing this. I would appreciate some pointers / help getting support implemented (if I am correct that it's possible).

I have a manufacturer-supplied C driver that I can share if necessary. I am also happy to use my hardware to test.

Thanks!

[rfuest]

It will be possible to get this display working with this crate, but it will be a bit harder to implement because the controller is connected via QSPI. At the moment this crate has only been tested on regular SPI interfaces with a separate connection to select between command and data bytes.

As a first step I would suggest to get the display working by treating the QSPI interface as a regular SPI interface. In chapter 4.4 of the datasheet you can see that the upper data pins (D1-D3) are only used to transfer pixel data, but even this is optional. This makes it possible to just use a regular SPI interface and drive D1-D3 low via GPIO to get started.

The regular SpiInterface does require a DC pin to select between commands and data and needs to be modified to support this controller via QSPI (even if only one data bit is used). According to section 4.4 each 1 bit write needs to be prefixed with [0x02, 0x00] and an additional 0x00 byte needs to be inserted between the command and the parameters.

After you've configured the QSPI link correctly the only thing that should be missing is the init sequence, which can be copied from the manufacture code.

I've tried to implement the required changes to the Interface and a new Model in this GIST to help you get started: https://gist.github.com/rfuest/840342ed96d77a7c69df1df5bfcbff4e

[michaelhthomas]

Thanks for your input and help getting started! I'll give this a go in the next few days and see how it works out. I'm guessing the advantage of a proper QSPI implementation would be higher bandwidth? Honestly, I'd just be happy to get the display working at all, so implementing SPI first seems like a good choice.

[rfuest]

I'm guessing the advantage of a proper QSPI implementation would be higher bandwidth? Honestly, I'd just be happy to get the display working at all, so implementing SPI first seems like a good choice.

Yes, that's right, QSPI will be faster. Once the display is working it shouldn't be to hard to upgrade to QSPI.

[rfuest]

The QSPI display made me curious and I've ordered one of the modules to give it a try. I got the display to work, but it might not be possible to support it in this crate. All other controllers allow individual pixels or rectangular regions of the framebuffer to be updated, but I couldn't get this to work with this controller in QSPI mode. I think that the display is supposed to work similar to a RGB interface display when it is in QSPI mode, but the datasheet doesn't really make this clear.

Here is my basic proof of concept driver: https://gist.github.com/rfuest/911ace409b90a17d0462d36601197f80
You can use an embedded-graphics Framebuffer to prepare the data to send to the display:

let pin_cs = peripherals.GPIO45;
let pin_sck = peripherals.GPIO47;
let pin_q0 = peripherals.GPIO21;
let pin_q1 = peripherals.GPIO48;
let pin_q2 = peripherals.GPIO40;
let pin_q3 = peripherals.GPIO39;
let _pin_te = peripherals.GPIO38;
let pin_backlight = peripherals.GPIO1;

let spi = Spi::new(
    peripherals.SPI2,
    Config::default()
        .with_frequency(Rate::from_mhz(50))
        .with_mode(esp_hal::spi::Mode::_0),
)
.unwrap()
.with_sck(pin_sck)
.with_sio0(pin_q0)
.with_sio1(pin_q1)
.with_sio1(pin_q2)
.with_sio3(pin_q3);

let mut backlight = Output::new(pin_backlight, Level::Low, OutputConfig::default());
backlight.set_high();

let cs = Output::new(pin_cs, Level::High, OutputConfig::default());

let mut delay = Delay::new();

let mut display = Axs15231::new(spi, cs, &mut delay).unwrap();

let mut framebuffer: Framebuffer<Rgb565, _, BigEndian, 320, 480, { 320 * 480 * 2 }> =
    Framebuffer::new();
mipidsi::TestImage::new().draw(&mut framebuffer).unwrap();

display.update(framebuffer.data()).unwrap();

While the display update makes use of all 4 data pins the update is still a bit slow (~40ms for a full redraw), because the bus is idle ~50% of the time. I haven't looked into this closely, but it is probably possible to speed this up by using DMA.

[michaelhthomas]

Wow, thank you so much! I'm admittedly in way over my head, and hadn't made much progress getting this working. It does seem like the manufacturer-supplied driver utilizes DMA, which I'm sure would help the performance. I'll try out your proof-of-concept driver and see if I'm able to get any more out of it.