BRT Community

Both the NHD-7.0-800480AF-LSXP-CTP and the RVT70HSLNWC00 should work.

Adapting either of these to the VM820C is a bit of a challenge though.
The 30-position 2mm header CN2 on the VM820C has no pins for the backlight-LEDs.
And the pins for the backlight-controller on the VM820C are only connected to CN4.

The 45-postion FFC header CN4 is not compatible with the display connectors and is missing a couple of signals, so you need an adapter board to connect to either of these.

Connecting to the NHD-7.0-800480AF-LSXP-CTP might be a bit easier as it does not require VGL and VGH signals, but the RVT70HSLNWC00 does.

Both display have a 40pin FFC connector and the pinout is almost the same.
The NHD-7.0-800480AF-LSXP-CTP however deviates a little from one of the de-facto standard pinouts and has LED-K on pins 36/37 instead of 31/32.

The RVT70HSLNWC00 could be connected to a PCB800182 LCD adapter which I also used to connected my 1024x600 7" to, I reverse-engineered these adapters here: https://github.com/RudolphRiedel/PCB800182_LCD_Adapter
See above in this thread, I ended up not using the backlight-controller on the VM820C.

Now for the touch controller, both should work with the BT820, logically.
However, the NHD-7.0-800480AF-LSXP-CTP is using a 6-pin FFC that is not compatible with CN9 on the VM820C.
And RVT70HSLNWC00 uses a 10-pin FFC.
-> you need adapter boards to connect to either CN9 on the VM820C, or, what I found easier to do, connect to CN8 on the VM820C with wires using a cheap generic FFC breakout board on the display side.


Yeah, I wonder what the holdup is, I would be in the market for a fully integrated BT820 display module.

Good morning:

I am beginning to investigate the BT820 to change the micros that we have ft-813 and bt817, found the vm820c development board, the only thing that today not found a screen that can connect, I could give me examples I would be interested to start one in 7 "but if there is not and there is 10" there would be no problem.

Edition: I found by researching a little on my own that these two models could be compatible:

1.- RIVERDI/SOMLABS SL-TFT7-TP-600-1024-LVDS
2.- NEW HAVEN NHD-7.0-800480AF-LSXP-CTP

If they are really compatible, could you please specify which one would be better.

Thank you very much

Translated with DeepL.com (free version)

Hi,

I've a GUI design created in ESD which I'm targeting on my STM32H7 board using FT813. I've run into a few questions on target that are causing problems.

1. I have a custom widget+actor using a Scroll Layout with Scissor enabled. The wanted effect is animated opening of a side window (think of a drop-down menu on many PC apps). This works well in ESD simulator, but using generated & exported code on target the appearance is different. My question: if I put a Linear Layout within Scroll Layout and enable Scissor in the Scroll, how does scissoring work for the nested Linear Layout?

2. Related to the above, my general question is how do scissor/clip and overflow work in a HIERARCHICAL sense?  So far, I have seen that overflow and clip appear to make no difference to anything and I can't understand how these are supposed to work when apparently scissor is the accepted way to actually implement clipping?

3. On another topic, regarding asset loading. As a simple way to avoid the need for FATFS (which I'm using for other things), I have a plan to modify the HAL-abstraced FATFS file loader to return const initialised data, with a few .astc files defined as hex binary data there. In this case presumably I only need to convert the raw .astc to hex and can skip the generation of flash-initialisation .bin files? I think this should work - but have I missed anything?

Thanks in advance,
Nick

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