Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rad]

Hi,

as in the subject:
is there any practical/theoretical redord/order when and how often REG_TOUCH_TAG can be read?

Once, testing some code I (mistakenly) read this reg every 1 millisecond and noticed that EVE started to crash. It took me a while to get it noticed that I do it too often.

Another point is about then this reg should be read:
can it be read anytime or rather once EVE finishes processing a freame buffer and REG_CMD_WRITE = REG_CMD_READ ?

[sjasz]

In our code, REG_TOUCH_TAG is read 20ms after CMD_SWAP. It doesn't check REG_CMD_WRITE = REG_CMD_READ before it is read. I inherited this code so didn't verify the 20ms myself, but the person that did told me it needed to be there, and was a conservative amount of time to wait.

Our code alternates between drawing pages and reading REG_TOUCH_TAG as fast as possible, so only ever reads REG_TOUCH_TAG after drawing a page. It never reads REG_TOUCH_TAG two times in a row. 

Sorry, not as empirical as you may have liked, but it has been 100% stable for several years.

[Rudolph]

My code usually checks for touch events every 5ms and that function does three reads now.
Reading REG_CMDB_SPACE to check if EVE is still busy from the display refresh or if there was a co-processor fault.
Reading REG_CMD_DL as a debug measure to get the size of the last generated display-list.
Reading REG_TOUCH_TAG.

I just did an experiment with a Teensy 4.1 under Arduino as this was wired up to the logic analyzer.
The SPI clock is 16MHz.
I moved out the function call to check for touch events that I placed in the loop() function to outside
the code that checks that 5ms passed.
And all that happens is that I can see with the logic analyzer that the SPI is flooded.
The REG_TOUCH_TAG is read every 12µs.

Now I commented out the reading of REG_CMD_DL which means that REG_TOUCH_TAG is read every 8µs.

Ok, I can get away with not reading REG_CMDB_SPACE since I have an internal flag for the DMA transfer of the display update.
And reading REG_TOUCH_TAG does not interfere with the co-processor.
Now the logic-analyzer traces shows reads of REG_TOUCH_TAG about every 3.6µs.

And the EVE3-50G module which has a BT815 and a GT911 is just fine.
No crash and the touch still works fine.

So no, there does not appear to be a limit on how often REG_TOUCH_TAG can be read.
My display update is every 20ms though, so it really does not help to read the register >5400 times in between. :-)

My main loop does this now, 5ms per step:
read read read display read read read display

And there probably would not be a noticeable difference if I changed that to >read / display< with 10ms steps.

Hmm, I wonder now how long touch events actually are, or rather how short these can get.
I went back to reading REG_TOUCH_TAG every 12µs and added a counter that is set to 1 on registering the touch of a button and gets increased as long as the button is touched.
And I can not get this time realiably below 3000.
Right now the number is 1142 which meant I managed to touch the button for only 13ms.
2161 - 28ms
976 - 12ms
2138
3298
4417
3275
3304
2156

Going back to 5ms timeslots I can not get the counter lower than 3.
And not trying to touch as fast as possible I get closer to 20.

So I guess it is ok to assume that the duration of touch events is at least 10ms.

[KarolBob]

Hi there.
I've been recently testing the method with interrupt handling from the touch panel. Thanks to this, it's possible to practically not send anything to FT/BT81x for most of the time. When an interrupt occurs, only then do I read the TAG. Here's the interrupt configuration:

Code: [Select]

void EVE_INT_config(void)
{
    EVE_memWrite8(REG_INT_EN,1);                // IRQ on
    EVE_memWrite8(REG_INT_MASK,EVE_INT_TAG);    // EVE_INT_TOUCH|
    EVE_memRead8(REG_INT_FLAGS);                // clear by read flag
}

Then, in loop functions:

Code: [Select]

if(is_set(FLAGS,_f_tp_irq))
        {
            CurrTag = EVE_memRead8(REG_TOUCH_TAG);
            RESET(FLAGS,_f_tp_irq);
... // the rest of the code
            // refresh the screen by set timDisp to 0
            timDisp = 0;
            EVE_memRead8(REG_INT_FLAGS); // skasuj flagi
            timer_screensaver = time_screensaver; // przeÅ‚aduj timer wygaszacza ekranu
        }
        // prepare a new display list:
        if(!timDisp)
        {
            timDisp = 50;     
            // start new 'display list'
            start_new_screen();
...// etc
            finish_new_screen();
        }
Also IRQ from pin change:

Code: [Select]

ISR(INT7_vect)
{
    SET(FLAGS,_f_tp_irq);
}

[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.

[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

[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?

[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,

[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