Hello,

Are you performing the flash to RAM_G write for every instance of the display being issued in relation to the RGB565 image?

Have anyone test with EVE4 1024x600 resolution display?

Current, I'm having Tiva with SPI at 16Mhz. What my display doing is load bitmap RGB565 (371x400) from flash to RAM_G, with 3 buttons. The total time it takes about 45ms. I'm not sure why it take that long to display one screen. The worst case can be more.

By that, I only can scan key every 100ms. My code doing is having a flag at 100ms. when flag is set, it scan and display. I can't find any better way to handle display and touch function.

I do feel like the cmd list I send from MCU to EVE4 is fast but the time for EVE4 display on screen is take so long that I can't do same as @Rudolph that scan key for every 5ms and display every 20ms.

I haven't try to use DMA or QSPI yet, but my setup is really simple and it take that long to display so I'm not sure using DMA/SQPI will improve the display time or not.

Best Regards,
BRT Community

OK, this is simple when image has no background...
But what's the way if the image is jpg with a solid (say white/back) color background?

Have anyone test with EVE4 1024x600 resolution display?

Current, I'm having Tiva with SPI at 16Mhz. What my display doing is load bitmap RGB565 (371x400) from flash to RAM_G, with 3 buttons. The total time it takes about 45ms. I'm not sure why it take that long to display one screen. The worst case can be more.

By that, I only can scan key every 100ms. My code doing is having a flag at 100ms. when flag is set, it scan and display. I can't find any better way to handle display and touch function.

I do feel like the cmd list I send from MCU to EVE4 is fast but the time for EVE4 display on screen is take so long that I can't do same as @Rudolph that scan key for every 5ms and display every 20ms.

I haven't try to use DMA or QSPI yet, but my setup is really simple and it take that long to display so I'm not sure using DMA/SQPI will improve the display time or not.

Hello,

Thank you for your question.

It won't be necessary to blend the two images together using the BLEND_FUNC, this is what is causing the image to only show on the darker sections of the back ground image.

You can simply place one image on top of the other so long as the image has an appropriately transparent background, for example the below code places an ASTC image (motorbike) on top of background image:

BITMAP_HANDLE(0)
CMD_SETBITMAP(0, RGB565, 800, 480)
BEGIN(BITMAPS)
VERTEX2F(0, 0)
END()

BITMAP_HANDLE(1)
CMD_SETBITMAP(768000, COMPRESSED_RGBA_ASTC_4x4_KHR, 288, 164)
BEGIN(BITMAPS)
VERTEX2F(6112, 4208)
END()
Please see the attached .png for an example of the above code running in EVE Screen Editor.

Best Regards,
BRT Community

Hi,

I am trying to draw some pictures on another background (white/black color) on another background picture. However I am not able to make the overlaying picture with its background  being transparent.

The closest result I obtain with :
1. draw background image (ACTS),
2. BLEND_FUNC(ONE, ONE)
3. draw overlaying picrute.

But a problem is that the second picture is only visible with some transparency on dark areas of background image.

Can anyone advise how to achieve it?

Thanks in advance

I work currently with the XC16 Compiler from MicroChip on a dsPIC33 within MPLAB X IDE 5.5.

After Rudolph's comment to check the editor for UTF8-mode, i changed my settings from LatinX to UTF8.

But nevertheless, if i don't use encoding like this here, i will have no success:
EVE_cmd_text( 10, 10, 1, 0, "\n\u00A9\u00BA\u00C4\u00D6\u00DC\u00E4\u00F6\u00FC\n   The quick brown fox");

I also opened the related file with another editor and saved it there in UTF8 mode.



Thanks for your assistance!

Hi Craggan,

We have been doing some testing and we were able to see the issue on some compiler platforms, where it seemed to be caused by the encoding.

For example, we can see the issue on Visual Studio but the same string and the same code on various MCUs is fine, and so it seems to be data type related. If the wrong data at byte level is passed into the EVE Text command by the IDE (which may not be apparent from the top-level code that you run) then you could see issues like this. This may explain why Rudolph also did not see the issue,

A second factor is to ensure that you convert all of the characters needed. If converting in higher quality and larger sizes of font, make sure that your converted data all fits into RAM_G depending on data size and address where you load it etc. With this you may see the wrong character in the string (as opposed to the 'tab' effect which seems caused by the compiler handling of unicode as above)

Best Regards, BRT Community

Hello,

Great to hear that it helped and thanks for letting us know,

Best Regards, BRT Community

Hmm?
Check my footer, it is *all* public. 

Hello,

Unfortunately the developers cannot provide the source code at this moment in time for the conversion utilities.

However I have requested an update on the progress of the Unix build for the command line tools

Best Regards,
BRT Community