本来想在源文件改的，但是，文笔不好，思路有点乱了，开个新篇章就当对上一篇文章的升华吧。
首先，摄像头的调试也是一个正常的嵌入式摄像头调试方法。刚开始上手以为人家给写好了，就想偷懒省事是不行的。整体调试过程依然是单板管脚配置->摄像头底层驱动->应用层编写。整体思路与stm32那种嵌入式无异。不过就是更复杂了而已。
其中，单板配置是./load3516文件，海思sdk把上层驱动加载进行了一次封装，可以通过这个文件重新配置寄存器。在加载系统后方便模式切换。
在加载应用程序之前需要先完成相应sensor的配置部分的编写。sensor驱动部分需要配合load文件中的时钟配置，i2c/spi通信方式，以及所需下层的通信协议lvds/mipi、2lane/4lane的配置问题。这部分需要认真调试，认真确定相关寄存器配置到位。datasheet要仔细阅读！
加载完驱动后即可加载应用程序了，应用程序中嵌套着摄像头驱动的相关代码进而驱动整个例程。而sensor底层涉及模式配置寄存器的部分又再次进行了一次封装。需要提前生成.so/.a文件来作为驱动库应用到各个软件中。应用层需要配置的是相关图像大小、颜色配置、通信方式等问题。这些问题需要配合寄存器配置进行相应设置来达到通信目的。
再来说说pqtools以及sample文件的关系，按照官方说法，当配置完成后应该先用sample例程中的其中一个来验证通信链路的正确性然后使用pqtools来调整图像的参数。
所以开始应该确定所需的工具然后按照其中一种来进行调试。我就在这个地方走了弯路，两边同时进行很耗费精力，而且有点像无头苍蝇乱撞，失去方向，建议就先调sample文件的相关参数，驱动更改后一定要全部重新编译防止没有加载上新的驱动文件。调试阶段增加一个版本输出的位置，每次编译都修改一次版本号，方便提示自己驱动是最新版本（这个被坑了好久，以为是配置问题，结果是驱动没更新）。我是使用venc里的图像输出来验证通路的，先图片再视频流，因为视频流还需要网络的配合，这部分可以在pqtools里再来验证。当截图成功时即证明数据链路配置正确，可以尝试pqtools的配置了。pqtools里的参数可以直接拿相关摄像头的参数直接用，这部分主要是显示效果的修改了，毕竟能看见和看的清是两回事。pqtools里如果更新驱动了需要修改配置文件然后重启即可更新驱动。
上位机里，参数修改是pqtools程序，查看视频流是ITTP_stream程序，pqtools在i2c/spi配置成功后即可尝试读取参数，但是图像是无法读取的，在并行通信协议配置成功后即可尝试读取视频流。如果在并行通信没有配置成功时运行 ./HiIspTools.sh -a imx385 时会出现itpp_stream配置错误的提示。这时应该检查并行通信。
最后即可成功输出图像了。下一步尝试修改例程.ヾ(◍°∇°◍)ﾉﾞ
Comments NOTHING