Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[m.tele]

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:

Code: [Select]

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.

[BRT Community]

Hello,

Thank you for your post.


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?

Best Regards,
BRT Community

[Rudolph]

I tried this with my library which does set 72MHz pixel clock for the RVT101 and also is setting REG_PCLK_2X.
And while I also saw this fail, the real killer seems to be CMD_GRADIENT in this case.

Without the CMD_GRADIENT line I can display all the buttons and even four more without an issue.
Ok, the display-list is filled by more than half then.

[m.tele]

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.

[Rudolph]

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.

[m.tele]

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.

[BRT Community]

Hello,

Thank you for the update!

I'm glad to hear that adjusting the REG_AH_HCYCLE_MAX registers has helped in this instance.
Please let us know if you have any further questions.

Best Regards,
BRT Community