Dear 6by9,
thank you for your answer.
Things are now much clearer to me, but I still have a few follow-up questions. I would be happy if you could answer them.
Is the RP1 CFE replacing the Unicam driver or will Unicam still be supported for setups not using virtual channels?
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)?
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?
Thank you,
Marc
thank you for your answer.
Things are now much clearer to me, but I still have a few follow-up questions. I would be happy if you could answer them.
Is the RP1 CFE replacing the Unicam driver or will Unicam still be supported for setups not using virtual channels?
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)?
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?
Thank you,
Marc
Statistics: Posted by marcp — Thu Dec 19, 2024 3:38 pm
