RPi Camera bounty

Any technical questions about the Epiphany chip and Parallella HW Platform.

Moderator: aolofsson

Re: RPi Camera bounty

Postby aolofsson » Fri Dec 18, 2015 8:49 pm

Wow, this is outstanding!! Will you be collecting your bounty? :D
Happy New Year!
Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: RPi Camera bounty

Postby tnt » Sat Dec 19, 2015 3:25 pm

Very nice !

I'm travelling for the holidays atm, but I'll definitely give this a shot next week.

BTW a few comments / questions.
- You should definitely update the MODULE_AUTHOR to your name ... I only wrote a skeleton kmod that did nothing useful.
- The 2048 pixel debayering wasn't really a bug imho. I made that as a conscious decision to save BRAMs since only the full raw resolution is > 2048.
- Tab 2 Space ... arghhh you're killing me here :p Official kernel style is TAB and it should be so if we want to push that upstream.
- What's that about LEVEL_SHIFTER ? I ran the interface at 425 Mbps while going through both the flat flex and a .1inch ribbon cable hacked up (before I got the porcupine).

Cheers,

Sylvain
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: RPi Camera bounty

Postby jpwhitt » Sat Dec 19, 2015 8:13 pm

Thanks for the comments Sylvain, I did wonder if you'd chosen the BRAM deliberately - and yes I admit it does seem a bit of a waste of another BRAM block just for an extra 650 odd pixels. I'm not sure what the consensus of opinion would be; resolutions over 1080p or an extra free BRAM block? Personally I think I'd chose the extra resolution, until of course, I ran out of space! However, I'll revert the debayer and restrict the driver to only raw mode over 1080p if you think that's best?

Tab vs spaces - noted. Sorry, force of habit. :oops: I'm from a hardware background and tabs were frowned upon where I used to work.

The LEVEL_SHIFTER define: I couldn't get the camera to transfer data successfully on your original settings for the higher resolutions and my assumption was that the lack of the resistor network described in the XIlinx app note to correct for the difference in logic levels was the reason for this. So I dropped the clock frequency until it worked. If your board also has no resistors added then maybe there's something else wrong with my set-up?

Thanks Andreas, I'll make the changes as above and then submit a pull request.
Seasonal greetings to you also!

Jason
jpwhitt
 
Posts: 4
Joined: Tue Dec 15, 2015 11:35 am

Re: RPi Camera bounty

Postby tnt » Sat Dec 19, 2015 9:03 pm

For the BRAM I guess the best would be to have an option to the vivado IP :)
For pre-built bitstream, it make sense to include support for full resolution because if there is enough free BRAM, might as well use them. But if someone has other logic in there and needs the BRAM, having the option would be nice. Especially if you try to build a core with several cameras core.


For the clock rate it should definitely work without any mods. I'm now using just a normal porcupine with the camera connected with the default flex that was shipped with the camera.

* You didn't include the clock constraints or io standard within the vivado IP core you created. Did you properly add the constraints to your project when building it ?
* Can you check in the build reports that both the clock constraint is applied and that the io standard and differential termination resistors are properly enabled on those IOs ?
* Did you ever try with the pre-built bitstream I posted ?

Here are the constraints I had :

Code: Select all
# Clock
create_clock -period 5.000 -name clk_csi [get_ports {gpio_p[15]}]
set_input_jitter clk_csi 0.150
set_clock_groups -asynchronous -group {clk_csi}

# LVDS for CSI interface
set_property IOSTANDARD LVDS_25 [get_ports {gpio_*[15]}]
set_property IOSTANDARD LVDS_25 [get_ports {gpio_*[17]}]
set_property IOSTANDARD LVDS_25 [get_ports {gpio_*[19]}]
set_property IOSTANDARD LVDS_25 [get_ports {gpio_*[13]}]
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: RPi Camera bounty

Postby jpwhitt » Sat Dec 19, 2015 11:49 pm

Hmm... so, I checked the applied constraints - they all look ok, except I have LVDS on GPIO_*[9:6] which I think is correct according to both the schematic and your rpi_cam.xdc. Then I tried your pre-built bitstream again and that gave me exactly the same corrupted image on 1080p and above.

I might try giving the ribbon cable a bit of a wiggle...

Further investigation will have to wait until the new year though as it's getting late here and I'm travelling early tomorrow. Definitely agree on the Vivado block RAM option, I'll look at including that when I return in the New Year. 'Bye for now.
jpwhitt
 
Posts: 4
Joined: Tue Dec 15, 2015 11:35 am

Re: RPi Camera bounty

Postby tnt » Sun Dec 20, 2015 10:17 am

Arf yeah sorry should be 9:6 ... I took the constraint file from my older test project when I was using my own breakout.
And actually the constraint should be 4 ns (i.e. 250 MHz = 500 Mbps) and not 5 ns.

