Few questions about VPFE.

jay19494

Prodigy 20 points

Hi~ everybody. [:D]

now i'm working with a dm365 and looking through VPFE User Guide( sprufg8a ).

there's something that i couldn't understanding about VPFE...

1. if CCD/CMOS hardware input is 8 bit, the ISIF convert to 16 bit automatically ?

or need to configure some registers?

2. if i need to configure.. which register do i need to change? ( register and setting value.)

3. one guy say to me like " BT.656 input have to use one-shot mode"

but.. what is one-shot mode?

and if i use that mode.. which register do i need to change?

just i want to capture(v4L2) the camera Image from the SDRAM after IPIPE(RZA) block.

but it's too hard for me [:'(]

please give a good answer..

thank you.

over 15 years ago

0 Juan Gonzales over 15 years ago

TI__Mastermind 37340 points

jay said:

now i'm working with a dm365 and looking through VPFE User Guide( sprufg8a ).

there's something that i couldn't understanding about VPFE...

1. if CCD/CMOS hardware input is 8 bit, the ISIF convert to 16 bit automatically ?

2. if i need to configure.. which register do i need to change? ( register and setting value.)

DM365 ISIF hardware can support up to 16-bit pixel input. If the external CCD/CMOS hardware you chose is limited to 8-bits, then ISIF can be programmed to store these 8-bit inputs per table 5 in VPFE UG. Does your CMOS sensor output 8-bit pixels, or 16-bit pixels via 8-bit data bus (2 clocks per pixel)? Either way, you should be able to use "MODESET.PACK8" register as described in VPFE UG to achieve the desired result.

With regards to one-shot mode (versus continuous), it may help to think about it like an assembly line where SDRAM allows you to buffer some data as this data moves along the different VPFE processing blocks (assembly points). When data passes directly from one processing block to the next without any SDRAM buffer, the next processing block needs to operate in continuous mode (default) to make sure it keeps up with the data coming in without braking the assembly line ; however, when data is placed in SDRAM buffer, you have the option (you do not have to) to operate in one shot mode since previous block can just keep buffering data in SDRAM until current processing block is ready. In one-shot mode only one frame is processed and requires user action to start the next frame, hence it gives you flexibilty on how fast you want to process. That said, I do not believe there are any restrictions on BT.656 having to operate in one-shot mode, although it the path is BT.656 via CCDC input --> SDRAM ---> resizer, it certainly can operate in one shot mode if desired...Registers for one shot mode for various stages of processing are defined in VPFE UG (search for ONE)

0 jay19494 over 15 years ago in reply to Juan Gonzales

Prodigy 20 points

i'm really appriciate hearing your answer.

still try to understand.. hehe [:)]

thank you

0 Digant Desai over 15 years ago in reply to jay19494

Expert 1225 points

Hi,

I am having similar kind of problem here.I am using Dm355 & Monta Vista 5.

I am using sensor with each pixel of 16 bit & giving out 8 bit data & 2 clock per pixel.

I have defined new STD in capture driver & kept buffer size 3000 x 1000 as my sensor size is 3M Pixels.

now the problem with my CCDC is ,

I have a provision to generate test patterns on my data lines from my sensor and I am generating 1234 & 5678 (16,16 bits=2 pixels alternatively).

Case 1: I am getting 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78 34 78... when I read the memory from buffer.START in char mode.

In this I have kept pixel data size of 8 bits & a-law disabled.

Case 2: I am getting 00 34 00 78 00 34 00 78 00 34 00 78 00 34 00 780 0 34 00 78......When I read the memory from buffer.START location char mode.

In this I have kept pixel data size of 12 bits & a-law disabled.

Now my questions are,

