☰

USB g_serial 오류? - 한 방향으로의 데이터 손실

tag-icon • tag-icon kernel bugs
USB g_serial 오류? - 한 방향으로의 데이터 손실

커널 모듈 Gadget Serial v2.4를 사용하는 데 몇 가지 어려움이 있습니다. g_serial은 Arch Linux 4.6.3-1이 설치된 ARM 머신 BeagleBone Black에서 호스트 PC와 통신하는 데 사용됩니다.

문제는 다음 호스트에서 재현됩니다.

  • 리눅스 4.2.0-23, PC x86_64,
  • 리눅스 3.4.43, Cubieboard2 armv7l,
  • 윈도우 10, PC x86_64,

다른 소프트웨어를 사용하십시오.

  • 장치(비글본 블랙):

    • C++ 및 용어,
    • python3-pyserial.

  • 호스트(PC 또는 Cubieboard2):

    • C# + .NET,
    • python3-pyserial.

파이썬 테스트:https://github.com/tomasxvavra/serial_test.

문제는 장치->호스트 방향에서 데이터가 손실된다는 것입니다. 예를 들어 장치가 ttyGS0에 100MB의 데이터를 전송하면 호스트는 ttyACM0에서 데이터의 99.7%만 수신합니다. 이것안 돼요호스트->장치 방향으로 발생합니다.

손실된 데이터의 양은 다음 조건에 따라 달라집니다.

  • 직렬 포트에 기록된 데이터 "패킷" 크기: *s.write(data)를 통해 포트에 한 번에 100MB를 쓰는 경우 실패할 가능성이 훨씬 적습니다. 패킷 크기가 다른 포트에 쓰면 오류율이 달라집니다. 예를 들어:
    • 더 작은 패킷 <= 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

그러나 로드 크기가 다르면 상황이 더 악화될 수 있습니다. 여전히 타이밍 문제가 있는 것 같습니다. //

관련 정보