カーネルモジュールGadget Serial v2.4を使用するにはいくつかの困難があります。 g_serial は、Arch Linux 4.6.3-1 がインストールされている ARM マシン BeagleBone Black でホスト PC と通信するために使用されます。
問題は次のホストで再現されます。
- Linux 4.2.0-23、PC x86_64、
- Linux 3.4.43、Cubieboard2 armv7l、
- Windows 10、PC x86_64、
他のソフトウェアを使用してください。
デバイス（ビーグルボーンブラック）：
- C++ と用語、
- python3-pyserial.
ホスト（PCまたはCubieboard2）：
- C＃+ .NET、
- python3-pyserial.
Pythonテスト：https://github.com/tomasxvavra/serial_test。
問題は、デバイス→ホストの方向からデータが失われることです。たとえば、デバイスがttyGS0に100 MBのデータを送信すると、ホストはttyACM0からデータの99.7％しか受信しません。これいいえホスト - >デバイスの方向に発生します。
失われたデータの量は、次の条件によって異なります。
- シリアルポートに書き込まれたデータ「パケット」サイズ：
* s.write（data）を介してポートに一度に100 MBを書き込むと、失敗する可能性がはるかに少なくなります。パケットサイズが異なるポートに書き込むと、エラーレートが異なります。たとえば、
- 小さいパケット<= 512B - 大丈夫ですが、時には約10-512Bが失われて失敗します。
- より大きなパケット 4096 - 32768 B: より頻繁に失敗し、多くのデータが失われます。
- ホストデバイス速度- 遅いCubieboard2の故障率はPCよりはるかに高く、特にパケットが大きい場合はさらにそうです。
1024 B または同等のサイズの数字を送信すると失敗することがあり、通常は 512 B が失われます。また、Wiresharkを使用してUSBパケットを分析してみましたが、実際にパケット損失が発生しました。しかし、それ以外は異常とは説明できません。
だからこれは私のカーネルの観点から見たタイミングの問題のようです。 g_serialも同様の経験を持っていますか？ありがとうございます。
編集する
ホストがCubieboard2（CPU 2個）のときにCPU 1個をロードすると、エラー率が急速に低下することがわかりました。
cat /dev/zero > /dev/null
ただし、ロードサイズが異なると、状況が悪化する可能性があります。それでもタイミングの問題があるようです。 //