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 ... 56
1
Discussion - EVE / Re: API function requirements
« on: June 09, 2025, 05:02:28 PM »
Hello,

Thank you for your post.

I will enquire with the software team to see if they have a document which covers the C prototypes for each support EVE command.

Best Regards,
BRT Community

2
Hello,

we’d like to offer the following explanations and suggestions:
1. Mismatch in RGB Bit Depth (OUTBITS Setting)
Some LCD panels, although labeled as supporting RGB888 (24-bit), may internally operate using RGB666 (18-bit). If the EVE IC’s output bit setting does not match the actual bit depth supported by the display, it can lead to color distortion or visual artifacts such as noise lines.
Suggestion:
Please verify your LCD panel’s actual color depth and ensure that the REG_OUTBITS register is configured appropriately during initialization to match the panel.

2. Avoid Using CMD_GRADIENT for Red-Sensitive Precision Areas
CMD_GRADIENT uses internal linear interpolation. In high-contrast or precision-sensitive areas—such as gradients involving red—it is prone to rounding errors that may cause visible banding or fine lines.
Suggestion:
Consider using a custom gradient image (bitmap) instead, and load it into RAM or flash to ensure consistent rendering and avoid interpolation artifacts.

3. Fine-Tune the Gradient End Color & Refresh the Cache
Using red values like 0xFF0000 (full red) can fall on edge-case transitions in RGB666 mode, leading to visual inconsistencies.
Suggestion:
Try slightly dimming the gradient end color—for example, use 0xF00000 instead of 0xFF0000—and observe whether the black line still appears.
Also, try calling CMD_CLEARCACHE() to clear the on-chip bitmap cache, which may help eliminate any residual rendering artifacts.

Best Regards,
BRT Community

3
Discussion - EVE / Re: BT82x
« on: May 27, 2025, 05:53:25 PM »
Hi Rudolph,

Sorry for the delayed reply, Our new Programmers guide will be ready soon,

You are correct, the LVDS output is for one display only. We use two channels to allow us to support the high resolution panels such as 1920 x 1200, but the two channels work together to provide the bandwidth required. Therefore, they are not designed to support two separate display panels on one BT820B IC.

Best Regards, BRT Community



4
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

5
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

6
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

7
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

8
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

9
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


10
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


11
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.

12
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

13
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

14
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

15
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

Pages: [1] 2 3 ... 56