BRT Community

polo? 

test

Ok, with the post from marketing, I kind of have to ask. :-)

I saw the IDM2040-21R a while ago and found it interesting.
Round, IPS, capacitive touch, rotary dial.

A bit too small for me, 2,1" is 53mm in diameter, but unfortunately this seems to be the upper end of round displays.
I also found 3.4", but only with MIPI DSI.

However, the FT800 puzzles me.
Why does the IDM2040-21R use a FT800?
The FT800 does not even use capacitive touch, it is the resitive touch variant, so the firmware needs to be patched. Why not use a FT801?

And then, why not use a BT881?
The FT800 could be used with I2C instead of SPI, but it is connected by SPI on the IDM2040-21R.
The BT881 would be a drop-in replacement with GPIO2 on pin 10 instead of MODE.


And personally, the RP2040 is a bit of an odd choice for me.
This controller has close to nothing that would make it exciting, except maybe, the PIOs which are not used here.
And so the IDM2040-21R has I2C or RS485 as communication interface and neither would the interface I would choose to run things thru my home.
Ah yes, there is USB, but that is an even worse fit for home automation.

I would rather go for a small controller that has a CAN-FD interface, like an ATSAMC21E - which could also do RS485 and I2C.
Or use an ESP32 and add WLAN, but you need to run a cable to the unit anyways and there are already enough things in our homes sending out radio waves.

A modular approach with a second PCB on top of the EVE PCB would help with size limitations.
And would not only make more room for more features, but also would add the flexibility to use different controller boards.

Hi BRT Community,

Many thanks for your reply. I'm not sure how to upload pictures in order to show some example views that I'm aiming for, so I'll try to explain as briefly as I can.

My spectrogram data arrives at the GUI (software) as a vector of 128 pixel values - i.e. 128 different colour values, where this vector is updated at a rate of about 100 Hz. This is obviously faster than the supported frame rate, so my software will need to lower the rate, which I can do by grouping the data into chunks of 5 (columns) x 128 (rows) at 100/5 = 20 Hz. So the challenge is then to left-shift the current bitmap left by 5 columns, discarding the left-most 5 columns and filling the 5 right-most columns with my new data. The aim is a view that scrolls from right to left in real time. Given a width of 800 pixels and 100 columns per second, the view should hold 8 seconds of data at any instant. I have this working already on a very simple SPI display (128x240) using the ST7735 controller chip.

I have another type of view in which I'd like to update an entire bitmap, of roughly 256x256 pixels, at the full frame rate.

Just to make things more interesting, I would also like the above two to be supported concurrently.

I've been reading deeper into the ESD User Guide and have looked at more of the examples and I'm beginning to think that your suggestion of using a primarily code-based approach is going to work best. I find the logic flow way of "coding" quite confusing without having a good grip on all the tricks that are no doubt there, but not so easy to find when scrolling the library tree.

All that I really need, I think, is a top level screen that has a menu button at top left. I want to touch that and have a panel grow (animated over a few hundred ms) to reveal half a dozen further menu buttons and maybe some checkboxes. I then want those revealed buttons to enable about 4 different views on the main page: two of those views I've already mentioned, the third is just an panel where I want to print some text and the 4th is a floating widget very much like a compact audio-recorder (stop/pause/play buttons+progress bar). If I can create the basic containers and this menu animation in ESD, then perhaps everything else can be done in pure C code as you've suggested?

I tried to adapt one of the examples to animate the transition from one page to another, as a crude attempt to achieve the animation mentioned above, but so far this isn't working. The Animation example using Actor generation uses a lot of logic to do what seems to me a really simple thing?

Thanks again and any further advice would be great.

*STOP PRESS* I just got a linear-layout with buttons opening in animated fashion! I guess that animated page transitions may not be supported, whereas to achieve the same using layouts is the right approach?..

Nick

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

Hi,

Following on from my introduction here a few months ago, I've now completed my STM32H755 PCB design (and bringup) and I want to start on the GUI development. My display is a Riverdi 800x480 capacitive touch with FT813 and I'm using SPI (1).

I've gone through several of the ESD tutorial videos on YouTube and have been looking at the documents. There's a lot of information to digest and without reading a lot more than I have already I'm not really getting the confidence that I want to know that I'm going in the right direction.

