国产mipi口fpga好像挺多的，去看一下？

【 在 oBigeyes 的大作中提到: 】
: 先不考虑lattice推的fpga方案。
: 谢谢！
--
FROM 221.219.3.*

什么叫2路合成1路？净切换？拼接？叠加？

【 在 oBigeyes 的大作中提到: 】
: 先不考虑lattice推的fpga方案。
: 谢谢！
:
--
FROM 117.107.176.*

不要切换的。

用虚拟通道合并传输，或者拼接起来，都行



【 在 whx83 的大作中提到: 】
: 什么叫2路合成1路？净切换？拼接？叠加？
--
修改:oBigeyes FROM 58.38.123.*
FROM 58.38.123.*

这我觉得不会有，只能用fpga方案

你想想哈，如果有这种芯片，且不说有没人用，即便是最简单的拼接方案，帧率同步，不同分辨率如何拼接，光是这些问题如何和使用者交互（利用寄存器），有把这些设计出来的时间，fpga方案早就做好10遍了。。。。


【 在 oBigeyes 的大作中提到: 】
: 先不考虑lattice推的fpga方案。
: 谢谢！
:
--
FROM 113.132.222.*

cpu板上咋合到一起的？

如果是全部4个画面都到内存，那就会好解决一些，如果是用芯片不缓冲去拼接的，很多问题都不好解决

你这个问题我觉得主要是芯片化无法解决各种情况下的配置交互问题，如果你本身帧率一样，分辨率一样的，帧同步可以有所牺牲，并且其他很多参数都能定下来，那么相当于解决了配置交互问题，但是这样一来，这个芯片几乎没有了其他使用场景，所以也就没有了价值，应该不会有人做的。

你现在这个场景我感觉fpga也不是好的办法，即便L家有所谓的解决方案的代码，反而你说的去cpu板的这种方法我觉得好一些，现在的嵌入式处理器基本都带mipi接口，并且都有一些image processer可以做拼接工作，这种方式自带缓冲，所以很多同步问题比较好处理，利用gstreamer之类的软件去交互也很方便，另外处理器本身还可以干点别的事情，fpga就没这么灵活了。

【 在 oBigeyes 的大作中提到: 】
: 车上有实现这种功能的，但是都是通过serdes传输到CPU板上以后合成为一路。一般是4
: 合1。
: 想找没有serdes的解决方案。
: ...................
--
FROM 113.132.222.*