Hello,

Thank you for your query.

The following link will take you to the BT81X Series Programming Guide: https://brtchip.com/wp-content/uploads/2021/09/BRT_AN_033_BT81X-Series-Programming-Guide.pdf.

In this guide, section 2 contains information on startup. Please take a look at section 2.4 in particular as it describes the initialization sequence during boot up.

If you need any more information please get in touch.

Best regards

BRT Community

Hi JuSil,

You can also put the image into flash with the EVE Screen Editor and so that might be worth trying

If it also gives the lines in ESE when you output to the module, could you send us a copy of the image and we can try it,

EVE4 also has a few features which can help to give more time for the display lines to be rendered. Please see page 51 of the Programmers guide:
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf

- Adaptive Frame rate varies the PCLK to allow more time for the screen to be rendered in cases where there are a lot of items to render. however, it is for RGB panels only and not all panels support it. Therefore, you could check this is off,

- REG_AH_HCYCLE_MAX is a new feature in BT817/8 which instead extends the HCYCLE value in cases where there are too many items to render in the time available (e.g. how much time one row has based on PCLK and number of pixels in a row). You could try this to see if allowing EVE to extend the HCYCLE time helps.

- There is also REG_UNDERRUN which allows you to check if the underrun is occurring and if so the REG_AH_HCYCLE_MAX may help.

If it works from RAM, it sounds like the image data being read from flash is slowing down the rendering. You could check that the BLOB is loaded and that the flash is in full speed mode. Also, if you try a lower quality conversion of the same image this may help to confirm if the issue is related to this.

For flash programming, please ensure that your module gets sufficient power from the USB adapter  as if the voltage to EVE or the flash droops, you get communication errors. Also, make sure all of the SPI cables are well connected and are as short as possible to avoid any signal quality issues.

Best Regards, BRT Community

Hi,

Glad to hear that you have resolved it,

You can store the calibration values in your MCU's Flash/EEPROM by running a calibration and once successfully completed, store the six REG_TOUCH_TRANSFORM values in your MCU and then re-write them back on each start-up.

It is worth including a way to force a re-calibration too when doing this (via a button on the screen, or by holding a touch on power-up, or by a physical button on your PCB if you prefer not to have an on-screen way of triggering it)

Best Regards, BRT Community

Hello Mathieu,

It would be best to contact support with an email so we can better assist you on this issue as there is quite a lot of information to send.

Please use this link to find the support team's email address: https://brtchip.com/contact-us/

Best regards,

BRT Community

Hello,

The following code will draw the desired circle with the line through it,

BEGIN(LINES)
LINE_WIDTH(48)
COLOR_RGB(0x0, 0xFF, 0xFF)
VERTEX2F(1688, 1384)
VERTEX2F(4768, 5056)
END()

BEGIN(POINTS)


CLEAR_COLOR_A(0)
COLOR_MASK(0, 0, 0, 1)

BLEND_FUNC(ONE, ONE_MINUS_SRC_ALPHA)
POINT_SIZE(1600)
VERTEX2F(3200, 3200)

BLEND_FUNC(ZERO, ONE_MINUS_SRC_ALPHA)
POINT_SIZE(1520)
VERTEX2F(3200, 3200)

COLOR_MASK(1, 1, 1, 0)

BLEND_FUNC(DST_ALPHA, ONE)
COLOR_RGB(3, 182, 0)
POINT_SIZE(1600)
VERTEX2F(3200, 3200)
BLEND_FUNC(SRC_ALPHA, ONE_MINUS_SRC_ALPHA)

END()

However after some investigation it appears as if the CLEAR_COLOR_RGB command is causing the behaviour you are seeing where the circle isn't being drawn. For example if you alter this to black or red the circle is drawn correctly. I believe this sample was designed only to utilise a black background, but I will confirm this with the development team, and in the meantime investigate a solution to this issue.

Best Regards,
BRT Community

Hello,

I've chased the developers up on this to see if we can make it happen.

I would like to second the vote on upping the font size, I know that would be helpful for my project, thank you!

T

Best Regards,
BRT Community

Hello,

We only provide the toolchain for Windows.

However we have heard other customers having the tools compiled for both mac and linux, and everything is functioning just fine.
This is because the tools used are open source.

See AN 325 FT9xx Toolchain Installation Guide for more information.

The only issue is programming the part.
You can, of course, use the open-source dfu-util to program the part, however if you end up breaking dfu mode, you have to use windows to recover with the one-wire programmer (FT900Prog.exe).
Your application code should have a DFU interface included if you want to use that. DFU is good for in-field updates but not during the development phase. See the GPIO DFU Example in AN_360 for reference.

So unfortunately we can’t support the toolchain on anything other than Windows.

Best Regards,
BRT Community

Hello,

Thank you for your question.

Unfortunately there isn't any functionality within the touch registers on EVE that would denote a 'hold' at a specific touch location on the screen or tagged object.
This functionality would need to be implemented in your MCU code, for example your touch routine would need to determine if first, a touch has occurred, then if the touch is on a tagged object, then you check that within a given time period that the REG_TOUCH_TAG register is still reporting the same value, to establish if a 'hold' has occurred.

Best Regards,
BRT Community