questions regarding FVID_frame structure

Hi,

We are working on this issue and will update you once getting the response from experter.

Thanks.

yihe

Hello,

Do you check the following wiki? is it helpful?

http://processors.wiki.ti.com/index.php/Accessing_pixels_in_a_frame_on_DM643x 

Regards.

yihe

Hi,

Thank you for you assistance. 

I have read this wiki document, and as I mentioned in the previous post, it is not helpful for my purposes. 

With the help of this wiki I have managed to "run over" the values in the *(frameBufferPtr) - meaning - I can process the image, but only on the buffer itself.

What I want to do is allocate my own new buffer ( a memory block in the size of width*height*2), capture a frame into the new buffer, and process that frame, without using the buffer allocated by the video_preview itself.

That, I'm afraid, isn't working for me so far. I allocate a buffer and point to it with frameBuffPtr->frame.frameBufferPtr, then I use FVID_exchange with the &frameBuffptr, but while in debugging mode, if I try to watch the values in my new buffer,, CCS shuts down.

Regards.

Yoav

Hi again,

I hope my question was not forgotten. I am still having trouble watching the contents of the memory area that frameBuffPtr->frame.frameBufferPtr is pointing to.

Does anyone have any idea what the problem is? Solving this issue will be very helpful for my project.

Thanks

Yoav

Yoav,

We are working on this issue and will update your once we get answers from SW team.

Regards,

yihe

I understand and appriciate it very much. Thank you.

I do have another question, regarding a different matter:

In my code, after processing a captured frame, I use a loop that checks the DIP switch state ni order to display the processed frame for unlimited time.

That is done like this:

// CODE //

{....}  // frame is captued,  processing is done, and now I want to display the processed image, which is pointed by the frameBufferPtr //

            FVID_exchange(hGioVpbeVid0, &frameBuffPtr);
            TSK_sleep(1);
           
            while( EVMDM6437_DIP_get(DIP_0) == 0 )
                {
                    asm (" NOP");
                }       

{...}

// END OF CODE //

The weird thing is, that the "while( EVMDM6437_DIP_get(DIP_0) == 0 )" loop helps me display the image only for several seconds - after some time it seems as if the condition is checked and returns 0 instead of 1 although I never touch the DIP switch again. Even weirder is, that the next time that the condition is checked, in the part of the code that decides whether or not the newly captured frame is to be processed, it again returns 1

Anyone knows this problem?

Anyone knows a better way to display a constant image on screen?

Thanks

Yoav

First off, you should always debounce any switch inputs to your system... if this is just for playing around, a dinky little routine that reads the switch several times in a row until the value is stable for a say 16 or 32 times in a row should take care if your new problem.

As for allocating your own memory buffer, you can start by making sure that you can watch allocated memory at all.  Put a breakpoint after your malloc call (making sure it doesn't return null) and see if you can watch the buffer at that point.

You also must remember that video buffers have to be 32 byte aligned for the hardware to work correctly (5 lsbits must be 0).

And finally, remember that anytime the video port hardware operates on a piece of memory to fill or grab a frame buffer, you have to remember to handle cache coherence.  So if you are going to process a frame returned by the vpfe, you have to invalidate cache for that memory location before you process it.  And then before you return it to the vpbe, you need to writeback-invalidate the buffer.

Took a quick look at the image you posted, and then read what Matt replied--yes, what you have is a cache problem. VPFE uses DMA to transfer captured image to memory, and DMA to transfer from memory to display device. DMA does not know about cache! But any processing you do does... the last few lines of processed image stay in cache, and never get actually transferred back to memory, but the display gets image from memory only. So, you need to make sure and WbInv the image from cache prior to display.

Jim

Hi guys,

Thanks for your replies. 

Regarding the unprocessed part of the image - you were both right. I found the problem a few days ago, and it was quite a silly one - while updating the cache, I used 720*480 sizes instead of the original 720*576. So that's that.

Matt - as for your reply, I must admit that I don't understand it. I'm afraid english isn't my native language, and further more, I am very new to the DSP programming, so the first paragraph is very unclear to me:

quote:

"First off, you should always debounce any switch inputs to your system... if this is just for playing around, a dinky little routine that reads the switch several times in a row until the value is stable for a say 16 or 32 times in a row should take care if your new problem."

end of quote.

I'd very very grateful is you could try make it a little simper for me.

And finally, about the memory allocation watching - well, there is no problem for me to watch the allocated memory when I use malloc. But if I use mem_Alloc in order to have a little bit more control - for some reason it fails allocating the buffer. Moreover - wathcing my  memory allocation wasn't the real problem. The main issue here was using the frameBuffPtr->frame.frameBufferPtr pointer to point at my allocation in order to capture a frame into my allocated buffer and not the original one. This, for some reason, I cannot do.

Thanks for all

Yoav

Hi Matt,

Thanks for the explanation - it did solve my problem! I hope this htread will be helpful for anyone bumping the same problem in the future. in order to debounce the switch I added a loop that tests its value 3 times, means it, and remains in the static display status if the outcome is greater than 0.5.

I'm still on the search regarding the memory access problem that I have had, however, one thing at a time...

Thanks again

Yoav

Maybe you should post your code here for the memory access problem that you are chasing.