mipidsi icon indicating copy to clipboard operation
mipidsi copied to clipboard

Display window selection not working

Open isaac-asdf opened this issue 10 months ago • 6 comments

I'm working on adding a Model for a ili9488 based display (https://www.waveshare.com/pico-restouch-lcd-3.5.htm). This could be something I'm doing wrong in the initialization, but the problem I'm having is that when drawing, the window selection doesn't seem to be working. So all area fill commands just will write from (0,0) and fill column-based until it's filled the area specified by the "Rectangle":

    let area: Rectangle = Rectangle::new(Point::new(50, 50), Size::new(50, 50));
    let _ = display.fill_solid(&area, Rgb565::RED);

Do you have any ideas on what might be wrong?

Main code mipidsi fork

isaac-asdf avatar Apr 11 '24 02:04 isaac-asdf

Maybe this line is the issue https://github.com/isaac-asdf/waveshare-testing/blob/d9925ef6c6504af42bc58cff7f065e63cc53d214/src/main.rs#L100. The ILI9488 framebuffer is 320x480 and not 480x320. The size is correct in ili9488.rs: https://github.com/isaac-asdf/mipidsi/blob/9580876785178257ea637b2ca8b78cb2cc5609ec/mipidsi/src/models/ili9488.rs#L20 I'm not sure if there are any checks for valid display sizes in the builder.

If changing this doesn't have an effect: Does set_pixel work as expected?

rfuest avatar Apr 11 '24 13:04 rfuest

Thanks for the suggestions. I updated the framebuffer in the definition, and tried testing with set_pixel and set_pixels with the same results. I pushed my latest code to that same repo/branch.

Multiple calls to set_pixels resulted in only the last call's pixels being present, and the pixels were set starting at the screen origin of (0,0) with 6 total pixels present, even though I would've expected the pixels to overwrite in the first location based on only 1 start/end pixel being chosen

isaac-asdf avatar Apr 12 '24 01:04 isaac-asdf

This https://github.com/isaac-asdf/mipidsi/blob/9580876785178257ea637b2ca8b78cb2cc5609ec/mipidsi/src/models/ili9488.rs#L93-L97 doesn't seem right. According to the datasheet the 0xB6 command takes 3 parameter bytes, but the code only sends 2. I'm not sure how the controller handles missing parameters and perhaps the NL parameter gets set to an invalid setting if it is missing. The comment above the command refers to "memory access data control", but that command is 0x36 and not 0xB6.

rfuest avatar Apr 12 '24 14:04 rfuest

Outdated comment, but yeah that command was missing the third param. I had been copying some example C code from the waveshare wiki. I added a parameter for that but I'm still having the same problem. I'm going to be testing modifying some of those parameters in the set up section for the display, it seems like there must be something wrong with how I'm configuring the chip

isaac-asdf avatar Apr 17 '24 02:04 isaac-asdf

Is there a difference in how command packets are formed based on long packet vs short packet?

I'm looking at the manual for this chip and on page 89 it specifies that the Column Address Set and Page Address Set require the "long packet" format. It seems like all other commands I'm using work with the "short packet", so I'm wondering if there's something about building that packet that I need to add for this.

isaac-asdf avatar Apr 20 '24 02:04 isaac-asdf

These differences only apply when the controller is connected via a MIPI DSI interface, which you don't use when the display is connected via SPI.

rfuest avatar Apr 20 '24 14:04 rfuest