Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raspberry pi camera v2.1 #1

Open
zappos23 opened this issue Mar 13, 2021 · 3 comments
Open

raspberry pi camera v2.1 #1

zappos23 opened this issue Mar 13, 2021 · 3 comments

Comments

@zappos23
Copy link

Hi @sameer,

Thank you for sharing all your work. I find it very helpful and i learn a lot from it.
I saw you mentioned that there is support for imx219 driver at https://github.com/hdl-util/mipi-ccs.
May i know if imx219 driver is working? I tried it but it doesn't seems to show anything from the camera except arduino logo.

I swapped the ov5647 module to imx219 as below:
imx219 #(.INPUT_CLK_RATE(48_000_000), .TARGET_SCL_RATE(100_000)) imx219 (
.clk_in(CLK_48MHZ),
.scl(MIPI_SCL),
.sda(MIPI_SDA),
.mode(mode),
.resolution(resolution),
.format(format),
.ready(ready),
.power_enable(MIPI_GP[0]),
.model_err(model_err),
.nack_err(nack_err)
);

Beside that there is some timing violations during synthesis not sure if this is a problem.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Slow 1200mV 85C Model Setup: 'mem_pll|altpll_component|auto_generated|pll1|clk[0]' ;
+--------+-------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------+-----------------------------------------------------+--------------+------------+------------+
; Slack ; From Node ; To Node ; Launch Clock ; Latch Clock ; Relationship ; Clock Skew ; Data Delay ;
+--------+-------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------+-----------------------------------------------------+--------------+------------+------------+
; -2.274 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[5] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][5] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.920 ;
; -2.270 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[7] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][6] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.916 ;
; -2.234 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[5] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][4] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.880 ;
; -2.233 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[6] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][5] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.879 ;
; -2.219 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[6] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][6] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.865 ;
; -2.175 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[3] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][2] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.821 ;
; -2.173 ; arbiter:arbiter|fifo:pixel_read_fifo|receiver[2] ; arbiter:arbiter|fifo:pixel_read_fifo|gray_code_chain:gray_code_chain_receiver|value_chain[0][1] ; hdmi_pll|altpll_component|auto_generated|pll1|clk[0] ; mem_pll|altpll_component|auto_generated|pll1|clk[0] ; 0.771 ; 0.014 ; 2.819 ;

@sameer
Copy link
Member

sameer commented Mar 13, 2021

HI zappos23,

Great to hear that you found my work helpful! 🙂

If you're getting the Arduino logo then there are bigger problems so let's figure that out first. It can only come from the default program in the onboard flash memory. How are you trying to load the bitstream?

Unfortunately, I don't have an imx219 handy. I had borrowed one at the time but never got it to work. The problems from what I remember:

  • Power budget: The v2 camera module has a higher start up power requirement than the v1 camera. Not quite sure why, but it causes problems for the MKR Vidor 4000. The board can't boot when powered by USB and the camera is attached so you have to either (1) connect it after starting the board, or (2) temporarily supplement the USB power supply with a LiPo cell via the JST connector
    • Symptoms: can't use the board as a USB blaster, can't put it into flash mode (red light fading in and out)
    • There is some discussion on the forum from what I recall but I don't think the folks at Arduino ever worked it out https://forum.arduino.cc/index.php?board=125.0
  • Register sets: in theory these are supposed to work. I pulled them from the imx219 drivers but I have no way of checking. Ideally I'd be using some combination of oscilloscope + logic analyzer to verify that the i2c lines and mipi lanes are being driven as expected but haven't gotten around to buying one.

Here are some resources that might be helpful in getting it to work:

As for the overall direction of mipi-ccs, I'm considering setting up something to convert the V4L2 linux drivers into the equivalent ones for an FPGA.

@zappos23
Copy link
Author

Hi @sameer,

Thank you for taking time to reply to my questions.

Regarding on how i upload the bitstream, i referred to this github https://github.com/HerrNamenlos123/JTAG_Interface. This is the only method i know of. So far i've tried it on your hdmi-demo project and its working fine. Please let me know if there is other better way to upload bitstream.

I didn't know that the Arduino logo is from default program. Thanks for pointing that out. After not getting anything display on the screen, I went and press the reset button twice. Only after that the logo appeared. So i thought maybe the double reset has caused the board to go back to default program. I will double check on that.

Regarding the power budget - i will try your suggested method #1 connect the camera after booted and see whether its working.

I do not have an oscilloscopes, so i thought maybe i can utilised the JTAG module to send some signals from the camera to SAMD21 for observation. May i know if the data_rx from the i2c_master is from the camera's status register?

Thanks for the documents. Looking forward for your V4L2 Linux driver to fpga conversion!

@sameer
Copy link
Member

sameer commented Mar 19, 2021

Regarding on how i upload the bitstream, i referred to this github https://github.com/HerrNamenlos123/JTAG_Interface. This is the only method i know of. So far i've tried it on your hdmi-demo project and its working fine. Please let me know if there is other better way to upload bitstream.

Interesting, I wasn't aware of this method. It looks like it's doing the same general thing as the one Martino at Arduino shared: https://github.com/vidor-libraries/USBBlaster. The advantage of that approach is it doesn't require running anything on the FPGA. I also wrote one myself: https://github.com/sameer/usbd-blaster.

Regarding the power budget - i will try your suggested method #1 connect the camera after booted and see whether its working.

👍 sounds good

May i know if the data_rx from the i2c_master is from the camera's status register?

The act of driving the i2c lines is correct, that much I'm fairly certain of. Since we don't have logic analyzers, I'm thinking a good setup would be:

  1. Bridge the mipi i2c with the main board i2c.
  • It's normally isolated but you could write a bidirectional i2c bridge in the FPGA. It would drive a line low when it detected that the other line was being driven low and vice versa. Someone out there has probably written one.
  1. Write a quick program for the SAMD21 that can read from the serial console and do register writes.
  2. Experiment!

Thanks for the documents. Looking forward for your V4L2 Linux driver to fpga conversion!

Me too! I got the IMX477 (Raspberry Pi HD camera) so I'll be trying it out with that when I get some time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants