Setting the Pcam 5C's internal registers

[bitslip]

Hello,

I'm trying to change the resolution of the Pcam 5C using the Zybo's reference design via a UART console.

The console application supports 3 pre-configured resolution setting changeable by typing 'a' and then the setting number.

But I want to change it manually via accessing the Pcam 5C's internal ISP registers - as described in page 41 in the datasheet:

https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf

 

Question:

Can the resolution be changed solely by changing the value of these registers "on the fly" ?

Or is a complete initialization sequence required ?

[BogdanVanca]

Hello @bitslip,

Yes, you are correct. Theoretically you can rescale the image at any size, even at 1000x1. I'm saying theoretically because I never tried it, not because I think it's not possible. The sensor doesn't have any kind of constraints  that could stop you to do that. Or, at least I couldn't find any into the datasheet.  The VDMA has to have a fix number of bytes for each individual transfer. So, if you are playing with the number of bytes, you have to reinitialize the function above for each transfer, as it was done in the DEMO. 

[BogdanVanca]

Hello @bitslip,

Things are a little bit more complicated.  Indeed, for changing the resolution you have to rewrite some registers. But you also need to make sure that the Video Trimming controller ip generates the required constants for you resolution. I wouldn't recommend to write all the needed registers from the control interface (it would be agonising) Instead I would go with the existent logic for changing the resolution, which is adding a new structure with all the register values. As an example, you can check the OV5640.H file. I much simple and quicker solution would be to use our video scaller ip. This ip was written in HLS and it was used in the  fmc pcam adapter demo for re-scalling the video at a 640x480 resolution.  You can check the design in here: https://reference.digilentinc.com/learn/programmable-logic/tutorials/zedboard-fmc-pcam-adapter-demo/start

 

Best Regards,

Bogdan Vanca 

 

[bitslip]

Thanks a lot for your input Bogdan.

Unfortunately, using the Scaller IP isn't an option - changing the actual resolution that the sensor outputs is a mandatory project requirement.

Quote

But you also need to make sure that the Video Trimming controller ip generates the required constants for you resolution

Can you explain what you mean by "Video Trimming Controller IP" ?

I can't find such a component in the Vivado PCAM 5C reference design... 

[BogdanVanca]

Hello @bitslip,

 

Sorry, my bad. I was referring to the Video Timing Controller not "Trimming". This IP simply generates timing parameters for the desired resolution. Check this link: https://www.xilinx.com/support/documentation/ip_documentation/v_tc/v6_1/pg016_v_tc.pdf

 

[bitslip]

I understand.
Thanks.

I'm using the reference design's infrastructure as a basis to achieve different operation.

What I need to do is record (single) raw images to the Zynq's memory upon software request.

The output to the monitor isn't necessary so the whole Tx path can be discarded.

 

Now, in my case - the resolutions the Zynq might request can be quite arbitrary and not limited to a set of standard image sizes ( basically any X * Y within the sensor's limits ).

A few questions:

1. Would the sensor support output of an arbitrary image size configured using its registers ? 

2. What about the other IP's in the design ? 

[BogdanVanca]

@bitslip

 

To answer your questions.

1. Yes. You can can output any image size that is described into the sensor datasheet. This can be done on the fly if you reprogram the right registers. Part of this is already achieved by the demo project. The change resolution option from the user interface reprograms the sensor for each resolution. For more info you can dig into the fallowing function: pipeline_mode_change(vdma_driver, cam, vid, Resolution::R1280_720_60_PP, OV5640_cfg::mode_t::MODE_720P_1280_720_60fps);  The OV5640_cfg namespace has 3 different modes for each individual resolution. Each mode is correspondent to a structure that stores all the registers values needed for that resolution. To be more specific, all the registers that are responsible for image windowing (0x3800 to 0x3807), are configured in these structures. Let's take for example the cfg_1080p_15fps_ structure. If you want to calculate the output X size, you would have 2287(0x3804, 0x3805 registers) - 336(0x3800, 0x3801) - 16(0x3810, 0x3811) which is equal with 1919. The registers 0x3808 and 0x3809 are configured for 1920, so the image is basically un-scaled. For image windowing you have to rewrite those registers. 

2. Yes and No. It depends on how many resolution do you want to add. Unfortunately I cannot give you a number, because I'm not sure how versatile is the current design. For now it works for 3 different resolution, but is hard to tell how many you could add on. Each individual resolution may have a different pixel clock, or as I said before, a different set of image constants. 

 For now, I would probably start to understand how to configure the above registers, and I would start playing with them. You also need to make sure, that the vdma transfer works as expected. As you may see, the pipeline_mode_change function reconfigure the vdma_driver object for each resolution. 

[bitslip]

Quote

It depends on how many resolution do you want to add.

Well...the software application that controls the logic design might set any X * Y combination - Even "very strange" sizes such as for example: X= 1000, Y = 1.
So I must be able to support all possible matrix sizes.
According to what you say - the sensor DOES support it...am I correct ?

But I'm not sure the VDMA does. I might have to remove this IP from the design altogether and write something custom.

 

[bitslip]

Thanks a lot for your kind help.
Please stay posted - I'll update on my progress and will definitely have more questions as I progress.