General Category > Discussion - EVE
How often and when read REG_TOUCH_TAG
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?
--- Quote from: vdc on April 03, 2024, 01:14:30 AM ---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.
--- End quote ---
Best Regards,
BRT Community
vdc:
--- Quote from: BRT Community on April 03, 2024, 09:51:09 AM ---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
--- End quote ---
Not really, here is my code display 371x400 bitmap on screen.
--- Code: ---
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);
}
--- End code ---
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?
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: ---Fps = (System Clock/REG_PCLK) / (VCYCL * HCYCLE)
--- End code ---
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,
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.
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
Navigation
[0] Message Index
[*] Previous page
Go to full version