S3C2440A采用IIC总线接口的形式。在主设备发送模式下，它的工作流程为：首先配置IIC模式，然后把从设备地址写入接收发送数据移位寄存器IICDS中，再把0xF0写入控制状态寄存器IICSTAT中，这时等待从设备发送应答信号，如果想要继续发送数据，那么在接收到应答信号后，再把待发送的数据写入寄存器IICDS中，清除中断标志后，再次等待应答信号；如果不想再发送数据了，那么把0x90写入寄存器IICSTAT中，清除中断标志并等待停止条件后，即完成了一次主设备的发送。
视频采集接口原理图如图9所示。
 
图9 视频采集接口原理图
V4L2是Video For Linux Two的简称，Video For Linux API的第二版本，是Linux下开发视频设备程序的接口标准，使用分层方法对所有视频设备的驱动和应用编程提供了一套完备的接口规范[3]。
参照V4L2的标准规范, 设置视频图片的采集及处理过程的流程如下：
 
图10 V4L2的视频图片的采集及处理过程
3.4 视频采集的工作时序及原理
OV9650作为前端传感器，只能工作在从模式下，因此由S3C2440作为主机对OV9650进行配置。其中配置的参数包括采用何种分辨率标准，以及输出数据的格式等。
首先S3C2440A提供24MHZ的时钟采样频率CAMCLKOUT，然后OV9650根据该时钟信号产生三个同步时钟信号反过来再送回S3C2440，摄像头自动控制曝光产生数据输出时钟，帧同步是通过检测VSYN和HREF来进行的。通常在采集过程，对数字信息还进行一定形式的实时压缩处理，较高档的采集卡依靠特殊的处理芯片进行硬件实时数据压缩处理；而那些没实时硬件压缩功能的卡，也可通过电脑上的CPU进行被称为软件压缩的处理。
启动现场视频图像获取程序，在每一个Camp-clk信号驱动中每帧像素的数据开始由高至低形式的传输，也就是响应派送单只8位的Y或者Cb、Cr视频获取数据，数据的传输只在Pclk小幅度上升沿起作用。派送完一帧数据后，Camhref同步信号的水平显示，暗示了下一帧数据派送的启动工作已准备就绪。
视频图像数据在S3C2440A微处理器的摄像头接口和DMA二者中的相互输送有两种不同的方式，也就是说微处理器的摄像接口电路中有两个独立的DMA通道即专注于处理采集数据与显示数据之间格式转换并进行RGB格式的最终存储工作的P预览通道和侧重于保存Ycbcr即具有编解码功能的图片数据库的C编解码通道。而对于本此设计视频图像的显示则采用具有触摸功能的LCD显示屏，选取P预览通道即可达到目的[4]。
3.5 对视频图片数据实施格式的编码及解码
为了克服从开源状态下的Lib Jpeg库内获取相应格式文件的操作的复杂性，本系统提出了方法上的改进，以便更好的实现图像在网络中的实时传输。选用来自IJG( Independent EG Group )的Lib Jpeg库完成视频图片数据的编解码，再将处理后的压缩数据发给网络，进行网络传输。通信速度的快慢受限于数据容量固定的信道带宽和通信链路，而繁杂多样的普通的现场视频监控图像数据对CPU较慢的处理速度和较小的存储容量都提出了巨大的挑战。因此，对于目前的视频监控系统中图像数据的传输与存储都要进行预先的数据压缩处理。
视频的显示其实就是抓拍到的一张一张的图片，以较快扫描速度读取并将获取数据以帧为单位打包派送给显示模块。而对于像素数据来说，采取行方向还是列方向的扫描都是有一定的依据的，因为这之间的相关性才导致了，二者之间的冗余度的存在。这个过程中的数据压缩，启动Lib Jpeg库进行编码就可以显示出或降低冗余度存在的可能性。
Lib Jpeg充分利用了人眼视觉特性，抓住了图像信息传输的本质，从轮廓、纹理思路出发，支持基于视觉内容的交互功能，这适应了多媒体信息应用由播放型转向基于内容的访问、检索及操作的发展趋势，它代表了基于模型、对象的第二代压缩编码技术[5]。Lib Jpeg库解码流程图如图11所示。 基于ARM的视频监控系统设计+源程序+流程图(5):http://www.youerw.com/zidonghua/lunwen_1341.html