• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 28 subscribers
  • Views 523 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.

Original question:

DLP2000: Disable BBB video buffer?

DLP2000: Image transfer rate, can it be adjusted? Can i load my own defaults on to the EVM?

Michael Ascenzi
Intellectual 540 points
Part Number: DLP2000
Other Parts Discussed in Thread: DLPC2607

Yes me again. I'm really struggling to understand what is occurring and how to increase the speeds on the image transfer rate we are trying to accomplish. I have some data that I'm looking at. 

We need: 40hz

with: 40 images, 360 x 640. Each image is black and white. there is a column exactly 5 pixels wide that goes from the top to the bottom. This 5 pixel width line shifts by 5 every frame. Its more or less a mask

What are we using: Starting off from the structured_light directory, using the C code. 

STOCK PROGRAM SPEED

./pattern_disp -r 40 1   = 40 frames ~6.1 seconds

./pattern_disp -r 30 1    = 40 frames ~6.1 seconds

./pattern_disp -r 20 1    = 40 frames ~6.1 seconds

./pattern_disp -r 10 1     = 40 frames ~6.1 seconds

./pattern_disp -r 5 1      = 40 frames  ~8 seconds

./pattern_disp -r 1 1       = 40 frames ~40 seconds

in another post I asked about 120hz, please ignore that. The 120hz was a different aspect of the project, related, but not really. for this discussion I need to the 40hz. 

I know the datasheet for the evm claims up to 60hz transfer rate. And the other discussion it was mentioned the BBB could get up to 40hz. So the speeds I'm seeing seem a little off. 

So I took some time and changed how the images were being collected, took out some of the code that wasn't applicable to my needs. I've managed to get the time reduced. I needed to increase the delay for allowing the buffer to finish loading and for the DLP2000 to update or I received splits in the mask lines the images. I also changed how the code accesses the gpio/i2c functionality and speed that up a bit. 

right now what I'm seeing is

UPDATED CODE

./pattern_disp                = 40 frames ~3.64 seconds

gotten closer, but there are some bottlenecks. namely the delays for the framebuffer to finish loading and the time for the DLP to update. Right now I have the Delay after loading the framebuffer set to 40000 and the delay to allow the dlp to update set at 30000. This is close to the minimum I can set them without creating any distortion in the image files as its loaded. but over 40 images. The delays add up to ~1.64 seconds for the first delay and 1.21 seconds for the 2nd delay. 

What am I missing? are there settings I should be looking at. I know there are control registers I could be setting. But it looks like the default is 60hz, based on table 11 on the DLPC2607 guide. 

There are a lot of references to frame rate related to motion video, video, such as frame rate control and settings such as vsync lock. But I'm not sure how they relate to still images. 

I guess what I'm asking is the way the software currently setup capable of 40hz? If it is capable, but not in its current form what should I be looking at to make changes to increase the speed? 

One last question. The EVM seems to have limited memory on it, where TI has stored images for testing and development purposes. Is there a way for us to get access to that memory, load our own images on it, rather than relying on the transfer rate between the BBB and the EVM. perhaps reducing the delays. 

Thank you for your time and help. 

  • 0
    TI__Mastermind 28005 points

    Michael,

    Based on your description above I am assuming this is related to the DLP2000 structured light example code.

    The DLP2000 EVM is going to be updating at the 60Hz rate based on whatever parallel video input data is being provided, regardless of what content is provided. Simply put, the bottleneck in this case is going to be the BeagleBone Black. There isn't anything you can throw at the DLP2000 that will cause it to slow down.

    It sounds like you are looking at tearing behavior on the BBB which is ultimately leading to slowdown in the whole system. If this is incorrect please elaborate if possible.

    Assuming that is the case the problem lies in the BBB's hardware graphics acceleration support, or lack thereof out of the box. Right now your system is probably using a software renderer (which is slow) to write each image to the framebuffer. To fix the issue, you need to get the hardware acceleration support set up.

    Let me know if this is indeed the behavior your are seeing so we can explore a bit further.

    Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    Intellectual 540 points

    Philippe, 

    Yes you are correct, I am referring to the structured light example code. 

    Looking at documentation I had thought the weak link would be the BBB, however I have some concerns and questions related to the DLP2000 that I am seeing that has me questioning the performance capabilities of the DLP2000 as well as the BBB. 

    So working with the structured light example, I made a number of modifications to try to weed out any bottlenecks. I played around with the freeze and unfreeze functionality, even timing the commands, which was improved with a more efficient library. However, there were two areas of the code that caught my attention as to questionable performance on the DLP2000 side. 

    If you reference <display_app.c> lines 237 - 245. As sits, the software causes some some judder at speed. Through some testing it seems that the delays on lines 243 and 245 are not long enough. So instead of relaying on the delay I inserted my own time delay, its still usleep(), but instead of the formula delay/10 or /3, I just inserted a time and decreased or increased the time till the judder was removed. What I found was this. 

    If I use a time of anything less than 40000 microseconds, on that first usleep() then the judder, tearing, is present. Now if I am understanding this correctly the function right before this delay memcpy(fbp, bbp, screensize) is the actual function that transfers the image from the BBB to the DLP2000. So this function and the usleep() is representing the time it takes for the BBB to complete the transfer. So this is absolutely chalked up to the limitations of the BBB. 

    However, on line 245 we have another delay, right after we unfreeze the update buffer of the DLP2000. on line 244 we unfreeze the buffer of dlp2000 allowing it to load the image we just transferred. What I found was that if I use a time of less than 30000 microseconds or 30ms, than we get the screen judder, tearing, again. At a delay of 30ms, we are talking a max rate of loading images on the DLP side of 33.33hz. This seems slow, am I missing something about the DLP2000's capablities?

    Ok, back to the BBB.  I am assuming the topic area I need to research is graphics acceleration support for BBB. Would that be correct? is there another area I should be looking at? 

    Philippe, Thank you for your time and help. This forum has been a great resource. 

  • 0 in reply to Michael Ascenzi
    TI__Mastermind 28005 points

    Michael,

    Thanks for your feedback. This is certainly an interesting study. Let me make some comments that might help:

    > The DLP2000 chipset is configured to run on a fixed 60 Hz sequence. This means that video data is being processed (and displayed) at 60 Hz, regardless of how the data is being sent in. In this manner, it is actually easier to think of DLP2000 EVM as a monitor device rather than a processor. If the video rate of the BeagleBone is having a detrimental effect, it may be because the BeagleBone is driving the EVM too slowly. This is why the graphics acceleration is important to ensure that (for these kind of applications) you can drive the DLP2000 at the 60 Hz it is expecting.

    > Yes, you want to be looking at graphics acceleration on the BBB. Unfortunately, it's not as much of an "out of the box" feature as other platforms. This is primarily due to the maintenance distribution of Debian on the BBB being configured for maximum compatibility (meaning, it is expected that not all target devices will have the necessary hardware available). Some community-driven tutorials such as this one might help you get going:

    https://busted.systems/PowerVR-SGX-on-the-beaglebone-black-in-2019

    I hope this helps.

    Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    Intellectual 540 points

    Phillippe thanks for that link. In all my searching, I never saw this one. It looks promising. I have shelved this aspect of the development for now. We are going to work off the current working speed of about 10hz. Not what we need, but for now we will implement all the other functionality first and then swing back to the speed issue. 

  • 0 in reply to Michael Ascenzi
    TI__Mastermind 28005 points

    Michael,

    Thanks for the update. Feel free to open another thread if new questions arise.

    Regards,

    Philippe Dollo