Firstly, my target platform is a custom PCB using STM32H7 with the display and EVE chip mentioned above. ESD wants me to define several aspects of my h/w: host processor, EVE platform, Flash memory etc.. whereas the only thing that seems relevant to me is that I'm using FT813 and I see now way to select a configuration that correlates well with my hardware. Should I worry about this? May I find in future that I can't generate code for my platform?

Secondly, is ESD the best place to start with my GUI, or should I firstly use ESE? I know what I want to implement and don't particularly feel the need to prototype screen layouts. I suppose I'm still unclear about how ESE fits into the development process.

In what I've read so far, the ESD tutorials and examples seem self contained and with no data input/output to/from the host applications. A key requirement of my system is to show real-time views of spectrograms 2D heat maps, so frame-by-frame updates of charts and bit-maps will be needed. Are there any examples that show these kind of data interactions with the GUI?

My overall impression is that GUI dev with the EVE tools that I've seen is quite far from my past experience of WYSIWYG design, with a considerably steeper learning curve. Any tips on how best to get up that curve would be very much appreciated.

Thanks in advance,
Nick

I implemented High Level Analyzers for Saleae Logic 2: https://github.com/RudolphRiedel/Saleae_Logic_HLA
There are two variants, EmbeddedVideoEngine is for FT81x/BT81x and EmbeddedVideoEngine5 is for BT820.

Not perfect or complete, but well, it decodes some stuff, when saving the .csv from the trace I get extra data like this for BT820:

BOOTCFGEN   
SETTBOOTCFG   
SETDDRTYPE   
BOOTCFGEN   
SETPLLSP1   
SETSYSCLKDIV   
ACTIVE   
READ REG_BOOT_STATUS   Decompressing rom asset image to DDR
READ REG_BOOT_STATUS   Attempting to attach to flash
READ REG_BOOT_STATUS   Normal running
WRITE REG_PWM_DUTY   0x00000020
WRITE REG_HSIZE   0x00000400
WRITE REG_DISP   0x00000001
WRITE RAM-DL+0x0000   DL_CLEAR_COLOR_RGB  0x000000
WRITE RAM-DL+0x0004   DL_CLEAR  0x000007
WRITE RAM-DL+0x0008   DL_DISPLAY  0x000000
WRITE REG_DLSWAP   0x00000002
WRITE REG_SO_EN   0x00000001
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_INFLATE
WRITE REG_CMDB_WRITE   0xD8E5DA78
READ REG_CMDB_SPACE   0x3F6C
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_LOADIMAGE
WRITE REG_CMDB_WRITE   0xE0FFD8FF
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_NEWLIST
WRITE REG_CMDB_WRITE   DL_TAG  0x000000

BRT_AN_086_BT82X-Series-Programming-Guide is out in version 1.1 and I am going over it now.

Here are my observations:

1) The memory region RAM_ERR_REPORT was renamed to RAM_REPORT.

2) The "BT82X data flow" was updated and one detail is that RAM_CMD and RAM_DL are documented to use SRAM.
Which has no user-level implications, but makes me wonder if the whole region from 0x7F000000 to wherever is SRAM.

3) RAM_G is documented to go from 0x00000000 to 0x7EFFFFFF, DDR3 "only" goes to 8Gbit, so RAM_G can "only" go to 0x3FFFFFFF.
4) Host command RESET_PULSE was added.

5) The Initialization Sequence given in the programming guide is different to what the Bridgtek examples are using.
https://github.com/Bridgetek/Eve-MCU-Dev/tree/bt82x-dev
https://github.com/Bridgetek/python-bt82x-dev/tree/development

Not fundamentally, but this is still a bit strange.

from EVE_HAL.c:

// Reset the display
MCU_Delay_20ms();
HAL_PowerDown(1);
MCU_Delay_20ms();
HAL_PowerDown(0);
MCU_Delay_20ms();

