• Content Count

  • Joined

  • Last visited

About bitslip

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks Bogdan! So this is my plan: 1. First I'll set the resolution to 2560 W x 2 H ( registers 0x3800 and 0x3814 ) without changing any other register. The Pixel Clock and Exposure time will remain as in the default configuration of the reference design. If I understand you correctly, as long as my custom DMA supports this resolution - everything should work correctly and no changes will be required to the MIPI_PHY ------> MIPI_CSI ------> Bayer video chain. 2. Afterwards, I'll increase the FPS by increasing the Pixel Clock and decreasing the Exposure Time (lines 473 to 478 that you mentioned) and see how it impacts the image quality. From what you said I understand that increasing the FPS (up-to a point of course) also won't require any changes in the MIPI_PHY ------> MIPI_CSI ------> Bayer video chain. Let me know what you think, Thanks again!
  2. That's what I thought...I don't need these. I'll try to explain why. You see...I don't send video to the monitor and don't use the VDMA. My application requires to only receive images from the sensor and store them (in a special manner) in the ARM memory. 1.I removed all the data storage (VDMA) and Video Tx parts. 2.I designed a custom DMA to store the incoming data. So now - the redesigned video chain looks like this: MIPI_PHY (original) ------> MIPI_CSI (original) ------> Bayer (original) ------> DMA (my custom) I tested it and it supports the existing resolutions very well. My custom DMA can support the new 2560 W x 2 H without a problem. So now what I need is: A. Make the sensor send the image at 2560 W x 2 H ( registers 0x3800 and 0x3814 ). This is straight forward. B. Increase the frame rate as much as possible. (I still need the red part of the video chain to function correctly because I don't want to redesign it). This is much more complex for me and I'm stuck at this stage. Questions: 1. What is the highest frame rate that will still work with the red part of the video chain ( given a 2560 W x 2 H resolution ) ? 2. How do I configure the OV5640 to this frame rate value ( what registers in the OV5640.h have to be updated ) ? I hope it's clearer now, Thanks a lot for your help Bogdan!
  3. You mentioned the VideoOutput.h file as responsible for changing the pixel clock. I'm a bit confused Does it change the pixel clock for the sensor ? Or only the IP components in the Block Design ( VDMA , rgb2dvi, etc...) ?
  4. Thanks, What will be the highest frequency that will still be supported by the current Bayer Filter ?
  5. Hi Bogdan, This doesn't answer my question. I know about these registers...but as I said: I don't want to JUST change the resolution - I want to make the frame rate (FPS) as high as possible. Suppose we change the resolution to : 2560 W x 2 H using the windowing registers. What's next ? 1. What will be the highest FPS for that resolution ? 2. How do we set this new FPS ?
  6. Hello, I'm working with the Zybo Pcam 5C (18.2) reference design and want to add a custom resolution to the design: 2560 W x 2 H ( yes the height is 2 - it's not a mistake ). With this resolution, I want to make the frame rate as high as possible. I'm looking in the OV5640.h file to see how the existing resolutions have been set. From example please look at the setting for 1920 * 1080 * 15fps below. I know I'll have to change the fields I marked in Red. Do I need to change anything else to support 2560 W x 2 H ? config_word_t const cfg_1080p_15fps_[] = {//1920 x 1080 @ 15 fps, RAW10, MIPISCLK=210, SCLK=42MHz, PCLK=42M // PLL1 configuration // [7:4]=0100 System clock divider /4, [3:0]=0001 Scale divider for MIPI /1 {0x3035, 0x41}, // [7:0]=105 PLL multiplier {0x3036, 0x69}, // [4]=0 PLL root divider /1, [3:0]=5 PLL pre-divider /1.5 {0x3037, 0x05}, // [5:4]=01 PCLK root divider /2, [3:2]=00 SCLK2x root divider /1, [1:0]=01 SCLK root divider /2 {0x3108, 0x11}, // [6:4]=001 PLL charge pump, [3:0]=1010 MIPI 10-bit mode {0x3034, 0x1A}, // [3:0]=0 X address start high byte {0x3800, (336 >> 8 ) & 0x0F}, // [7:0]=0 X address start low byte {0x3801, 336 & 0xFF}, // [2:0]=0 Y address start high byte {0x3802, (426 >> 8 ) & 0x07}, // [7:0]=0 Y address start low byte {0x3803, 426 & 0xFF}, // [3:0] X address end high byte {0x3804, (2287 >> 8 ) & 0x0F}, // [7:0] X address end low byte {0x3805, 2287 & 0xFF}, // [2:0] Y address end high byte {0x3806, (1529 >> 8 ) & 0x07}, // [7:0] Y address end low byte {0x3807, 1529 & 0xFF}, // [3:0]=0 timing hoffset high byte {0x3810, (16 >> 8 ) & 0x0F}, // [7:0]=0 timing hoffset low byte {0x3811, 16 & 0xFF}, // [2:0]=0 timing voffset high byte {0x3812, (12 >> 8 ) & 0x07}, // [7:0]=0 timing voffset low byte {0x3813, 12 & 0xFF}, // [3:0] Output horizontal width high byte {0x3808, (1920 >> 8 ) & 0x0F}, // [7:0] Output horizontal width low byte {0x3809, 1920 & 0xFF}, // [2:0] Output vertical height high byte {0x380a, (1080 >> 8 ) & 0x7F}, // [7:0] Output vertical height low byte {0x380b, 1080 & 0xFF}, // HTS line exposure time in # of pixels Tline=HTS/sclk {0x380c, (2500 >> 8 ) & 0x1F}, {0x380d, 2500 & 0xFF}, // VTS frame exposure time in # lines {0x380e, (1120 >> 8 ) & 0xFF}, {0x380f, 1120 & 0xFF}, // [7:4]=0x1 horizontal odd subsample increment, [3:0]=0x1 horizontal even subsample increment {0x3814, 0x11}, // [7:4]=0x1 vertical odd subsample increment, [3:0]=0x1 vertical even subsample increment {0x3815, 0x11}, // [2]=0 ISP mirror, [1]=0 sensor mirror, [0]=0 no horizontal binning {0x3821, 0x00}, // little MIPI <moderated>: global timing unit, period of PCLK in ns * 2(depends on # of lanes) {0x4837, 48}, // 1/42M*2 // Undocumented anti-green settings {0x3618, 0x00}, // Removes vertical lines appearing under bright light {0x3612, 0x59}, {0x3708, 0x64}, {0x3709, 0x52}, {0x370c, 0x03}, // [7:4]=0x0 Formatter RAW, [3:0]=0x0 BGBG/GRGR {0x4300, 0x00}, // [2:0]=0x3 Format select ISP RAW (DPC) {0x501f, 0x03} };
  7. Thanks, Can you please explain what you mean by ?
  8. Why doesn't this post get any attention ? I pointed out and showed an example of a clear problem
  9. Hello, I'm working with the Zybo Pcam 5C (18.2) reference design. While using the default resolution of 1920 * 1080 - I observe the AXI Stream but exiting from the GAMA CORRECTION IP (this is last core in the video chain before the VDMA). A strange thing I noticed is that the first 4 lines at the beginning of each frame are a constant 0xAE for all pixels. ( all the red , green and blue pixels have the same value which is 0xAE ). After the first 1920 * 4 pixels non - constant data starts to arrive. Why is this ? Is this the way the sensor outputs data ?
  10. Thanks! This post of the same project also awaits your kind attention:
  11. I did something a little different. I looked at AXI_VDMA.h file and change the contents of PS_IIC.h to be more like it. This is what I did: // I changed the original function prototype : template <typename Func> void MyCallback(void* CallbackRef, int i) { auto pfn = static_cast<std::function<Func>*>(CallbackRef); pfn->operator()(i); } // To this : template <typename Func> void MyCallback(void* CallbackRef, uint32_t mask_or_type) { auto pfn = static_cast<std::function<Func>*>(CallbackRef); pfn->operator()(mask_or_type); } //////////////////////////////////////////////////////////////////////////////////////////////////// // And I changed the original function call : XIicPs_SetStatusHandler (&drv_inst_, &stat_handler_, &MyCallback<void(int)>); // To this : XIicPs_SetStatusHandler (&drv_inst_, &stat_handler_, &MyCallback<void(uint32_t)>); It now compiles well. Can you explain why it didn't work and this solved it ?
  12. This is a snapshot of the settings.
  13. It's a typo - the project IS defined as C++ I'd like to add that NO changes where made to the offending file named: PS_IIC.h It's EXACTLY the same as in the original project.
  14. Hi Ana-Maria, 10 days past since my last post - so I was beginning to loose hope... Thanks for stepping in. Yes I did. By "modified version" I mean that I changed the logic design in Vivado and re-exported the hardware to SDK. When I tried to re-compile the C code inside SDK - I got many errors in various C and Header files. I managed to fix all - except of the one in this post.
  15. Hello, While trying to compile (a modified version of) the 18.2 Zybo PCAM 5 demo inside the SDK I got the following error: no matches converting function 'MyCallback' to type 'XIicPs_IntrHandler {aka void (*)(void*, long unsigned int)}' The error pointed to the following line of code in a file named PS_IIC.h : XIicPs_SetStatusHandler (&drv_inst_, &stat_handler_, &MyCallback<void(int)>); Please explain this error. Notes: 1. The Vivado project compiled correctly and the hardware was exported successfully to the SDK. 2. The PS_IIC.h file and a snapshot of the error message are attached. PS_IIC.h