Question to Mr.Bernard Thompson

It is actually much simpler than you are thinking, this is because the call to the function was made with an 2/3 pixel height (320 lines instead of 480 lines), so this is effectively a bug in the function (good catch! :) ), I probably forgot I was passing the pixel height in for 2/3 of the image and just modified the multiplier instead of changing the input to the call when I decided I wanted to make it go for the whole screen, originally I had it only working on part of the screen so I could easily see what the original vs the modified image would look like.

If you change process_image( (void*)(frameBuffPtr->frame.frameBufferPtr), 320, 720, 100, 200 ); to process_image( (void*)(frameBuffPtr->frame.frameBufferPtr), 480, 720, 100, 200 ); than you can modify the 3x multipliers to be 2x multipliers (I just tried this and it appears to work), and the image modification code makes much more sense, I will make this modification and upload a new zip file to the wiki.

EDIT: File on Wiki has been updated.

Thank you very much for your reply.

Happy New Year!

Dear Mr. Thompson.

Your examples are very helping us - beginners -  to learn DM6437. Do you plan to publish more examples of programming DM6437?

Thank you,

Igor. 

The examples already included with the DVSDK that this was based on should cover most of what you would need to get started, I typically only make/modify examples like this when there is a specific need for such an example. What type of examples do you feel should be added to the DVSDK?

How to connect DM6437 with camera in raw mode and control camera using I2C.

This is kind of a two part question, and for examples you will also find two, the first place you probably want to take a look at is C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\rawcapture which is a good example of interfacing to a image sensor in RAW mode, the video driver already supports this out of the box. As to the I2C configuration this would usually be done within the video capture driver which you could modify to do so, however alternatively there is an I2C example within C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\drivers\i2c\sample that you could use as a basis for your I2C communiation either in the driver or in your application code.

Speaking of which, DM6437 needs an example of interfacing to LCD. Analog output examples are great and very sufficient but there is no LCD output example. The only example I could find is the one for DM6446. It is not hard to convert it to DM6437, but still a standalone example should be for DM6437.

I agree that a LCD example for DM6437 would be useful, the reason this never came to be is no one at TI made a board with an LCD, or an LCD daughtercard adapter for the EVM so there has been no way to validate such an interface. Though TI has not provided anything in this regard there is at least one third party out there who has a LCD reference design, in particular I know D3 engineering has a LCD daughtecard and I have sent a few developers their way to get LCD example drivers/software with no complaints (though there is likely some cost associated with it).

Dear Mr Thompson

I too am trying to interface a image sensor in raw mode. I have looked at the example that you have indicated, however I am slightly confused as to its operation. This is probably a stupid question, most likely due to not fully understanding the operation of the VPSS.

The application creates four channels (CCDC, Video, OSD-0, Venc). However in the 'loopback test' section of the code, the handles to the OSD-0 and Venc don't seem to be used. In this case how does the captured video get transfered to the back end for display on a composite display as indicated by the vencParams?

Thank you in advance

Chithambaram

This is just how the driver is laid out, there are seperate channels that end up going to the same display, in this case the example is configuring the overall output with the VENC and the OSD hardware with the OSD-0, as well as the video window, but once it comes time to display the image and the rest of the video path is properly configured you only need to move the frame from a single capture driver (CCDC) to a single display driver. I believe the raw capture example is actually using the OSD to display as opposed to the video window, so it can display the RGB data it captures from the sensor properly, as the OSD window supports the RGB color space.

Chithambaram Veerappan said:

In this case how does the captured video get transfered to the back end for display on a composite display as indicated by the vencParams?

To answer directly, the vencParams apply to the overall output, so what goes into your video and OSD windows comes out in the form defined by the vencParams.

Bernie,

Bernie Thompson said:

in particular I know D3 engineering has a LCD daughtecard and I have sent a few developers their way to get LCD example drivers/software with no complaints (though there is likely some cost associated with it).

I tried the link but was not able to access it, nor www.d3engineering.com. We have a government firewall in China which might have inadvertently blocked the website, though normally it doesn't filter technical sites. 

Update: I was able to access the website several minutes later. It is not blocked and was just a temporary connection problem.

Could you put a copy of the linked content/code as an attachment on the forum, if their copyright policy allows this?

I am contacting them directly now.

Bernie Thompson said:

I agree that a LCD example for DM6437 would be useful, the reason this never came to be is no one at TI made a board with an LCD, or an LCD daughtercard adapter for the EVM so there has been no way to validate such an interface.

I am actually curious on why TI has no way to validate such an interface. Ultimately TI engineers design LCD controller in the VPSS, and they must have tested the controller with various LCDs before releasing the product. Any testing code of this kind would contain the necessary code for LCD display pinmuxing {VCLK, VSYNC, HSYNC, LCD_OE, RGB pins}, OSD and VENC configuration and so on, therefore such code would be an ideal example to users of DM6437 requiring LCD display.

It goes without saying that such code must exist, and since it contains only standard configuration steps, it also shouldn't be proprietary or confidential. So may I request a copy of such code? On the LCD side, I have done with the SPI interface for register writing/reading and the LCD now displays colored flakes which is an indicator of its normal working state; but on VPBE side, I have tried tuning various registers for several days without getting VCLK and RGB656 signal output. There are an overwhelming combination of all register value combinations, and it is quite difficult for me to figure out the correct setting without an example to reference.

Could you help to provide a version of such code here? I would be very much obliged to this. 

Zheng