// Set System PLL NS = 15 for 576MHz
HAL_HostCmdWrite(0xFF, 0xE4, 0x0F, 0x00, 0x00);
// Set System clock divider to 0x17 for 72MHz
HAL_HostCmdWrite(0xFF, 0xE6, 0x17, 0x00, 0x00);
// Set bypass BOOT_BYPASS_OTP, DDRTYPT_BYPASS_OTP and set BootCfgEn
HAL_HostCmdWrite(0xFF, 0xE9, 0xe1, 0x00, 0x00);
// Set DDR Type - 1333, DDR3L, 4096
HAL_HostCmdWrite(0xFF, 0xEB, 0x08, 0x00, 0x00);
// Set DDR, JT, AUD and WD in Boot Control
HAL_HostCmdWrite(0xFF, 0xE8, 0xf0, 0x00, 0x00);
// Clear BootCfgEn
HAL_HostCmdWrite(0xFF, 0xE9, 0xe0, 0x00, 0x00);
// Perform a reset pulse
HAL_HostCmdWrite(0xFF, 0xE7, 0x00, 0x00, 0x00) ;
// Set ACTIVE
HAL_HostCmdWrite(0x00, 0x00, 0x00, 0x00, 0x00) ;

// Delay ~100 mS
for (i = 0; i < 5; i++)
{
    MCU_Delay_20ms();
}


The order should not really matter, but I do wonder why RESET_PULSE is in there and why it is placed directly before ACTIVE.

6) REG_LVDSTX_PLLCFG
Following the updated register description for REG_LVDSTX_PLLCFG my code works now.
LVDSPLL_NS went from "Progammable loop divider" to RESERVED with a fixed value of 7, whatever this actually does.
And "Table 21 - LVDSTX Clock Configuration" also has "(scanclk_2x / 2)" under "LVDSTX clock (MHz)".

So, the multiplier is actually the system-pll multiplier which means that for the pixel clock you can only setup 576MHz / (TXLDVIV + 1) - unless you change the system-pll multiplier.
That is pretty bad in regards of the resolution of the pixel-clock, especially after the BT817.
The target for the 1024x600 I am currently using is 51.2MHz with min = 45MHz and max = 57MHz.
And practically the only options are 48MHz or 57.6MHz, as I really do not like the idea of lowering the system clock.
800x480: >25.2/25.4/37.2MHz -> set TXCLKDIV = 10 for 26.2MHz
800x480: >23/25/27MHz -> set TXCLKDIV = 11 for 24MHz
1024x600: >45/51.2/<57 MHz -> 48MHz
1024x768: >52/65/<71 MHz -> 57.6Mhz
1280x720: >57.1/58.1/85MHz -> 57.6MHz or 72MHz
1280x768: >55/60/<65 -> 57.6MHz
1280x800: >66.3/72.4/78.9 MHz -> 72MHz
1366x768: >66.9/72/<80 MHz -> 72MHz
1366x768: >63/76/<96 MHz -> 72MHz

Ok, getting these to work would not be an issue, only hitting 60Hz might.
And no, I do not have these, sourcing inexpensive displays with touch is still a major pain.

7) REG_TOUCH_MODE was removed from the Programming Guide
8 ) Microchip and TI touch controllers were removed from REG_TOUCH_CONFIG
9) REG_CTOUCH_TOUCHn_XY registers are still named 0/A/B/C/4 and not 0/1/2/3/4.
10) new register: REG_LVDSRX_CORE_FRAMES - LVDSRX frame counter - 8 bit value
11) REG_SYS_STAT had bit definitions removed
12) REG_I2S_CFG definition has LENGTH removed, 16-bit is the only supported format
13) REG_GPIO_DIR Bit 15 – 9 changed from "Unused" to "These bits control the direction of GPIO8 to GPIO15." -probably was meant to say GPIO9 to GPIO15
14) REG_GPIO Definition Bit 15 – 9 changed from "Unused" to "General purpose Input/Output pins"
15) The description for REGION has been greatly improved, but there still is no warning that the "dest" parameter is absolute which prevents display list fragments that were built from commands like CMD_TEXT to be used with CMD_APPEND since the translation to display list commands by the co-processor uses REGION for a couple commands now and the generated snippet is very unlikely to be placed at the exaxt same display list address.
16) the C prototypes of several commands are still wrong and use int16_t instead of uint16_t for parameters like width, height, radius and font which must not be negative
17)  the C prototype of CMD_TEXTDIM still has this: void cmd_text( uint32_t dimensions ...
18 ) I only briefly checked this, but it looks like the inconsistencies I reported here: http://www.brtcommunity.com/index.php?topic=585.0 are still in place


Oh yes, what I did not mention so far is that there are indeed numerous improvements in the 1.1 version of the BT82x programming guide.
For example the explanation of the Swap Chains.