BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Pages: 1 [2] 3 4 ... 10
 11 
 on: April 10, 2024, 03:39:55 PM 
Started by _chris_ - Last post by BRT Community
Hello

Thank you for your post.

There are different versions of the astcenc.exe file available, some versions including the version distributed with EVE Asset Builder require AVX2 support in your CPUs instruction set.

Could you take a screen of the CPU-Z output for your machine?
Could you also attach the .bmp file that you were trying to convert so that we can test this?

Best Regards,
BRT Community

 12 
 on: April 09, 2024, 10:44:39 PM 
Started by _chris_ - Last post by _chris_
For some reason I seem unable to run astcenc.exe supplied with EAB. I just get an error code "Error when run astcenc.exe tool!"
I tried installing in default 'documents' directory, in program files x86 and also under c:\  All with the same result. I also tried running as administrator, same result again.

I downloaded a generic astcenc.exe for windows and copied in place. This works but the display shows pink/purple dots at the bottom of the image.

Any suggestion on why the supplied astcenc doesn't work, or suggest an alternative version to try which won't show the incorrect dots.

A separate issue to note, the image conversion tool doesn't read the alpha channel from a 32 bit ARGB .bmp image and generates a non tranparent image in ARGB555 or compressed form. A .png works fine so not a problem to convert in a paint package first.

Many thanks.

 13 
 on: April 04, 2024, 11:58:19 AM 
Started by Rad - Last post by BRT Community
Hello,

EVE renders the screen from the contents in RAM_DL, however RAM_DL is actually double buffered meaning there is an active RAM_DL which EVE parses and uses to render the screen for every screen refresh. There is also a passive version of RAM_DL, this is the one you write to when you are issuing a display list or command list to EVE, this is swapped into the active buffer when the SWAP() command is issued.

The intention being that you only write a new display/command list to EVE when require the screen to be updated (say when a button is touched and you wish to enact a 3D effect to make this apparent), otherwise you can let the active display list continue to render the screen in the background and reduce the number of SPI transactions you send to EVE.

I note you mention you are scanning and re-issuing your Display() function every 100ms, but can I ask if this is irrespective of a touch detection?
It would not be necessary to re-issue the Display() call if you do not need to update any of the items on the screen.

Generally there are two approach's to dealing with touch on EVE, in either case we would recommend to initially issue your display list (call Display()):

  • Polling - Call Display(), then utilise another routine to periodically poll the appropriate touch registers to detect a touch (for example REG_TOUCH_TAG) 
    • If a touch is detected then you can re-issue a new display list with the appropriate updates (call Display() to update the screen) if required
  • Interrupts - Configure the touch interrupt, Call Display(), then wait for the interrupt pin to trigger and process this interrupt on your MCU (read the appropriate touch registers)
    • If an item has been touched which requires the screen to be updated then issue Display() accordingly with the required updates

Both approaches should reduce the number of times you call Display() the idea being that you would only need to update RAM_DL when something has to be changed on the screen. i.e. you shouldn't need to worry about an interrupt being triggered half way through your Display() routine because you are not continuously writing this data to EVE. If you structure your code in am manner that calls Display() and then only calls it again once a touch has been detected you should avoid any interrupted Display() calls. However it is possible that for example two interrupts would be trigged very close to each other, in this case you can utilise the recovery routine detailed in section 5.7 of the Programmers Guide and then re-issue the Display() command. As EVE will be rendering from the active versions of RAM_DL is a write to EVE is interrupted half way through a Display() command then the screen contents wont be affected.

Best Regards,
BRT Community

 14 
 on: April 03, 2024, 01:27:26 PM 
Started by Rad - Last post by vdc
I'm using Riverdi EVE4 Display (RVT70HSBNWC00-B)

I just do a quick test, sending all command to command FIFO take 1ms. Including copy Bitmap to flash total time will be 14ms (fixed some problem with my code)


My define to calculate FPS

#define DispHCycle    1344L
#define DispVCycle    635L
#define DispPLCLKFREQ  0x8C1       
Gpu_Hal_Wr8(host, REG_PCLK, 2);

So based on Fps = (System Clock/REG_PCLK) / (VCYCL * HCYCLE)
(72000000/2) / (1344 * 635) ~= 42FPS

Also, for the touch interrupt, how do we make sure touch interrupt not corrupt display function?

For example. My Display() take about 24ms to finished is worst case for waiting copy stuff from flash to RAM_G. If the interrupt kick in before the Display() finished. A command from display may corrupted. How we fix this problem?

Also, when touch detected, interrupt kick in. If the interrupt kick in during Display() function sending data to Command FIFIO. In most case, there will be a command corrupted because the CS line reset. From the interrupt, I can signal the Touch function to scan after Display() finished. But there can be chance when Touch scan, touch already released cause the TAG/XY is empty, scan will be no touch because we share the same SPI bus from MCU to EVE4. Unless we can read the Touch signal on difference bus (UART/I2C) directly from MCU.



 15 
 on: April 03, 2024, 12:05:24 PM 