It'd be interesting to see if the core reports any errors. (like bad ECC or wrong sequence or even fifo overflow or things like that).

I've re-looked at the app note from xilinx and for the receiver, the network is pretty simple. They have series resistor for the LP receivers, but we don't have LP receivers here at all so it's not applicable and the only other thing is that they use a 150 ohm termination resistor instead of the built-in 100R one.

Of course there is also the option that the clock phase is not good. That's why I included IDELAY blocks. I never had to use them myself but maybe I was just lucky. They're fully wired and can be controlled from software so you could try playing with that.

That's how they're controlled.

Code: Select all
 0x04 - PDCR [WO] (PHY Delay Control Register)

        [31]    Load Data Lane 3 IDELAY
        [30]    Load Data Lane 2 IDELAY
        [29]    Load Data Lane 1 IDELAY
        [28]    Load Data Lane 0 IDELAY
        [27]    Load Clock Lane IDELAY
        [4:0]   Delay value to load


So to configure the IDELAY with a value of "10" in the c'lock lane you'd write 0x0800000a to that register.
I don't know if the clock edge needs to be moved forward or backwards so you'll have to try both cases. In one case you only load a delay on the data lanes and leave the clock delay at zero. And in the other case it's the other way around, you leave the data delay at 0 and load a positive value in the clock lane delay.
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: RPi Camera bounty

Postby aolofsson » Sun Dec 20, 2015 9:20 pm

wrt to IDELAYS, I am doing something similar with the new elink, except I gave up on meeting timing with constraints all together. The worst-casing of Vivado makes it impossible to meet timing at 3ns and above.
Instead I send out a pilot sequence of reads from ARM and scan the full range of idelays, then pick the middle of the "good range" where reads actually come back.

https://github.com/parallella/oh/blob/m ... c/e-main.c

Seems to work well...
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: RPi Camera bounty

Postby tnt » Mon Dec 21, 2015 9:31 am

Yeah that's why I included those in the first place and why the core has some error detection / reporting to detect ECC errors and invalid packets.

However we can't just trigger read. You basically need to reset everything including the sensor between each IDELAY tries and see if the data comes back with valid frames which definitely takes a while.
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: RPi Camera bounty

Postby jpwhitt » Fri Jan 08, 2016 6:37 pm

Hi Sylvain, Happy New Year and happy new driver!

The new version includes the facility to set the IDELAY via a sysfs node 'phydelay' and also as a module parameter. I considered automatic IDELAY setting via the error register read back as per Andreas' method but I figured it better to keep it simple, at least initially. Hopefully the default IDELAY value will cover most scenarios - it only needed a shift of one to clean up the transfers, which can be done 'on-the-fly' i.e. whilst the camera is operating.

The phy delay register mapping was slightly different though:-

Code: Select all
 0x10 - PDCR [WO] (PHY Delay Control Register)

        [28]    Load Clock Lane IDELAY
        [27]    Load Data Lane 3 IDELAY
        [26]    Load Data Lane 2 IDELAY
        [25]    Load Data Lane 1 IDELAY
        [24]    Load Data Lane 0 IDELAY
        [4:0]   Delay value to load


It's also possible to read the error register via another sysfs entry, 'errors'. Writing to this clears the register. Incidentally, your pulse transfer module generates two output pulses for every one in - this wasn't intentional was it?

Other updates include frame rate enumeration, a fix for the pixel registration problem in VGA mode and for a bug in RGB565 mode which was a secondary cause of the corruption at high clock rates.

If the default delay setting works on your system then I think it might be ready for inclusion in the main repository?
jpwhitt
 
Posts: 4
Joined: Tue Dec 15, 2015 11:35 am

Re: RPi Camera bounty

Postby igorg » Thu Jan 21, 2016 9:06 am

Hi guys,

there is one question regarding image quality from sensor. Even during daylight conditions the image is full of green tones (see attachment). It looks like something with AEC or AWB features but I'm not sure.
I've tried to switch camera into test pattern generation mode and displayed pattern looks good, so CSI RX core works correctly. I have this issue when controlling camera by Linux driver or Sylvain's standalone application both.

Does anyone was able to get "clean" balanced image by RaPi camera and Zynq? Could you point me to the right sensor registers values probably?

Thanks in advance,

Igor
Attachments
Camerashot#0.jpg
Captured "green" image
Camerashot#0.jpg (273.32 KiB) Viewed 17968 times
igorg
 
Posts: 1
Joined: Thu Jan 21, 2016 8:19 am

PreviousNext

Return to Epiphany and Parallella Q & A

Who is online

Users browsing this forum: No registered users and 4 guests

cron