Unicam is the driver or the CSI2 receiver on Pi0-4.Is the RP1 CFE replacing the Unicam driver or will Unicam still be supported for setups not using virtual channels?
Pi5 has a totally different hardware block (on RP1 rather than the main BCM2712 SoC), and that is the CFE.
Two drivers for two different bits of hardware.
The mapping of a virtual channel to a certain video device is still a mystery to me. Is there an example how this is done? A search for 'multiplexed streams interface' did not lead to a meaningful result.It has to be configured using the multiplexed streams interface, so the CSI2 link has one link with multiple streams, and then you can choose where to route those streams to in terms of /dev/videoN output nodes (there are 4 memory outputs, or one stream can run through the CFE to produce stats etc).
Are there any general examples available on how to use RP1 CFE, e.g. from your test with the Arducam's V3Link? Beside the mapping of a VC to a video-device, are there any differences in the usage of RP1 CFE compared to Unicam, if the /dev/videoN devices are accessed directly in user code (no use of libcamera)?[/quote]
Still being worked on.
https://github.com/raspberrypi/libcamera/pull/200 is the libcamera update to use it, and goes alongside the kernel changes in https://github.com/raspberrypi/linux/pull/6437. I'm trying to get the same thing working on 6.12 at the moment, but it's now likely to be after the Christmas break.
Virtual channels probably don't help you. Some sensors don't allow you to set the virtual channel and will always use VC 0.I had a look on the FPDLink / V3Link / GMSL SerDes systems. Thank you for the tip. They look interesting and could indeed be a solution for my issue. I will further investigate them. But it could be the case that they may introduce a too big hardware overhead as I would have to serialize and deserialize the video signals at the same physical location, just to merge the streams.
Coming back to our discussion in the old thread. We still have the situation that we hardware trigger both cameras independently and could therefore guarantee there will be no overlapping image streams (only one image from only one camera at the time). But we would still like to keep both cameras in streaming mode in order to save switching time. In the old thread we came to the conclusion that, even though it may not be the cleanest solution, a simple MIPI switch could be used to combine both stream. There could be glitches on the clock lane during switching, but you mentioned that shouldn't be a problem, which I hope is still true? The remaining big issue was mapping the two streams to two different video devices, which seemed hard to do back then. With the now introduced support of virtual channels this problem is also solved. Du you see any major concern in using a simple MIPI switch for combining the streams in our setup?
Glitches in the clock lane won't matter if your sensor does NOT use continuous clock mode, as there will be plenty of LP<>HS transitions.
You may have a hope, but I'm afraid it's not something I have any time to delve into, and none of the libcamera pipeline setup is currently in a position to support it.
Statistics: Posted by 6by9 — Fri Dec 20, 2024 2:52 pm