Pixel coprocessor

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I have an analog camara(CVBS) connected to a video decoder, and its digital video output (ITU-R BT601) to the AVR32 ISI.

I have an user program reading frames from capture interface an writing them to framebuffer:

- read a frame (720*576, YUV packets)
- color conversion (YUV422 to RGB)
- writte frame to framebuffer (/dev/fb0)

Using this, I have 10 fps ... which is not enought form me :cry: .
I am thinking two posible solutions.

Sol 1: Use PICO (pipeline operations): I think the color conversion should be faster. Anybody know if any driver is already done for this? (Cause I don't want to reinvent the wheel)

Sol 2: Use /dev/video1 interface.

What do you think would be the better solution?

Thanks in advance,

Regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, there is even an appnote about a very similar setup I think. Look at this http://www.dave.eu/engineering.h...

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PICO works well for color space conversion but if your LCD is greater than 320x240 I suggest you to use the AVR32's Preview Path.

You will have some limitations:
1- max output is 640x480
2- the output format (without conversion) is only 16 bit RGBcolor (framebuffer must be set appropriately)

Using the Dave's board of the appnote suggested by hce and the preview path I'm acquiring a PAL analog signal and show it on a 800x480 LCD @25fps with quite low cpu load.

Regards
Matteo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Thanks by your replies, I will try with preview interface.

I will tell you about results.

Regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

To get a higher fps value, as Pegomat said, I tried to use preview path of ISI.

To use this interface, I took a look to streaming examples suggested by AVR32 AP7 isi app note:

http://www.thedirks.org/v4l2.

I followed this ioctls secuence:
- Init video device:
ioctl(videoDevice, VIDIOC_REQBUFS, &req);
ioctl(videoDevice, VIDIOC_QUERYBUF, &buf[i]);i=0..3;
mmap(NULL, buf[i].length,PROT_READ | PROT_WRITE, MAP_SHARED,videoDevice,buf[i].m.offset);

- Queue buffers:
ioctl(videoDevice,VIDIOC_QBUF,&buf[i]);

- Start streaming: ioctl(videoDevice,VIDIOC_STREAMON,&fmt.type);

All ioctl return success, but whith this last ioctl, kernel starts to output a lot of error messages of the type: "Call trace...Opps: kernel access of bad area.." and I have to swith off the board.

I have STK1006, buildroot2.2.1, kernel2.6.25.10 and my isi config data is:

static struct isi_platform_data __initdata isi_data =
{
.image_hsize = 720,
.image_vsize = 288,
.pixfmt = ATMEL_ISI_PIXFMT_CbYCrY,
.prev_hsize = 360,
.prev_vsize = 144,
.frate = ISI_FRATE_DIV_2,
.gs_mode = ISI_GS_2PIX_PER_WORD,
.streaming_v4l2_fmt = V4L2_PIX_FMT_RGB555X,
.cr1_flags = ISI_EMB_SYNC | ISI_FULL ,
};

Pegomat, could you tell me ioctls secuence you followed and if you see any mistake in my code?

Do you know if there is any little example of how to use this interface properly? (something similar to capture.c)

Best regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi jck,

have you tried to stream with mplayer?

mplayer -tv driver=v4l2:noaudio tv://

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the ioctl sequence seems OK.

from your configuration I suppose that the streaming is intelaced...

what kind of video decoder are you using?

If you need, I have a test program to stream from isi to framebuffer. It also take care of the interlaced stream (duplicating each line of the field).

regard
Matteo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Mateo,

My camera provides CVBS PAL signal to ADV.

I am using an ADV7180 who provides a ITU-R BT 601 digital stream (each frame contains 720x576 pixels)to ISI. (Same that DAVE AN-ENG-001 note).

First 720*288 pixels correspond to odd lines so I configured image_hsize an image_vize on that way.

As I want to use preview path, and as 2D Image Scaler output of preview path is 640x480 I configured prev_hsize = 360, and prev_vsize = 144. (maybe is this wrong?)

It would be very nice if you could give your test program.

Thanks a lot by your help.

Regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jck_ives82 wrote:

First 720*288 pixels correspond to odd lines so I configured image_hsize an image_vize on that way.

As I want to use preview path, and as 2D Image Scaler output of preview path is 640x480 I configured prev_hsize = 360, and prev_vsize = 144. (maybe is this wrong?)

It's ok, because the 2D scaler apply the same ratio for both horizontal and vertical size.

The test program is attached:
There are a lot of hard coded values you must change.
(My preview path output is 640x240!)

Inside you can find also an example how to use PICO for color space conversion.

Let me know if you make it work! :)

