almindor / mipidsi

MIPI Display Serial Interface unified driver
MIT License
108 stars 47 forks source link

Display window selection not working #124

Open isaac-asdf opened 2 months ago

isaac-asdf commented 2 months ago

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

rfuest commented 2 months ago

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?

isaac-asdf commented 2 months ago

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

rfuest commented 2 months ago

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.

isaac-asdf commented 2 months ago

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 commented 2 months ago

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.

rfuest commented 2 months ago

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.