BRT Community

Hi Rudolph,

We use an HDMI to LVDS board here for testing too, you can find details of the board that we use in chapter 9 of this new application note below,

https://brtchip.com/wp-content/uploads/2025/06/BRT_AN_092-BT820-Hardware-Design-Example.pdf

You can use a camera with HDMI output or even a laptop with HDMI monitor output to input video to the BT820B,

Best Regards, BRT Community

Hi Maria,

To get your touch working, we recommend to use the CMD_SETROTATE instead of the register write. The command writes the REG_ROTATE register for you but also does the touch rotation.

If you calibrate your touchscreen after start-up and then use the command, this will rotate your touch as well as your graphics, and so the touch will work well across the full screen.


Best Regards, BRT Community



 

Hi Rudolph, Maria,
 
Thanks for your inputs on these items, please note that there will be some integrated modules coming soon for BT820B and so we'll keep you posted here.
 
Hi Matrix Orbital,
 
We have to say, the ability to make a stunning full-colour touch-enabled GUI on an LVDS 15.6" panel with high-resolution images and fonts, touch icons overlaid and live video (with pre-processing) driven by some very cost-effective MCUs is really quite impressive.
 
Our new BT820B combines the many benefits of our earlier EVE devices (including their graphics, touch and audio capability) with even more powerful graphics capabilities.
- Directly drive large LVDS panels up to 1920 x 1200 e.g. 15.6" panels
- Use high-resolution live video in your UI easily, and without it passing through the MCU
- Pre-processing to add effects and improve the video stream without MCU workload
- The ability to render very complex graphics by combining the above with a frame buffer
- and many more...
 
These make the BT820B ideal for all kinds of products and applications embracing the latest UI trends including large hi-res displays, more complex UIs with lots of waveforms and controls, and in some cases live video etc.   The BT820B is therefore ideal for both new product designs and existing EVE designs being updated.

Best Regards, BRT Community

Hi Nick,

Great to hear that you have your PCB designed.

There are a few different development approaches that you can use.

EVE Screen Designer will allow you to lay out the user interface via the drag-and-drop editor. The latest ESD versions have STM32 CUBE IDE export also included and so you can choose the STM32 as the platform in ESD. You can then export to an STM32 CUBE IDE project via the menu and then build on CUE IDE. ESD also includes the flowchart based programming of the application flow. For this reason, the ESD project typically runs on the MCU as the main program loop and interaction with other I/O on the MCU can for example be added via User code in ESD. One example is the Blink LED via GPIO example where a GPIO on the MCU is controlled and the usercode example.

Another option is a code-based solution such as our code examples from https://github.com/Bridgetek/ or Rudolph's library. If you require a lot of editing on a pixel by pixel basis this may be a good solution. You can update things like raw bitmaps in RAM_G and they will be reflected on the screen. We also have different bitmap formats such as the bargraph type which may be useful. For the code-based solution, you can also use EVE Screen Editor to lay out your user interface, and then copy the list of commands into your code and this will make the layout easier.

What kind of spectrograms and graphs will you be using, and we can see if we have any examples for either ESD or for a code-based application?

Best Regards, BRT Community

Hello Rudolph,

Thank you for this!

We have a Seleae Logic analyser here in the office so we will try out these high level analysers when we get a chance!
In any case these look really useful for any EVE users debugging needs.

Best Regards,
BRT Community

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

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

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

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

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

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

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

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

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

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