• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 319 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Dm6437 FVID_Buffer

dcarrozza
Prodigy 80 points


We're driving a 640x480 LCD display. The problem is that display updates are initially slow when a new image is loaded into the frame buffer. We've narrowed down this sluggish behavior to the time it's taking to execute the FVID_exchange() statement.  I've read that this function can block if no buffers are available, which appears to be happening. What conditions could cause this? What's interesting is that after a period of time, the display becomes more responsive. We re-measured the FVID_exchange time and it was substantially less.  The display task basically consists of the following few lines of code:

LCD_Frame_p = (Uint16 *)DISPLAY_MEM_ADDR;

memcpy(vpbe_osdFB->frame.frameBufferPtr,LCD_Frame_p,(_XSIZE *_YSIZE * 2) );

FVID_exchange(hOSD0,&vpbe_osdFB);

 

 

  • 0
    TI__Expert 4010 points

    dcarrozza said:
    What conditions could cause this?

    Without knowing more about your setup, there could be a couple of thins causing this.

    1.  There is a higher prirority thread that is basically blocking your display task from running as fast as you want it to.

    2.  If the video port backend is set up as a slave for clocks and syncs, and those clocks and syncs are slower than expected, this could cause the problem you are seeing.

    dcarrozza said:
    What's interesting is that after a period of time, the display becomes more responsive.

    How long of a period of time?  What do you mean by "more responsive" - what type of frame rate are you getting?

  • 0 in reply to David Meixner
    Prodigy 80 points

    It doesn't appear to be a priority issue, as the display task is setup to run as the highest priority task, nor do we think its a clock setup issue.

    After our controller board completes its setup and initialization, we display a series on bitmap images on the LCD which are looped on for a set period of time, to indicate system status (i.e. looping through display image calls to show an hourglass filling on the LCD).

    For the first 30 seconds or so in this loop, the time interval between subsequent images displayed on the LCD is approx 1 second. However, after this display loop runs for approx. 30 seconds, the time interval between image updates on the LCD is much faster (in the mSec range). We measured the time it's taking to execute the FVID_exchange() and found a correlation between the time it's taking to execute the FVID_exchange and the time between image updates. Since this function can block if a buffer is unavailable, we're assuming this is why FVID_exchange is initially taking so long to execute. We also haven't been able to figure out why after 30 seconds, the execution time for this function is much faster .  What could be causing this function to block?   

  • 0 in reply to dcarrozza
    Prodigy 105 points

    May be you need to check how much time the following would take:

    memcpy(vpbe_osdFB->frame.frameBufferPtr,LCD_Frame_p,(_XSIZE *_YSIZE * 2) );

    640x480*2 = 614400 bytes xfer thru' cache might be hitting. As a quick trial you could try out copying just 1K bytes and see if memcpy is not the culprit!