Quote from: Rudolph on April 16, 2025, 10:03:16 PM
I am trying out the SD card functions now and just successfully used CMD_FSDIR.

CMD_FSDIR "only" returns a bunch of names.
How can I find out which of these names are directories?

Hi Rudolph,

One way to check is to perform a cmd_fssize.  Directories will return -1 for the size.
We'll add that as a note in the document too,

Hope that helps,

Best Regards, BRT Community

Hi Rudolph,

Thanks for your suggestion, we'll pass that back to our R&D team and get their feedback,

Best Regards, BRT Community

Quote from: Rudolph on April 15, 2025, 03:17:21 PM
I just implemented CMD_RESULT and had an idea.

The register region has room for over 2100 registers in the BT820.
Documented are 155 right now and regardless of how many register are undocumented, it should be highly unlikely that
there are not plenty of unused slots.

Can we please reserve a bunch and name them like REG_USER0 to REG_USER9?

Why?
Because CMD_RESULT(REG_USER0) would be nicer than needing to find places in the memory map over and over again.

I am trying out the SD card functions now and just successfully used CMD_FSDIR.

CMD_FSDIR "only" returns a bunch of names.
How can I find out which of these names are directories?

Edit: I implemented CMD_FSSIZE and the number returned for directories is 0xffffffff.
Well, yes, that matches the description of CMD_FSSIZE, that entry is not a file, so no file of that name was found.
And consequently CMD_FSREAD and CMD_FSSOURCE return 2 on folders for file-not-found.

So when the name is returned by CMD_FSDIR and CMD_FSSOURCE returns 2, then it is a folder.

I just added the functions for CMD_RESTORECONTEXT and CMD_SAVECONTEXT.
And I do not get it, what was the point of adding these as commands to the co-processor?

SAVE_CONTEXT and RESTORE_CONTEXT are display-list commands that were introduced with the FT800, IDs 0x22 and 0x23.
And executing these with the co-processor, like the rest of the display-list commands, never was an issue.

So instead of having the co-processor just copy over the commands to the display-list it now has to exectute the
command to write the same values to the display-list.
This really strikes me as weird.
And then these were the only display-list commands that got that privilege to be elevated to co-processor commands.

I just implemented CMD_RESULT and had an idea.

The register region has room for over 2100 registers in the BT820.
Documented are 155 right now and regardless of how many register are undocumented, it should be highly unlikely that
there are not plenty of unused slots.

Can we please reserve a bunch and name them like REG_USER0 to REG_USER9?

Why?
Because CMD_RESULT(REG_USER0) would be nicer than needing to find places in the memory map over and over again.

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

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.

The picture is nice and stable, yes, I started to implement the new commands for the BT820. 

But I currently have an issue that I can not explain.
First I noticed that I need to place additional VERTEX_FORMAT(0) in my display list, somehow the setting is not persistent.
Then I noticed that the back-to-back CMD_TEXT in the snippet I am using with CMD_APPEND no longer work, only the first line is displayed.
And when checking with the logic analyzer I found that a single CMD_TEXT is keeping the command-co-pro busy for an unusual amount of time, like there is some issue.
When I interleave the CMD_TEXT with COLOR_RGB then all the lines are displayed, the co-pro still is busy with this for quite a while though.

Choosing the less complicated CMD_NUMBER I get the same:

EVE_cmd_dlstart();
EVE_color_rgb(BLACK);
EVE_cmd_number(10, 515, 26, 0, 12345);
EVE_cmd_number(10, 500, 26, 0, 12345);
EVE_execute_cmd();

Followed by:
num_dl_static = EVE_memRead16(REG_CMD_DL);
EVE_cmd_memcpy(MEM_DL_STATIC, EVE_RAM_DL, num_dl_static);

The result right now is that the second line is not completely displayed.
When I switch the order of the lines, the other one gets incorrectly displayed.

When I throw in an extra EVE_color_rgb(BLACK); between the two CMD_NUMBER, then both lines are displayed.
When I use a NOP one of the lines still get corrupted.

The resulting sequence for EVE_cmd_number(10, 515, 26, 0, 12345); is:
0xff 0x01 0x00 0x00 - write + REG_CMDB_WRITE
0x2a 0xff 0xff 0xff - CMD_NUMBER
0x0a 0x00 0x03 0x02 - x = 10, y = 515
0x1a 0x00 0x00 0x00 - font = 26, options = 0
0x39 0x30 0x00 0x00 - number = 12345

I still need to read out the resulting display list snippet and analyze it, but right now I do not see anything wrong with my code.

