虽然摩托罗拉现在也出售给了斑马公司，但针对行业设备的支持还说的过去，但是网上针对se4500在ti omap平台的调试文章少之又少，不信你随便搜搜互联网。 公司使用的是ti(德州仪器)公司提供的方案omap37xx系列mpu，系统是wm6.5(windows mobile 6.5.3)的，调试
       虽然摩托罗拉现在也出售给了斑马公司，但针对行业设备的支持还说的过去，但是网上针对se4500在ti omap平台的调试文章少之又少，不信你随便搜搜互联网。
       公司使用的是ti(德州仪器)公司提供的方案omap37xx系列mpu，系统是wm6.5(windows mobile 6.5.3)的，调试到se4500的时候，开始是i2c问题，i2c死活不通，后来解决了i2c读写问题，但是在上层应用层调用对应的api获取图像数据，就直接崩溃了，但是地址打印出来，还是可以看到对应的地址的，但是使用isbadptr测试该指针以后，不可以读，只要一读，直接崩溃(data abort)。
       这个问题是这样的，需要修改摩托罗拉提供的驱动程序的部分代码，修改基本上如下：
       驱动添加根据motorola\motorola software decode sdk for arm\drivers\ti\cam_se4500\wm65 目录下的readme.txt操作，
在对应的drvr_intf.cpp源文件的cam_iocontrol()函数中，具体修改如下：
case se45_ioctl_alloc_buffer: if ((pbufout == null) || (dwlenout dwbuffercount - 1) * sizeof(dword))) || (pdwactualout == null)) { dwreturn = error_invalid_parameter; goto badparameter; } else { uint i, noutputbytecount; pse45_alloc_buf_req pallocreq; handle hcaller; pbyte pvirtaddr; //wince5.0.2内核限制，所以必须增加该判断#if (_winceosverdwbuffercount - 1) * sizeof(dword);#if (ce_version == 5) //hcaller = getownerprocess(); //为什么要注释掉上面一行代码，改成下面这行？因为调用的同时，他们应该是同一进程地址空间 hcaller = getcurrentprocess(); pallocreq = (pse45_alloc_buf_req )mapcallerptr( pbufout, noutputbytecount );#endif#if ((ce_version == 6) || (ce_version == 7))// hcaller = openprocess(0, false, getcallervmprocessid()); hcaller = openprocess(0, false, getdirectcallerprocessid()); // ce 6 automatically marshals the ioctl parameters mapcallerptr() is obsolete pallocreq = (pse45_alloc_buf_req)pbufout;#endif if (null == pallocreq) { dwreturn = error_invalid_parameter; goto badparameter; } // reset the user buffers in the low level driver camera_reset_buffers(pdev); pallocreq->nnumbuffers = pdev->dwbuffercount; pallocreq->nbuffersize = pdev->dwbuffersize; // save the caller handler pdev->dstprocess = hcaller; /* return a list of buffer start addresses mapped to caller's process space */ for (i = 0; i dwbuffercount; i++) { if (camera_get_buffer_addr(pdev, i, &pvirtaddr)) {#if (ce_version == 5) pallocreq->ppbuffers[i] = (dword )mapptrtoprocess(pvirtaddr, hcaller);#endif#if ((ce_version == 6) || (ce_version == 7)) pallocreq->ppbuffers[i] = (dword)virtualalloccopyex(getcurrentprocess(), hcaller, pvirtaddr, pdev->dwbuffersize, page_readwrite);#endif // save it in the driver context for freeing this memory later pdev->baseaddr[i] = pallocreq->ppbuffers[i]; } else { pvirtaddr = null; pallocreq->ppbuffers[i] = (dword)null; } debugmsg(zone_ioctl, (text(se4500 : app:0x%x mapped from kernel:0x%x\r\n),pallocreq->ppbuffers[i], pvirtaddr)); } *pdwactualout = sizeof(dword) * (pdev->dwbuffercount - 1) + sizeof(se45_alloc_buf_req);#if (_winceosver

后来就考虑直接在系统驱动里面，将获取到的图像直接保存到文件，这里似乎有一个问题，保存文件操作是在单独的一个线程里面做的，是异步操作，有可能出现保存数据只有部分的情况。经过多次测试，传输过来的图像752 x 480分辨率始终是条纹状，要么颜色不对，基本上都是如下图像：
在驱动图像帧回调函数中保存了这些图片，基本上过来30多张只有一两张还能看得到图像，其他基本上都是斜的条纹，颜色明显不对，正常的颜色是应该是黑白单色。后来查硬件问题，发现是pclk的电平转换芯片的最大支持频率不够，和其他公司一样，你使用ti的方案，那周边的什么pmic，电平转换芯片等等都用他的，做高通、mtk的也都一个样。
       本来用的是txs0104/08针对se4500的pclk过来的3.3v电平，转换成1.8v的提供给omap37xx，结果发现txs0104/08在vcca为1.8v时最大支持的data rate只有24mbps(参考该电平转换芯片手册)，远远不够。
       前前后后折腾了几个月，没有解决这个问题，后来换成了txb0104/08系列电平转换芯片，用了摩托提供的c#写成的sdl_gui测试程序，se4500出光了以后直接就解码了。
         至此，问题已经得到解决，但是总结一点。也许是ti针对大多数的应用场景，根本不需要多高的数据速率，只是简单的电平转换而已，但是用在视频传输上，电平转换的芯片选择就尤为重要了，速率不对，传过来的数据就有可能是错的。芯片选型的时候，一定要充分考虑它的应用场景。