1- where are 12 & 56 ...first bytes of each patterns ??? :(

2- Whether any other way to check what I have received exactly??

3- My assumption in 1st case my data is PACKED is correct ???

4- Is my buffer size alright ?? as I am actually applying 6 M times - 8 bits of data , considering 8+8 bits per pixel in two clocks??

0 Jinh over 15 years ago in reply to Juan Gonzales

Expert 2315 points

Following Juan's answer, I am trying to insert data per field on the DM365 and have also questions about one-shot mode and continous mode if it applies to the Pass-Through setting in the demo code. Firstly when I run fbdev_loopback demo then the original fields from the input buffer is just coipied over to the output/display buffer and my field data is kept as is and displayed but when I run the encodedecode demo and even in -p mode my second field is duplicated into my first field and I loose half my data. From the VPFE and v4l2 documentation I can see that when the resizer and encoder is enabled this will happen - also something to do with continouos mode - but from the comments in the code in encodedecode demo and what I understand the data in passthrough mode should not change like I see it is doing now. Please help me to resolve if there are problems with buffer handling or setting up the attributed of the mode. In my application, derived from encodedecode, I do not wish to use the resizer or encoder and want to keep field information in place like in the fbdev_loopback demo. Please help me on this one.

Thanks, Jinh T

0 Digant Desai over 15 years ago in reply to Jinh

Expert 1225 points

I am using 3000 x 1000 sensor with 2 clock for one pixel mode.8 + 8 bits.

I have defined 6MB buffer in VPFE & getting only 3MB data though my H & V sync are perfect.

Where is the problem??? I am not able to find even the cause of the problem. I have tried both packed & unpacked mode !!

I am using Dm355 & Monta vista 5.

Please help.

0 Luke Postema over 15 years ago in reply to Digant Desai

Intellectual 700 points

Are you using User-space allocation of the buffer or kernel space allocation? Kernel space allocation may be limited by the maximum buffer size it can allocate.

0 Juan Gonzales over 15 years ago in reply to Luke Postema

TI__Mastermind 37340 points

Another thing to think about is how does the CCD capture interface know if you are inputting 8-bit pixels (one clycle) or 16-bit pixels (takes two cycles with an 8-bit interface). I do not believe there is a way to specify this for RAW mode.

My understanding is that you can use up to 14-bit pixels in RAW mode (14-bit interfacein RAW mode) which by default are stored in 16-bits (two bytes) in SDRAM; optionally, you can choose to use 8-bit input interface along with PACK8 setting to store 8-bit pixels in every byte of SDRAM. This means that if you want store 3000x1000 16-bit pixels, you may need to define your video frame to be 6000x1000 8-bit RAW PACK8 input. In RAW mode, the DM6467 does not care what data is at the input, it simply grabs as many bits as you tell it per pixel clock (8bits in this case) and places them in SDRAM (in either one byte or two depending if PACK8 is set).

0 Digant Desai over 15 years ago in reply to Juan Gonzales

Expert 1225 points

Thx juan . I did it.

I was also thinking the same , your reply added confidence.

Now the issues is I am getting 6MB Buffer mmaped @ user space.

I was using the following code to store array into filesystem & was working fine with 3000 x1000 image size.

    fp = fopen("Original.raw","wb");
    fwrite(buffer_addr.start,1,CAP_WIDTH * CAP_HEIGHT * 1,fp);
    fclose(fp);

here buffer_addr.start is the start location of hte image retuned from mmap.

But now its showing segmentation fault.Can u tell me Y ? and do you have any other way to get the received image data into filesystem ???

Thak you again fro your help

0 Juan Gonzales over 15 years ago in reply to Digant Desai

TI__Mastermind 37340 points

segmentation fault would imply a problem with buffer_addr.start

Can you post the code where the buffer gets allocated and mmapped?

0 Digant Desai over 15 years ago in reply to Juan Gonzales

Expert 1225 points

I have been able to store the IMAGE now.The problem was I was initializing the pointer with wrong address.

Thx Juan.

But now I am getting some thing strange,

I have an test pattern generator using that I am testing VPFE.

I found the data has been copied into next following address & this was also happening the day before I altered the buffer size.

The output of the pattern generator is when I am setting the random output mode(on every pixel clock it generated random 8 bit data)

8e 8e f3 f3 fc fc 11 11 90 90 cc cc fc fc 1 1 90 90 94 94 fc fc d d 90 90 87 87 fc fc 4 4 90 90 e6 e6 fc fc 77 90 90 aa aa fc fc 2 2 91 91 7b 7b fc fc a a 8f 8f b7 b7 fc fc a a 91 91 6c 6c fc fc 3 3 91 91 5f 5f fb fb fd fd 90 90 6a 6a fc fc 5 5 90 90 6d 6d fc fc 3 3 91 91 bb bb fc fc 4 4 8f 8f b0 b0 fc fc 3 3 91 91 ca ca fb fb fe fe 90 90 88 88 fb fb ff ff 90 90 6d 6d fc fc 2 2

And for test pattern from generator is,
55 55 55 55 aa aa aa aa 55 55 55 55 aa aa aa aa 55 55 55 55 aa aa aa aa 55 55 55 55 aa aa aa aa 55 55 55 55 aa aa aa aa ...

I am getting @ DM355's memory ,

55 55 55 55 55 55 55 55 aa aa aa aa aa aa aa aa 55 55 55 55 55 55 55 55 aa aa aa aa aa aa aa aa ...

For the test pattern I have checked the pixel clock and the data lines, they are fine on OSCILLOSCOPE also.

Please help

0 Juan Gonzales over 15 years ago in reply to Digant Desai

TI__Mastermind 37340 points

I have looked at the errata and VPFE UG and cannot readily see an obvious reason why the data would be placed as suggested above. One potential cuase may be if DM355 resizer is enabled and trying the scale the picture by 2x, thereby duplicating the pixel information.

0 Anshuman Saxena over 15 years ago in reply to Juan Gonzales

TI__Mastermind 19985 points

Juan,

although, i dont know the reason of this problem, I dont think the resizer would repeat the data so evenly. It uses some filters which use nearby pixels to generate new pixel data. So it is unlikely that resizer would generate exactly same data for a 2X upsample.

Regards.,

Anshuman

0 Juan Gonzales over 15 years ago in reply to Anshuman Saxena

TI__Mastermind 37340 points

Anshuman,

Thank you for clarifying this.

0 Digant Desai over 15 years ago in reply to Juan Gonzales

Expert 1225 points

I am not using re-sizer / ipipe at all...I am also not using medial filter.

here is my CCDC register settings....

Reading 0x0 to SYNCEN...
Reading 0x800 to MODESET...
Reading 0x0 to HDWIDTH...
Reading 0x0 to VDWIDTH...
Reading 0x0 to PPLN...
Reading 0x0 to LPFR...
Reading 0x0 to SPH...
Reading 0x177f to NPH...
Reading 0x1 to SLV0...
Reading 0x1 to SLV1...
Reading 0x3e7 to NLV...
Reading 0xffff to CULH...
Reading 0xff to CULV...
Reading 0xbc to HSIZE...
Reading 0x0 to SDOFST...
Reading 0x0 to STADRH...
Reading 0x0 to STADRL...
Reading 0x0 to CLAMP...
Reading 0x0 to DCSUB...
Reading 0x4e4e to COLPTN...
Reading 0x0 to BLKCMP0...
Reading 0x0 to BLKCMP1...
Reading 0x0 to MEDFILT...
Reading 0x100 to RYEGAIN...
Reading 0x100 to GRCYGAIN...
Reading 0x100 to GBGGAIN...
Reading 0x100 to BMGGAIN...
Reading 0x0 to OFFSET...
Reading 0xfff to OUTCLIP...
Reading 0x95 to VDINT0...
Reading 0x0 to VDINT1...
Reading 0x0 to RSV0...
Reading 0x8 to GAMMAWD...
Reading 0x0 to REC656IF...
Reading 0x8000 to CCDCFG...
Reading 0x0 to FMTCFG...
Reading 0x0 to FMTPLEN...
Reading 0x0 to FMTSPH...
Reading 0x0 to FMTLNH...
Reading 0x0 to FMTSLV...
Reading 0x0 to FMTLNV...
Reading 0x0 to FMTRLEN...
Reading 0x0 to FMTHCNT...
Reading 0x0 to FMT_ADDR_PTR_B...
Reading 0x0 to FMTPGM_VF0...
Reading 0x0 to FMTPGM_VF1...
Reading 0x0 to FMTPGM_AP0...
Reading 0x0 to FMTPGM_AP1...
Reading 0x0 to FMTPGM_AP2...
Reading 0x0 to FMTPGM_AP3...
Reading 0x0 to FMTPGM_AP4...
Reading 0x0 to FMTPGM_AP5...
Reading 0x0 to FMTPGM_AP6...
Reading 0x0 to FMTPGM_AP7...
Reading 0x0 to LSCCFG1...
Reading 0x0 to LSCCFG2...
Reading 0x0 to LSCH0...
Reading 0x0 to LSCV0...
Reading 0x0 to LSCKH...
Reading 0x0 to LSCKV...
Reading 0x0 to LSCMEMCTL...
Reading 0x0 to LSCMEMD...
Reading 0x0 to LSCMEMQ...
Reading 0x0 to DFCCTL...
Reading 0x0 to DFCVSAT...
Reading 0x0 to DFCMEMCTL...
Reading 0x0 to DFCMEM0...
Reading 0x0 to DFCMEM1...
Reading 0x0 to DFCMEM2...
Reading 0x0 to DFCMEM3...
Reading 0x0 to DFCMEM4...
Reading 0x0 to CSCCTL...
Reading 0x0 to CSCM0...
Reading 0x0 to CSCM1...
Reading 0x0 to CSCM2...
Reading 0x0 to CSCM3...
Reading 0x0 to CSCM4...
Reading 0x0 to CSCM5...
Reading 0x0 to CSCM6...
Reading 0x0 to CSCM7...
Reading 0x0 to DATAOFST...

I am also confused why this is happening :(

0 Digant Desai over 15 years ago in reply to Juan Gonzales

Expert 1225 points

I am not using re-sizer/ipipe/median filters at all..

here is my CCDC register list...

I am also confuse.Why this is happening ...

0 Juan Gonzales over 15 years ago

TI__Mastermind 37340 points

jay said:

1. if CCD/CMOS hardware input is 8 bit, the ISIF convert to 16 bit automatically ? or need to configure some registers?

2. if i need to configure.. which register do i need to change? ( register and setting value.)

3. one guy say to me like " BT.656 input have to use one-shot mode" but.. what is one-shot mode? and if i use that mode.. which register do i need to change?

1) If we are talking RAW CCD sensor input (as opposed to BT.656), our hardware will take CCDC 8 to 16 bit CCD input (e.g. it could be 12-bit pixels); because of this, by default the hardware stores each pixel in 16-bits (two bytes) in SDRAM. That said, if the CCD input is 8-bits wide, then you can configure the register to store one pixel per byte (as opposed to two-bytes) in SDRAM by using PACK8 feature. If you are doing BT.656 input (8-bit interface but 16-bit pixels, one pixel every two clocks), then the hardware is smart enough when in this mode (two registers to configure this mode) to store each pixel in 16-bits in the proper format.

2) This depends on your input, our demos (encode, decode, encodedecode) should give you a pretty good idea of how to configure the interface as they support SD as well as HD video input. You will likely not need to do anything at the register level, there are user space defined interfaces (e.g. V4L2 vide capture Linux standard) to control video capture settings.

3) From a hardware perspective, you do not need to use BT.656 in one-shot mode; In one-shot mode only one video frame is processed thru IPIPE (e.g. for resizing) at a time and CPU is involved in initiating the processing of the next frame; in contrast, in continous mode, next video frame is processed automatically which also means having to ensure that there is valid data ready for IPIPE to process as soon as it needs it.

Hope this helps....

Processors

Processors forum

Few questions about VPFE.