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

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.

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

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