The driver may also work with mplayer but without halfword swap, so for each line you will have even and odd pixel inverted.

Regards, Matteo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I will try it inmediately.

Thanks again,

Regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi¡

Your code has helped me a lot, finally I am using capture interface with the PICO functions of your code and I have adquiring video quite fast with very CPU load¡ Thanks a lot. :lol:

Unfortunately, streaming interface of your test code is giving me same errors as I described before, so I suspect may be there's something wrong in my configuration or in the streaming functions of the driver(atmel-isi.c of kernel 2.6.25.10). Could you tell me what kernel version are you using?

Anyway, capture interface with pico is enough for me by now.

As not all can be always good news, here the bad news :cry: :

Sometimes, when I execute my capture program, the image of the screen get desynchronize, a vertical black line appears (hsync) appears in the middle of the screen..is as the lcd controller was reading frame buffer with nok timings.. and I have to reboot the board to get the lcd controller run well again.

I read in other posts that this could be a lcd dma priority conflict with cpu...I don't think this could be a timing problem becouse with an static image there's no problem.

Did you have this problem?

Thanks in advance, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm using kernel 2.6.25.10 but a different version of atmel_isi.c

jck_ives82 wrote:

Sometimes, when I execute my capture program, the image of the screen get desynchronize, a vertical black line appears (hsync) appears in the middle of the screen..is as the lcd controller was reading frame buffer with nok timings.. and I have to reboot the board to get the lcd controller run well again.

I read in other posts that this could be a lcd dma priority conflict with cpu...I don't think this could be a timing problem becouse with an static image there's no problem.

Did you have this problem?

I don't a have this problem, not related to isi streaming, because I'm using the preview path

I think you are right, it's a memory bandwidth related problem.
I try to explain what I thing is your problem:
Using the capture interface and PICO for conversion you need to access multiple time to memory:

1st: ISI capture [720 x 288 x 2 x FR]
2nd: read buffer and write to PICO [720 x 288 x 2 x FR] (only once because PICO has a separate bus)
3rd: read output from PICO and write it to Framebuffer [360 x 144 x 3 x FR x 2] (I suppose you perform the decimation to a lower resolution)

for FR=25fps you will have:
10,368 + 10,368 + 0,7776 = 28,512 MB/s

compare it with your memory bandwidth.

using the preview path you will have:
1st: [360 x 144 x 2 x FR]
2nd: read buffer [360 x 144 x 2 x FR]
3rd: write to framebuffer [360 x 144 x 2 x FR x 2]
= 10,368 MB/s

Maybe you can slow down the framebuffer to free some bandwidth...

regards
Matteo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

You are right.

To reduce needed bandwidth what I did is to reduce the size of the displayed video.

I read 720*288*2 bytes from ISI but I only pass 360*288*2 first bytes to PICO and to framebuffer. In this way, I have a smallest image, but no desynchronize is produced by now. (1 hour running continuosly).

Regarding to streaming, you say you are using a different atmel-isi.c, I suppose then you fix any bug in the original driver?

Regards, jck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope this is the solution you need.

I'm using the driver originally developed by Dave before Atmel released their own... and I modified it to use the preview path.

Maybe in the future i will merge my driver with the official one.

Regards, Matteo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jck_ives82 wrote:
I am using an ADV7180 who provides a ITU-R BT 601 digital stream (each frame contains 720x576 pixels)to ISI. (Same that DAVE AN-ENG-001 note).

 

Could you share schematics for the ADV7180 chip?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gortu wrote:
Could you share schematics for the ADV7180 chip?

 

You mean the DATASHEET?

 

http://www.analog.com/media/en/t...

 

Google is your friend.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Gortu wrote:

Could you share schematics for the ADV7180 chip?

 

 

You mean the DATASHEET?

 

I mean .brd file for a breakout board of the ADV chip (can be other format, and .sch too)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you aware that this thread is over 8 years old and most of the links in it are no longer valid?

 

 

Analog Devices offers a board for the purposes of evaluating the device:

 

http://www.analog.com/en/design-...

 

There should be schematics and a board layout in the documentation...Usually when I order an Eval board from them there is.  Otherwise you are probably not going to get anywhere here.

 

 

Jim

 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user