Confused about the naming of CAM0 and CAM1

[njsss]

The CMIO board schematic shows 4 pins are disabled in CAM0 socket while CAM1 socket has full pins. This correctly corresponds to the documented 2-lane CAM0 and 4-Lane CAM1 blocks inside the compute module. However in the tutorial https://www.raspberrypi.org/documentati ... -camera.md, though GPIO 0-3 are physicically connected to CMIO CAM1 socket (and GPIO 28-31 to CAM0), the dts maps CAMERA_0* with GPIO 0-3.

Code: Select all

pin_define@CAMERA_0_LED { type = "internal"; number = <2>; };
pin_define@CAMERA_0_SHUTDOWN { type = "internal"; number = <3>; };
pin_define@CAMERA_0_UNICAM_PORT { type = "internal"; number = <1>; };
pin_define@CAMERA_0_I2C_PORT { type = "internal"; number = <0>; };
pin_define@CAMERA_0_SDA_PIN { type = "internal"; number = <0>; };
pin_define@CAMERA_0_SCL_PIN { type = "internal"; number = <1>; };

So is Camera_0 the same as the 2-lane CAM0 as mentioned everywhere in the document, but connected to a 4-lane socket CAM1 in the tutorial? Are they basically the same thing?

[6by9]

CAMERA_x_UNICAM_PORT dictates whether you are using the CAM0 or CAM1 connector for the CSI bus routing. All other settings need to then follow suit to connect up the device.

CAM0 only supports 2 CSI2 data lanes.
CAM1 supports 4 CSI2 data lanes.

CAMERA_0... and CAMERA_1.... in the defines correlate to how the user knows the camera modules.

Because CAM1 is the more capable interface, all non-CM Pi variants use CAM1 for the camera interface (even though they only have 2 lanes exposed via the connector).

[njsss]

CAMERA_x_UNICAM_PORT dictates whether you are using the CAM0 or CAM1 connector for the CSI bus routing. All other settings need to then follow suit to connect up the device.

Thank you for pointing it out! Now everything is clear.

Because CAM1 is the more capable interface, all non-CM Pi variants use CAM1 for the camera interface (even though they only have 2 lanes exposed via the connector).

So, in the end, they are the same, since the current pi camera doesn't use any of the CAM1's more capable interface?

Then will future ones do? I'm trying to decide whether to keep 22-pin socket or switch to the 15-pin in a customized board.

[6by9]

Because CAM1 is the more capable interface, all non-CM Pi variants use CAM1 for the camera interface (even though they only have 2 lanes exposed via the connector).

So, in the end, they are the same, since the current pi camera doesn't use any of the CAM1's more capable interface?

Then will future ones do? I'm trying to decide whether to keep 22-pin socket or switch to the 15-pin in a customized board.

Raspberry Pi (Trading) don't publish details of future products in advance of release.

There are devices out there which can use all 4 lanes of CAM1 on the CM3 - the Auvidea B102 (HDMI to CSI2 bridge) is one of them.
The Pi Zero also has the 22pin connector as it is a smaller form factor over the 15pin one. In theory that could have all 4 data lanes populated, but currently it only has 2 due to PCB routing constraints. It does mean that there is a fair availability of camera cables from the 22pin to 15pin form factor.
Ultimately it is your choice - I can't answer it for you.

[LinuxFanatic777]

There are devices out there which can use all 4 lanes of CAM1 on the CM3 - the Auvidea B102 (HDMI to CSI2 bridge) is one of them

Very interesting! Correct me If I wrong, heard that CSI-2 interface can be used for data transmission, not only video capture/output. Is this function supported on Raspberry Pi or perhaps on it's analogues?
Of course, special device with data transmission/reception must be present for this mode.

[6by9]

Very interesting! Correct me If I wrong, heard that CSI-2 interface can be used for data transmission, not only video capture/output. Is this function supported on Raspberry Pi or perhaps on it's analogues?
Of course, special device with data transmission/reception must be present for this mode.

Define your data.

The CSI2 bus is very image-centric. It has signalling for start/end of lines, as well as start/end of frame. Each line is checksummed.
The receiver peripheral on the Pi has parameters for image stride as well as overall buffer sizes. The driver generates an interrupt when the end of frame short packet is received, but also requires an interrupt after the start of frame to know that it is safe to update the buffer pointers (normally done after a number of line interrupts).
If your data comes in as one huge block with no "lines", then you may cause problems due to not swapping buffers at a suitable point.

The V4L2 driver for the receiver is at https://github.com/raspberrypi/linux/bl ... 5-unicam.c. If you have the capabilities then feel free to go and hack it for general reception, but don't underestimate the size of the task.