Started by Rad - Last post by BRT Community
Hello,

Without knowing your exact display settings I would suggest an average configuration 1024*600 display would be running at roughly 50Fps (20ms a frame).

Therefore the 29ms you are seeing for frame rendering doesn't sound too unusual for a display of the resolution you are utilising. The CMD_SWAP command will also wait until the current screen refresh has completed to rendering a new display list, depending on when the list is issued this will add a small delay into the execution time also.

You can work out your display refresh rate in the following manner:
Code: [Select]
Fps = (System Clock/REG_PCLK) / (VCYCL * HCYCLE)

In short yes, the size of your screen is the limiting factor in this instance, I would suggest looking into utilising EVEs touch interrupts if possible.

Best Regards,


 16 
 on: April 03, 2024, 10:32:46 AM 
Started by Rad - Last post by vdc
Hello,

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


Best Regards,
BRT Community


Not really, here is my code display 371x400 bitmap on screen.


Code: [Select]
   

Display(){
static uint8_t Close = 0;

Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(255, 255, 255));
App_WrCoCmd_Buffer(phost,CLEAR(1,1,1));

App_WrCoCmd_Buffer(phost, COLOR_RGB(0xFF,0xFF,0xFF));
App_WrCoCmd_Buffer(phost, COLOR_RGB(0, 81, 122));
Gpu_CoCmd_Text(phost, 512, 62, 31, OPT_CENTER, "DOOR IMAGES");

// Load one time
if(Load == 0){
Gpu_CoCmd_FlashRead(phost, DOOR_RAM_G, DOOR_ADDRESS, DOOR_SIZE);
Load = 1;
}

// Draw Bitmap
Gpu_CoCmd_SetBitmap(phost, DOOR_RAM_G, RGB565, DOOR_CLOSING_W, DOOR_CLOSING_H);
App_WrCoCmd_Buffer(phost, COLOR_RGB(0xFF,0xFF,0xFF));
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(320*16, 125*16));
App_WrCoCmd_Buffer(phost, END());

// Draw Buttons
Gpu_CoCmd_FgColor(phost, 0x00557F);
App_WrCoCmd_Buffer(phost, COLOR_RGB(0xFF,0xFF,0xFF));
App_WrCoCmd_Buffer(phost,TAG_MASK(1)); // Enable Tagging

App_WrCoCmd_Buffer(phost, TAG(KEY_TAG_1));
Gpu_CoCmd_Button(phost, 710, 540, 90, 50, 29, 0, "1");

App_WrCoCmd_Buffer(phost, TAG(KEY_TAG_2));
Gpu_CoCmd_Button(phost, 810, 540, 90, 50, 29, 0, "2");

App_WrCoCmd_Buffer(phost, TAG(KEY_TAG_3));
Gpu_CoCmd_Button(phost, 909, 540, 90, 50, 29, 0, "3");

App_WrCoCmd_Buffer(phost,TAG_MASK(0)); // Disable Tagging

App_WrCoCmd_Buffer(phost, DISPLAY());
Gpu_CoCmd_Swap(phost);
App_Flush_Co_Buffer(phost);
Gpu_Hal_WaitCmdfifo_empty(phost);
}


The first time is worst case where it take more time because it need time to load Bitmap from flash to RAM_G. This take about 45ms to display on screen.
After that, the display take about 29ms.

Because in normal case, the display function already take about 29ms. Scanning Touch Screen within 50ms doesn't make sense to me because at some point, the display haven't finished yet. Is this because high resolution cause the problem?


 17 
 on: April 03, 2024, 10:11:21 AM 
Started by Rad - Last post by BRT Community
Hello,

Unfortunately it is not possible to achieve this with a JPEG as these are loaded into EVE as RGB565 bitmaps (or  L8) which do not include an alpha layer (transparency), this is required to make sections of images transparent.

As you have noted using a command such as blend, this effects the whole image because it cannot determine which sections are the background in a JPEG. It may be possible to utilise a second masking image to mask off the background in your JPEG and then use the STENCIL operation to only draw the section of the image that isn't masked, but this would require an image such as a PNG which utilises an alpha layer to be used as the mask. In this case it may be simpler to modify your original JPEG image in a image processor to include a transparent background and save this accordingly.

Best Regards,
BRT Community

 18 
 on: April 03, 2024, 09:51:09 AM 
Started by Rad - Last post by BRT Community
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

 19 
 on: April 03, 2024, 09:50:11 AM 
Started by Rad - Last post by Rad
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?


 20 
 on: April 03, 2024, 01:14:30 AM 
Started by Rad - Last post by vdc
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.

Pages: 1 [2] 3 4 ... 10