TI Omap37xx 系列MPU调试 SE4500扫描头2D扫软解记录

虽然摩托罗拉现在也出售给了斑马公司，但针对行业设备的支持还说的过去，但是网上针对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()函数中，具体修改如下：

<pre name="code" class="cpp">	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-&gt;nNumBuffers = pDev-&gt;dwBufferCount;
			pAllocReq-&gt;nBufferSize = pDev-&gt;dwBufferSize;
			// Save the caller handler
			pDev-&gt;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, &amp;pVirtAddr))
				{
#if (CE_VERSION == 5)
					pAllocReq-&gt;ppBuffers[i] = (DWORD )MapPtrToProcess(pVirtAddr, hCaller);
#endif
#if ((CE_VERSION == 6) || (CE_VERSION == 7))
					pAllocReq-&gt;ppBuffers[i] = (DWORD)VirtualAllocCopyEx(GetCurrentProcess(), hCaller,
						pVirtAddr, pDev-&gt;dwBufferSize, PAGE_READWRITE);
#endif
					// Save it in the driver context for freeing this memory later
					pDev-&gt;baseAddr[i] = pAllocReq-&gt;ppBuffers[i];
				}
				else
				{
					pVirtAddr = NULL;
					pAllocReq-&gt;ppBuffers[i] = (DWORD)NULL;
				}
				DEBUGMSG(ZONE_IOCTL, (TEXT("SE4500 : App:0x%x mapped from Kernel:0x%x\r\n"),pAllocReq-&gt;ppBuffers[i], pVirtAddr));
			}
			*pdwActualOut = sizeof(DWORD) * (pDev-&gt;dwBufferCount - 1) +
							sizeof(SE45_ALLOC_BUF_REQ);
#if (_WINCEOSVER<br>

<pre class="brush:php;toolbar:false">

       后来就考虑直接在系统驱动里面，将获取到的图像直接保存到文件，这里似乎有一个问题，保存文件操作是在单独的一个线程里面做的，是异步操作，有可能出现保存数据只有部分的情况。经过多次测试，传输过来的图像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针对大多数的应用场景，根本不需要多高的数据速率，只是简单的电平转换而已，但是用在视频传输上，电平转换的芯片选择就尤为重要了，速率不对，传过来的数据就有可能是错的。芯片选型的时候，一定要充分考虑它的应用场景。