BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - BRT Community

Pages: [1] 2 3 ... 55
1
Discussion - EVE / Re: Add new platform to ESD
« on: May 08, 2025, 05:35:59 PM »
Hi,

Thanks for your question,

We'll check with our R&D team on this and will let you know as soon as possible,

Best Regards, BRT Community

2
General Discussion / Re: FT813 reporting invalid interrupt flags
« on: May 05, 2025, 10:37:58 AM »
Hello,

Thank you for the update.

In cases where the SPI connection is long and there is no possibility to shorten it significantly, we would normally suggest adjusting the slew rate and drive strength characteristics of the MCU SPI port to help improve transmission quality. But please do keep us updated with how your testing goes.

Best Regards,
BRT Community

3
Discussion - EVE / Re: BT82x
« on: April 30, 2025, 02:44:57 PM »
Hello,

On the programmers guide point, this is currently going through the final review stages and we hope to have it released shortly.

I will follow up with the R&D team for your other queries.

Best Regards,
BRT Community

4
General Discussion / Re: FT813 reporting invalid interrupt flags
« on: April 30, 2025, 10:57:44 AM »
Hello,

Thank you for the update and the details.

I had a quick discussion with the R&D team concerning the operation of the of REG_INT_FLAGS, REG_INT_MASK, and the INT_N pin in general. After viewing the associated microcode I can note that the  REG_INT_FLAGS register is always set by hardware, however, the INT_N pin is only asserted to low when the corresponding bit of REG_INT_MASK is enabled. In this case it may be possible to some values from the REG_INT_FLAGS register that hadn't previously been set in the masking stage.

However, in believe in this case that the 0x4A you are reading from the register should likely be 0x25 (SWAP, TAG, FIFO empty). It is possible that there may be a hardware related issue causing this, one approach would be to test the register reads using a slower SPI clock rate as Rudolph has suggested. But, I would be interested to know in the first instance if the ISR has any bearing on the behaviour you are seeing. Would it be possible to test the ISR where you only perform a read of the REG_INT_FLAGS register on the INT_N pin toggling? and do not service the routine or send any new commands to EVE otherwise. I'm curious to see if the 0x4A register read still occurs in this instance.

Best Regards,
BRT Community

5
General Discussion / Re: FT813 reporting invalid interrupt flags
« on: April 28, 2025, 03:38:29 PM »
Hello,

Thank you for your question.

Can I ask how you have configured the interrupts?

Would it also be possible to provide a logic analyser capture of a read of the flags register when the issue occurs?

The interrupt flags not returning as expected is curious, but it would not be considered a fault scenario on its own.

Just to clarify you would only need to perform a fault recovery if the REG_CMD_READ register reports a value of 0xFFF (indicating a fault in the co-processor). In terms of EVE and the touch engine, the current valid display list contained within RAM_DL, will be read by the touch engine for tagged items, which will then updated the REG_TOUCH_TAG register if an item has been touched accordingly. In this sense as you have noted your screen manager is out of sync with what it believes to be on the screen, what is the mechanism, that you are using to keep track of screens in your application?

Best Regards,
BRT Community

6
Discussion - EVE / Re: BT82x
« on: April 17, 2025, 10:29:13 PM »
Nice work Rudolph! Your application looks great and good to see you've got the SD card running,
Yes, the longer RAM_DL is a nice thing to have on the BT820B to support larger amounts of text etc.

Best Regards, BRT Community


7
Discussion - EVE / Re: BT82x
« on: April 17, 2025, 04:02:25 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


8
Discussion - EVE / Re: BT82x
« on: April 16, 2025, 11:25:04 PM »
Hi Rudolph,

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

Best Regards, BRT Community

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.

9
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

10
Discussion - EVE / Re: BT82x
« on: April 15, 2025, 07:54:15 AM »
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

11
Discussion - EVE / Re: RGB 18 bit interface and BT816
« on: April 11, 2025, 01:48:07 AM »
Hi,
Yes, RGB565 is a commonly used 16-bit image format, but it does result in some loss of color information — especially for neutral tones like grayscale.
This is because RGB565 allocates only 5 bits for red and blue, and 6 bits for green. The imbalance in bit allocation can cause color distortion, which may lead to grayscale areas appearing bluish on the display.
If you want to preserve better color fidelity, we recommend using the ASTC compression format.
You can use our EVE Asset Builder tool to convert images into ASTC format.
For example, using 8×8 ASTC compression typically provides visually good quality while producing a smaller data size than RGB565.


Best Regards, BRT Community

12
Discussion - EVE / Re: RGB 18 bit interface and BT816
« on: April 10, 2025, 03:02:29 AM »
Hi,
Yes, REG_OUTBITS = 0x01B6 is correct for 6 bits per color (R:G:B = 6:6:6).
We recommend connecting your screen's D17–D0 lines to BT816 as follows:
•   D17–D12 → BT816 R7–R2
•   D11–D6 → BT816 G7–G2
•   D5–D0 → BT816 B7–B2
This maps the highest 6 bits of each color output from BT816 to your LCD input, ensuring better color accuracy.

Best Regards, BRT Community

13
Discussion - EVE / Re: BT82x
« on: April 02, 2025, 03:08:13 PM »
Hello Rudolph,

Glad to see you are making progress with your testing!

Please let us know if there are any specific questions you may have concerning the BT820B protocols or if you run into any issues.

Best Regards,
BRT Community

14
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

15
Hello,

Thank you for your patience.

After some further discussion with the development team on this issue, they have confirmed that there is a limitation in the BT81x firmware where the '\n' character cannot be used in conjunction with CMD_FILWIDTH, as the character is counted as having the maximum font width in the conversion.

  • Customers can use the newline ‘\n’ characters to control line break by manually calculating each line pixel width.
  • Customers can also use spacing (space character) to adjust line break when using CMD_FILLWIDTH.

This limitation has been resolved in the BT820B firmware, which includes a new command to calculate the area a input string will occupy in pixels when using CMD_FILWIDTH.

Best Regards,
BRT Community

Pages: [1] 2 3 ... 55