Hmm, I added the lines with x=110 to the main display list and also made the list use separate commands instead of using DMA,
the two lines are displayed just fine.
Then I checked my implementation of CMD_APPEND, nothing there, changed the target address for the snippet, no change.

Looks like the co-processor does not like to put commands in a display list anymore that is not meant to be displayed on it's own?
There is no CLEAR_COLOR_RGB or CLEAR for the snippet, as this is in the main display list.


Edit: I just modified my code to use CMD_NEWLIST/CMD_ENDLIST/CMD_CALLLIST which just stores the co-processor command instead of executing them.
And this works just fine, when executed in the context of the display list, both lines for CMD_NUMBER are displayed correctly.

After restoring the rest of my original code everything is executed as it should, I even can remove the two extra VERTEX_FORMAT(0) lines that
were necessary before.
I noticed in ESE that both CMD_NUMBER and CMD_TEXT switch to use SAVE_CONTEXT / VERTEX_FORMAT(2) when going beyond 511 on the B817/BT818.
And with the BT820 SAVE_CONTEXT is replaced with REGION.
Oh wait, that is the issue, the destination in REGION is absolute, not relative, so with CMD_APPEND destinations are pointing to the wrong address in the display list.

At least there is a workaround, although it is exclusive to BT817/BT818/BT820.
Makes me again wonder why VERTEX_FORMAT(0) is not just the default.

Additionally I found that CMD_NEWLIST is not finishing on it's own, REG_CMDB_SPACE never indicates that the FIFO is empty.
Only after I removed the busy check things worked.
This behaviour is not documented and something I should try on the BT817.

Hi Rudolph,

Congratulations on getting the BT810B up and running on your board !
Glad to hear that you found the cause of the issue with the contact side on the touch connector already and that it's working well now.

Is your picture nice and stable now on the display too?
We'll check the definitions of the REG_LVDSTX_PLLCFG in the guide.

Best Regards, BRT Community

How do I use the touch engine?
As far as I understand it, setting bit 6 in SETBOOTCFG should be enough, this should enable the touch system and
during boot the touch system should do an auto-discovery to determine the touch controller connected.

My LCD does have a FT5316 and after connecting it to the VM820C it does nothing at all.
Reading REG_TOUCH_CONFIG returns 0x00000000, writing 0 or 0x381 does nothing either.

I can not calibrate and reading REG_TOUCH_RAW_XY returns 0xFFFFFFFF.

It should not be necessary to setup CTP_SCL/GPIO5, CPT_SDA/GPIO6, CTP_INT/GPIO7 or CTP_RST/GPIO8 in order to use the touch engine.
But then I can not find how to actually set this up anyways, how to configure them for alternate function or GPIO.

Edit: I soldered pins and to the FFC adapter I am using for the touch controller and looking at SCL, SDA and Reset with the logic analyzer.
And while the pins wiggle like expected for their function, the touch controller does not seem to answer.

What is odd though, when I write 0x381UL to REG_TOUCH_CONFIG to setup a FocalTech device, the lines are just dead.
SCL is Low - really odd for an open collector ouput with pullup-resistor, SDA and Reset are high.

When I write 0x380UL to REG_TOUCH_CONFIG, which should not do much according to the register description,
apparently auto discovery is triggered, Reset is pulled low, then there is a pause and then there is one or two byte transfers on SCL/SDA.
Same thing happens when not writing to REG_TOUCH_CONFIG or when writing 0.

Oddly I also see 311ms periods with SCL just low like this, even when I disconnect the CTP.

Maybe my touch controller is toast, but what the BT820 does is not looking correct either.

Looks like I need to check the touch controller with an Arduino, there was some I2C scan sketch somewhere.
Edit: I did just that, I have an Arduino UNO running at 3.3V with 4k7 pullup resistors to 3.3V scan the I2C right now, connected to the CTP of the display as written on it's FFC cable: 1 = GND, 2 = SDA, 3 = SCL, 7 = VDD - and nothing is found.
Strange.


Edit: I found the issue, I do have working touch now. 

The connector on the 10pin FFC adapter board I am using looks like is contacting on both sides of the cable,
but it definately is only contacting on the bottom side.
The cable for the CTP has the contacts on the top side...

Have two fotos to celebrate. :-)
Yes, I noticed that the backlight is a bit dim, but I can't control it by software and only set it to 20mA, maybe I'll add another resistor in parallel later.


Edit: I just put up a repository with the information from reverse engineering this display adapter: https://github.com/RudolphRiedel/PCB800182_LCD_Adapter