古いシナリオ

以前、専用ATSテスト基板を作成する際に、通常のデバッグシリアルポートとドッキングする方法を適用しました(https://blog.csdn.net/engrossment/article/details/103064310)、この案はカスタマイズされた基板に適用される.彼はシリアルポートを経由してUSBチップCH 340を回転しないため、測定される基板上でこれは漏れ測定に属する.

シナリオ1

既存のシリアルポート転送USB独立モジュールを採用し、測定対象ボードのMicro USBポートに接続し、シリアルポートに変換した後、他の一般的なシリアルポートとドッキングし、データ送受信テストを行う.しかし、実測の際、ボードカードとモジュール上の2つのCH 340がドッキングし、まったく認識されず、通信できないことに気づいた.
シナリオは実行できません.

シナリオ2

シナリオ1の実測結果解析から,ドッキングしたシステムはCH 340を認識しなければデータ通信テストを行うことができないことに気づいた.そこで、Micro USBケーブルでボードカード自身のUSBホストを取り戻すのはいかがでしょうか.USBデバッグシリアルポートを考慮してパソコンに接続する場合、Windowsで対応するドライバを提供する必要があります.チップ駆動を専門に取り付けたり、汎用駆動(win 10)を使用したりします.では,我々はボードカードのLinuxにおいても,CH 340を識別し,デバイスノードを生成してシリアル通信を行う駆動が必要である.
ドライバの同僚の検証を経て、私たちの現在のバージョンのカーネルはすでにCH 340のドライバを統合して、menuconfig構成の上で更にコンパイルすればいいです.
実測により、駆動を追加した後、USBデバッグシリアルラインを通じてUSB TO UARTデバッグシリアルポートをUSB HOSTに接続し、デバイスノードに/dev/ttyUSB 0が追加され、このノードは元のデバッグシリアルポートの/dev/ttyS 2と通信できることが証明された.

もう一つ問題が残っている

カーネルは/dev/ttyS 2を占有しています.彼に送ったデータは、カーネルがエコーされ、解析実行を試み、フィードバックを出します.これは、一般的なシリアル通信方式でデータ送受信テストを行うことはできません.前述した従来のスキームは、カーネルのエコー機能を利用した特殊なデータ送受信方法を提供する.ここでは安定性を向上させるために,カーネルのデバッグシリアルポート構成を直接修正し,/dev/ttyS 2をデバッグシリアルポートとしない.ここでUbuntuでscrファイルを生成する方法を採用すると,メリットは2つある.一度にファイルを交換すればいいので、毎回構成しなくてもいいです.二つ目はubootのデフォルト変数とFlash、eMMCの変数の記憶の影響を受けないことです.

#boot.cmd  
setenv console 'ttyS2,115200n8'

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Beagleboard boot script" -d ./boot.cmd ./boot.scr
#sudo apt-get install u-boot-tools（mkimage  ）

もちろん、このように構成すると、このシステムはテストにしか使用できません.デバッグシリアルポートは使用できません.問題のトラブルシューティングを容易にするために、車scrファイルを1つ多く提供し、ubootのconsole変数を再構成できます.
この案は広州創龍の570 xボードカードで検証された.
2020年7月27日