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->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<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针对大多数的应用场景,根本不需要多高的数据速率,只是简单的电平转换而已,但是用在视频传输上,电平转换的芯片选择就尤为重要了,速率不对,传过来的数据就有可能是错的。芯片选型的时候,一定要充分考虑它的应用场景。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









C++ マルチスレッド デバッグでは、次のように GDB を使用できます。 1. デバッグ情報のコンパイルを有効にします。 2. ブレークポイントを設定します。 3. infothread を使用してスレッドを切り替えます。 5. next、stepi、および locals を使用してデバッグします。実際のケースのデバッグ デッドロック: 1. threadapplyallbt を使用してスタックを出力します。 2. スレッドのステータスを確認します。 3. メイン スレッドにシングル ステップでアクセスし、デッドロックを解決します。

LeakSanitizer を使用して C++ メモリ リークをデバッグするにはどうすればよいですか? LeakSanitizer をインストールします。コンパイル フラグを介して LeakSanitizer を有効にします。アプリケーションを実行し、LeakSanitizer レポートを分析します。メモリ割り当てタイプと割り当て場所を特定します。メモリ リークを修正し、動的に割り当てられたメモリがすべて解放されるようにします。

Xiaomi Mi 15シリーズは10月に正式リリースされる予定で、その全シリーズのコードネームが海外メディアのMiCodeコードベースで公開されている。その中でもフラッグシップモデルであるXiaomi Mi 15 Ultraのコードネームは「Xuanyuan」(「玄源」の意味)です。この名前は中国神話に登場する高貴さを象徴する黄帝に由来しています。 Xiaomi 15のコードネームは「Dada」、Xiaomi 15Proのコード名は「Haotian」(「好天」の意味)です。 Xiaomi Mi 15S Proの内部コード名は「dijun」で、「山と海の古典」の創造神である淳皇帝を暗示しています。 Xiaomi 15Ultra シリーズのカバー

この記事では、実行の一時停止、変数の確認、ブレークポイントの設定に使用される組み込みデバッガー dlv など、Go 関数のデバッグと分析のためのショートカットを紹介します。ログ記録。ログ パッケージを使用してメッセージを記録し、デバッグ中に表示します。パフォーマンス分析ツール pprof は、コール グラフを生成してパフォーマンスを分析し、gotoolpprof を使用してデータを分析します。実際のケース: pprof を通じてメモリ リークを分析し、リークの原因となる関数を表示するコール グラフを生成します。

昨年Huawei Mate60シリーズが発売されて以来、個人的にはMate60Proをメインで使っています。ほぼ1年の間に、Huawei Mate60Proは複数のOTAアップグレードを受け、全体的なエクスペリエンスが大幅に向上し、人々に常に新しい感覚を与えました。たとえば、最近、Huawei Mate60 シリーズは再びイメージング機能の大幅なアップグレードを受けました。 1 つ目は、新しい AI 除去機能で、通行人やゴミをインテリジェントに除去し、空白領域を自動的に埋めることができます。2 つ目は、メインカメラの色の精度と望遠の鮮明さが大幅に向上しました。新学期シーズンであることを考慮して、Huawei Mate60シリーズは秋のプロモーションも開始しました。携帯電話の購入時に最大800元の割引が受けられ、開始価格は4,999元という低価格です。よく使われる、価値の高い新製品が多い

同時実行テストとデバッグ Java 同時プログラミングにおける同時実行テストとデバッグは非常に重要であり、次の手法が利用可能です。 同時実行テスト: 単体テスト: 単一の同時タスクを分離してテストします。統合テスト: 複数の同時タスク間の相互作用をテストします。負荷テスト: 高負荷時のアプリケーションのパフォーマンスとスケーラビリティを評価します。同時実行デバッグ: ブレークポイント: スレッドの実行を一時停止し、変数を検査するかコードを実行します。ロギング: スレッドのイベントとステータスを記録します。スタック トレース: 例外のソースを特定します。視覚化ツール: スレッドのアクティビティとリソースの使用状況を監視します。

PHP 非同期コードをデバッグするためのツールには、次のものがあります。 Psalm: 潜在的なエラーを検出する静的分析ツール。 ParallelLint: 非同期コードを検査し、推奨事項を提供するツール。 Xdebug: セッションを有効にしてコードをステップ実行することで、PHP アプリケーションをデバッグするための拡張機能。その他のヒントには、ロギング、アサーションの使用、ローカルでのコードの実行、単体テストの作成などがあります。

一般的な PHP デバッグ エラーには次のものがあります。 構文エラー: コード構文をチェックして、エラーがないことを確認します。未定義の変数: 変数を使用する前に、変数が初期化され、値が割り当てられていることを確認してください。セミコロンの欠落: すべてのコード ブロックにセミコロンを追加します。関数が未定義です: 関数名のスペルが正しいことを確認し、正しいファイルまたは PHP 拡張子がロードされていることを確認してください。
