BRT Community

Quote from: Rudolph on March 31, 2025, 04:24:03 PM
I just went back to this and added:

EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);

And with this I have it up and running on my RVT101H right now with more buttons and the gradient.

Forgive me for the late reply, but I did not receive a notification.
I had some time today to make some tests, and enabling the adaptive framerate as well as adding the line you mentioned did work very well. Thanks a lot, that's going to help a great deal going forward.

I also noticed a typo in my own code, which would explain why I read 0 for underrun; after fixing that, the example I posted before gave me a ~72000 value.

Quote from: BRT Community on March 25, 2025, 03:16:34 PM
Can I ask what system clock frequency you are running the BT817 at? (I note that the specific Riverdi panel requires a PCLK typical value of 72MHz)
Have you applied any settings to the REG_AH_HCYCLE_MAX or REG_ADAPTIVE_FRAMERATE registers?

If possible could you perform a read of REG_UNDERUN and print this on screen at a set time interval?

I've set it up at 72MHz by using the values provided in the datasheet (https://download.riverdi.com/RVT101HVBFWCA0/DS_RVT101HVBFWCA0_Rev.1.5.pdf).
I've not yet tried the adaptive framerate as I wasn't entirely sure the screen supported it (they don't mention it in the datasheet), though I did read that the BT817Q itself does.

I saw REG_UNDERRUN mentioned in some other topics in this forum, but I keep reading 0. I'm performing the read before sending the final SWAP command, is that correct or should I be reading it somewhere else?


Also, I'm not sure if this is useful, but I noticed that reading the command fifo and the display list values during this problematic screen shows 380 and 164; after moving the button (with the display appearing properly) I read the expected 380 and 3672.

Good morning,
I wanted to get some feedback on this issue I've been having while using the BT817Q. In the company I'm working with we've been using FT810 in a variety of devices, so I had a decent familiarity with the way they work, though I'm by no means an expert. I believe we're using a custom driver to call the various FT81x/BT81x commands, which has been tested thoroughly throughout the years.

In the past few months we started using newer capacitive displays, which use the BT817Q. I've been encountering some weird outputs even with some pretty simple display lists and I was hoping someone could point me in the right direction. In this specific example I'm using a RVT101HVBFWCA0, setup with the parameters described in their datasheet. I've attached a couple of photos, but what is shown in the "issue" image is not a static display, it causes a strong flicker and it corrupts sections of the screen (part of what is shown appears to be the blue boot-up screen that precedes this one). Also do note that the co-processor is not crashing in this instance, if I move to another screen it is displayed as it should (though the flickering does persist until a reboot).

Here's an example list that gives me the issue:

cmd32( CMD_DLSTART )
cmd32( ( DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG ) )
cmd_Do_gradient(0, 0, color1, 1280, 800, color2) // x1, y1, color, x2, y2, color
cmd32( (DL_COLOR_RGB | 0xFFFFFF ) )
cmd_Set_ForeGround_Color(color3)

cmd_Do_Button(100, 120, 530, 80, 28, 0, "testing") // x, y, w, h, font, options, string
cmd_Do_Button(100, 205, 530, 80, 28, 0, "testing")
cmd_Do_Button(100, 290, 530, 80, 28, 0, "testing")
cmd_Do_Button(100, 375, 530, 80, 28, 0, "testing")
cmd_Do_Button(100, 460, 530, 80, 28, 0, "testing")
cmd_Do_Button(100, 545, 530, 80, 28, 0, "testing")

cmd_Do_Button(650, 120, 530, 80, 28, 0, "testing")
cmd_Do_Button(650, 205, 530, 80, 28, 0, "testing")
cmd_Do_Button(650, 290, 530, 80, 28, 0, "testing")
cmd_Do_Button(650, 375, 530, 80, 28, 0, "testing")
cmd_Do_Button(650, 460, 530, 80, 28, 0, "testing")
cmd_Do_Button(650, 545, 530, 80, 28, 0, "testing")

cmd_Do_Button(430,740,120,52,28,0,"")
     
     
cmd_Do_Button(200,590,400,80,28,0,"testing") // issue
//cmd_Do_Button(200,600,400,80,28,0,"testing") // no issue


That small change in the final button causes the issue to appear or not. Please note that in this particular case the issue seems to be related to button overlap, but I had the same happen in other situations (where the list was a bit more complex, with some scissors and a couple of gradients) without any overlap of any elements.
We've had similar lists on the FT810 screens without issue, though those were of course on smaller screens with lower resolutions as well.